How Verification Settles Work

An agent saying “done” is a claim, not a fact. Models are getting too good at being wrong and confident — so the Oathe runtime never lets an assertion of completion settle work on its own.

The claim loop

claim → statements (+ automatic trace linkage) → done → verification task → verify → settle or reopen

Every step is enforced in the substrate, where no caller can route around it. Refusals are features: a second claimant is refused, a statement against no claim is refused, self-verification is refused, settlement without a verdict is refused.

Trajectory vs. task intent

Verification is not an agent reading logs. The verifier — an engine that didn’t write any of the code — post-processes the agent’s recorded session traces against the task intent: what was the definition of done, what did the agent actually do, and does the evidence support the completion statement? It can rerun the deciding test. It can be a different harness than the one that did the work.

If the evidence doesn’t hold, the work reopens. Rejected work stays open — nothing quietly becomes true.

Effect receipts

Consequential actions — deploys, payments, messages — carry durable identities and receipts. On retry, an effect that already happened is refused rather than repeated. The definition of done is recorded before work starts, so it can’t drift to match whatever the agent ended up doing.

Where Scan fits

Oathe Scan applies the same behavioral philosophy before a skill enters the runtime: run it in a sandbox, watch what it does, judge the behavior. Verification applies it during the work. Together: nothing enters unaudited, and nothing settles unverified.