Verification checks
The evidence reference: each check the receiving client runs automatically, the references it uses and where it runs, for integrators and auditors.
Standard Proof is execution evidence that a receiving system can check against its own accepted policy. The receiving client runs these checks automatically before it delivers a result, so the next agent can use it without manual inspection. This page lists the checks for integration testing, auditing and troubleshooting.
Input bindings identify the artifacts or snapshots used. Source provenance is covered only when the operation includes evidence of the source. Execution evidence does not establish that source records are truthful or complete.
Where verification runs
The recipient's integration, SDK, or verification software checks the evidence in an environment it trusts. A dashboard status or an agent's success message is not a substitute for those checks.
Accepted references must be established independently of the candidate result. They include the runtime identity and revocation state, evidence-signing trust roots, workload and input digests, applicable authority, and the recipient's verification policy.
Claims to check
The required evidence depends on the selected operation and execution boundary.
| Claim | Required relationship |
|---|---|
| Runtime | Attestation must match the accepted environment and applicable freshness or revocation requirements. |
| Workload | The recorded workload must match the approved code, model, or verifier. |
| Inputs | Recorded input bindings must match the expected artifacts or snapshots. |
| Authority | The operation and release must be covered by the required permissions. |
| Result | The evidence must bind to the exact returned result and intended release context. |
| Signature | The signed evidence must validate under the accepted trust model. |
Missing evidence for a required claim is a verification failure. A claim outside the recorded boundary remains unverified. Cleanup is reported separately and is not proof of physical erasure.
Independent checks for agent-written code
Pin the test suite, evaluator, and acceptance policy outside the producing agent's authority. Verify their digests as well as the candidate artifact's digest. A different test suite cannot silently satisfy a policy that requires the original suite.
This establishes which checks ran and their recorded outcomes. It does not establish that the tests are sufficient or that the software has no defects.
From verification to action
An accepted proof may contain a failing security report. Verify the evidence first, evaluate the report second, and enforce authority for the next action separately. For release, all three must succeed before the exact tested artifact proceeds.