Verifiable Task Completion
Proof of Done You Can Open
Most products mark a task "done" with a checkbox, so whoever receives the result has only the producer's word for it. Verifiable Task Completion declares up front what "done" must prove, then attaches an inspectable bundle to the result — tests passed, sources checked, sign-offs collected. You open the proof instead of trusting the label, and the evidence rides along when the result gets forwarded.
Framing
The problem
A task marked "done" is a label, not evidence — the receiver has to trust the producer's word, and that word carries nothing inspectable once the result is forwarded to someone who never saw the work.
The pattern
Declare what "done" must prove up front, then attach an inspectable proof bundle to the result at completion — passed tests, checked sources, sign-offs — so the receiver opens the evidence before accepting it and the proof travels with the result.
Why chat breaks here
A chat reply that says "done" is just text — there is no attached evidence to open, no way to ask "done against which criteria, checked by whom?", and nothing survives when the answer is copied onward.
Risks
Proof is only as good as its checks: gameable test suites or captured reviewers fake it, and a bundle only the producer can read defeats the point; the heavy-duty end — zk-SNARK traces, TEE attestations, cryptographic signatures — buys auditability at real cost and latency, so reserve it for high-stakes or private work, and treat it as where delegation is heading, not a default that ships today.
Avoid when
The task is low-stakes and the receiver can just look at the result themselves — attaching proof costs more than reading the output.
Use when
When a result carries its own evidence, the receiver verifies it in seconds instead of trusting a checkbox that proves nothing once it is forwarded.
DOPE evaluation
- Directability
- Delegators choose verification strictness (none / unit-test / zk-proof / panel) per task and renegotiate if a delegatee cannot meet the standard
- Observability
- The proof bundle is inspectable — every attestation, signer, and verification artefact is visible alongside the result
- Predictability
- The verification policy is declared up front; done means exactly the criteria the policy specified, no more, no less
- Explainability
- Each proof carries its method (test suite, ZKP circuit hash, TEE enclave id) and the verifier identity that signed it
In the wild
- C2PA · Content Credentials (C2PA · Adobe / OpenAI / Leica) — Cryptographically signed provenance metadata embedded in images, audio, and video at generation time. The proof travels with the artefact and any consumer can verify it without trusting the originating product. The clearest deployed example of "done = signed proof bundle" outside crypto.
- Optimism · Fault proofs (OP Labs) — Optimistic verification: results are accepted provisionally, but every claim carries an open challenge window in which anyone can run a fault proof that re-executes the disputed step and provably rejects a wrong result. Game-theoretic completion verification — wrong solutions cost the poster their bond.
- GitHub · Required status checks (GitHub) — Merge is gated by a verification policy: test suite must pass, CodeQL must succeed, signed-commits required. "Done" = green checks from named verifiers. Closest day-to-day production example.
- A2A Protocol · Signed Agent Cards (Google / Linux Foundation) — A2A v1.0 ships cryptographically signed Agent Cards — verified agent identity today. Signed task-completion attestations (self-reported / counter-signed / third-party) exist as an active extension proposal (AIP, arXiv 2603.24775) layered on A2A — the closest agent-protocol trajectory toward this pattern.
FAQ
When should I use the Verifiable Task Completion pattern?
When a result carries its own evidence, the receiver verifies it in seconds instead of trusting a checkbox that proves nothing once it is forwarded.
When should I avoid the Verifiable Task Completion pattern?
The task is low-stakes and the receiver can just look at the result themselves — attaching proof costs more than reading the output.
What problem does Verifiable Task Completion solve?
A task marked "done" is a label, not evidence — the receiver has to trust the producer's word, and that word carries nothing inspectable once the result is forwarded to someone who never saw the work.
Why is chat the wrong fit for this?
A chat reply that says "done" is just text — there is no attached evidence to open, no way to ask "done against which criteria, checked by whom?", and nothing survives when the answer is copied onward.
Related patterns
- Extends: Action Audit & Undo — Action Audit logs what happened; Verifiable Completion signs what happened so the log itself is cryptographically trustworthy and portable.
- Often paired with: Citation Trail — Citations attach sources to claims; signed completion attaches verifiers to outcomes. Both make epistemic chains inspectable.
- Extends: AI Provenance — Provenance marks per-fragment authorship; Verifiable Completion adds a contractual seal that the full result meets a declared specification.