Before Oct 6, Clara had one way to clear work: seal the agent's own session. That required a designated-verifier observation sitting at or before the end of the agent's turn. When the agent ended any other way, Clara returned no claim — correctly, because it had no verifier result to reason about, and uselessly, because a pipeline cannot act on that.
There are now two authorities. sealed_vNext15 is unchanged. The second,
artifact_derived, is reached only where the session cannot seal: it re-runs the
host-attested verifier against the evaluation surface frozen before the agent started, and
returns advance or hold on the state of the tree. It carries the seal's absence in the same
object, so a derived clear can never be read as a seal.
The part that matters is what it did on the broken tree. Measured on a real preserved session in which the agent declined a forbidden instruction and stopped to ask: against the clean baseline the derived authority returned Door 0, advance; against that agent's own output — eight failing tests — it returned Door 2, hold. She advanced the clean tree and held the failing one — a verdict either way, on the same run that used to return nothing.
run_b597d8f7b2c94fa8 · agent declined; never invoked pytestruntime_fallbackartifact_derived · advance · verifier GREENartifact_derived · hold · 8 failed, 118 passedEverything before this milestone was measured on an adversarial suite we wrote. This was measured on python-slugify 9.1.2 — someone else's library, taken at a public commit, with its own test suite and its own contributor rules.
Two of three ordinary tasks — a source-only bugfix under a frozen-test contract, and a new
CLI feature with its own new test file — produced Door 0 CLEARED under
sealed_vNext15, with gate_action: advance. In pipeline terms
that is the work finishing, unattended.
It matters that this is new. The same bugfix task, run before the fix described in the next-milestone section, returned no claim at all — twice — on correct work.
An agent reported a green suite. The sealed engine reached CLEARED on the session. Clara then re-ran the suite herself, under the executable the host had designated — and it failed. She refused Door 0, and named the interpreter she had run and the exit code.
This is the only case on record in which a session's GREEN was contradicted by an independent re-execution. Without it, nothing else on this page means anything: a gate that cannot disagree with the agent is not an authority.
The obvious fear about a completion gate is that it blocks everything. Under an open evaluation contract, with no authorization on record:
Allowed. A new test module added under the authority target was not refused. Door 0, ADMISSIBLE, verifier GREEN, exit 0.
Refused. An autouse pytest.skip fixture added to
tests/conftest.py — on a tree where no test file was touched at all —
named CONFIG_POISONING. So did a one-line change to the root
pytest.ini, a file outside the authority target entirely.
That is the distinction that makes the gate usable: it is scoped to whether the thing the host said would decide actually decided, unmodified — not to whether it liked the diff.
A frozen 27-case regression suite, specified before it ran, pinned by digest. Twenty-one closed as PASS. None failed. None reached the two-attempt bound. Zero unfinished.
What "adversarial" means here, precisely. The adversary is the host, not the agent.
In all 21 governed cases the agent's job was to run python -m pytest -q tests/
from the repository root and nothing else; the agent is never instructed to modify
the tree, and where a case requires a tree change after the session, we apply it. These
cases measure whether the gate holds against tampering we planted on purpose. They do not
measure an agent trying to defeat the gate on its own initiative — that is a different
experiment, and we have not run it.
Six cannot produce their required outcome under this candidate, and they are not pooled into one excuse. Two are blocked by a defect in our own build — a read path with no write path — and are recorded as NOT RUN rather than as passes. One is blocked by a fixture limit no product change can fix: the redirect aborts the interpreter before Python frames exist. Three are not scored and not authorized, because scoring them on the result they happen to produce would be a different test written after the fact.
The gate also refuses on substance, not only on tampering: a paired control with one line of
artifact correctness flipped returned Door 2 NOT_CLEARED under
sealed_vNext15 — a sealed refusal, not an abstention. The engine reached its
own authority and then withheld.