How to Prove AI Work Is Actually Done

What counts as completion evidence?

Completion evidence is a machine-readable record that ties one observable acceptance criterion to an exact verifier, an observed result, an artifact or receipt, a freshness rule, a reviewer, an unresolved risk, and a verdict.

The definition is deliberately stricter than proof of activity. A trace can show that a model called a tool. A test receipt can show that one command exited successfully. A digest can identify the bytes that were reviewed. An attestation can connect an artifact to a build process. None of them, alone, proves that the intended customer or production outcome now exists.

The criterion owns the decision. If the promise is 'the page is live at the canonical URL,' the verifier must query that URL and inspect the returned state. A build log is useful supporting evidence, but it answers a different question.

Write the criterion so a person or program can observe it without interpreting a victory speech. 'Improved the page' is not checkable. 'The canonical URL returns 200, contains the approved H1, and exposes the expected canonical tag' is.

How do you connect a claim to a verdict?

Start with the promised outcome, then work backward to evidence. Do not begin with whichever logs happen to exist. Available telemetry can support a criterion, but it should not invent the criterion after the work is finished.

The matrix below turns a confident statement into a reviewable decision. One task can have several rows. The overall verdict cannot be stronger than its weakest required row.

Use PROVED only when the criterion has fresh passing evidence and the required review. Use INCOMPLETE when evidence exists but disagrees or remains partial. Use BLOCKED when an important criterion has no observable verifier. Use HUMAN_REVIEW_REQUIRED when a machine can collect the evidence but the decision needs accountable judgment.

What does each kind of evidence prove?

Evidence is useful when its boundary is explicit. Teams get into trouble when a strong artifact is allowed to answer a question it never observed.

A cryptographic hash identifies exact bytes. It does not say those bytes are correct. A passing test receipt says a named test ran and passed against a named revision. It does not say the test covered the promise. A screenshot shows what one viewport displayed at one moment. It may be stale, cropped, or disconnected from the current system.

A trace shows activity inside an execution. OpenAI's current Agents SDK tracing documentation includes generations, tool calls, handoffs, guardrails, and custom events. That can explain what ran. It does not promote the final business result to true. Traces can also capture sensitive data, so collection needs an explicit privacy boundary.

An artifact attestation connects an artifact to provenance about how it was built. GitHub's documentation is careful about the limit: an attestation supplies provenance, not a guarantee that the artifact is secure or correct. The final acceptance decision still belongs to the workflow's criteria and verifier.

An action receipt proves that an outside system accepted or recorded an attempt. The postcondition may still fail. A fresh independent live check is stronger for a live-state claim because it observes the state the user or operator will actually encounter.

What happens when you test the contract?

I built a side-effect-free local experiment with one artifact, one test receipt, and one HTTP endpoint. The evaluator received the same fields the public contract recommends. It then compared three completion records.

The evidence-backed record supplied three observable criteria: the artifact digest matched build-42, the required fixture test returned exit code 0, and a fresh HTTP request returned build-42. Each row named its evidence reference, reviewer, and remaining limit. The evaluator returned PROVED.

The narrative-only record said the work was complete but supplied no observable criteria. The evaluator returned BLOCKED. A persuasive summary could not manufacture a verifier.

The third record contained a stored accepted deployment attempt for build-42 while the independent endpoint returned build-41. The evaluator returned INCOMPLETE. The receipt proved an attempt. The endpoint disproved the claimed postcondition.

The experiment is intentionally narrow. It does not prove production security, every test path, or the behavior of a real deployment provider. It proves the contract's decision behavior: status loses when fresh verifier output disagrees, and a narrative cannot substitute for observable acceptance criteria.

What should a completion receipt contain?

Keep the receipt small enough to generate for every important criterion. It should point to durable evidence instead of copying every log, prompt, or payload into one document.

Freshness is part of the contract. A test from the correct revision can stay valid for an artifact claim. A live-state check from before deployment cannot support a post-deployment claim. Store both the observation time and the revision or attempt identity that the observation covers.

Independence should match the risk. The author can verify a reversible local draft. A production release, payment, deletion, or policy change should require a reviewer or live verifier that did not simply repeat the agent's own claim.

What the WarpOS release disagreement taught me

WarpOS is the agentic operating system I use to coordinate work across several production applications. Its frozen public commit already contains strong completion machinery: backed dispatch records, current schema checks, output digests, named artifact hashes, cross-provider review rules, acceptance-criteria checks, approval records, and release state transitions.

The coverage gate rejects an ok:true row without dispatch identity and a command checksum. It also rejects stale schema records and named artifacts whose on-disk digest disagrees. The artifact-contract validator fails closed on unknown types, missing fields, conflicting precedence, dangling references, and internal errors. Those are useful, executable forms of proof discipline.

The same frozen commit exposed a harder boundary. Release RL-20260611-045 has status deployed, a deployment target, a timestamp, and a deployer. Its generated report still says preparing, not deployed, no approval recorded, and deployment not performed. The release helper can mark a record deployed and update ledgers without independently checking the outside environment. Its ledger updates are intentionally fail-open.

That disagreement does not erase the delivery. It shows exactly where the system needed stronger truth: the release status and report were records about deployment, not the deployed environment itself. The hardening rule is to query the target after the action and let that result govern the live-state claim.

This is why the strongest completion system keeps several layers distinct. A backed worker record proves bounded execution. An artifact digest proves identity. Tests support selected behavior. Approval proves authorization. A provider receipt proves an attempt. A fresh postcondition check proves the observed target state. The final verdict joins them without pretending any one layer saw everything.

When should the workflow refuse done?

Refuse done when a required criterion has no observable verifier, the evidence belongs to a different revision, the evidence is too old for the claim, the verifier failed, or a fresher independent observation disagrees.

Do not average the rows. Three passing checks do not cancel one missing production postcondition. The overall verdict is the weakest required verdict because the promise includes every required criterion.

A human-review verdict is not a polite version of pass. It means the machine collected enough evidence to frame the decision, but an accountable person still owns judgment. Keep the workflow blocked until that review is recorded.

Low-risk drafts can use lighter evidence. Outside actions and completion claims that trigger billing, publication, release, deletion, customer contact, or irreversible state need stronger reviewers and fresh postcondition checks. The cost of proof should follow the consequence of being wrong.

How do you build the first version this week?

Pick one completion claim your team has argued about. Write two or three observable criteria before changing the workflow. Name the exact command, query, reviewer, or outside-system check for each one.

Create one structured receipt per criterion. Tie every receipt to the artifact revision or attempt identity it observed. Add the four verdicts, then plant two failure fixtures: a narrative-only claim and a stored success label that disagrees with fresh live state.

Finally, connect the verdict to the workflow transition. If BLOCKED and INCOMPLETE still allow done, the receipt is documentation, not a control. Make the transition reject missing or contradictory evidence.

Start with one consequential path. Expand only when a real claim requires a new verifier. You do not need a verification platform to stop accepting victory speeches as operational truth.