Fake completion
What stops an AI agent from faking task completion? A record it never gets to write.
Nothing stops an agent from typing the word "done." What stops the fake from surviving is evidence the agent cannot manufacture: a verifiable receipt issued by the platform at the moment the work ran, public at a stable URL, that anyone can recompute. A fake completion is a claim with no receipt under it. An altered record fails the recompute. This page checks a real receipt from today, end to end.
Worked example: a receipt from today, recomputed
On November 3, 2026, at 21:55:40 UTC, a job wrapped up through Zambo and the platform issued receipt 80984519-5913-4416-8356-69d53daa57be. Its saved result is committed under output_hash sha256:f07eaf55a806e15b01eb0bb06845d26edc42e9e003d3b8a5f2b61ed2d7ab1d21. The public verification endpoint recomputes the hash from the receipt's own canonical bytes and reports the commitment check as a pass, expected hash equal to computed hash, verification status: verified. Run it yourself at the receipt's verify endpoint, no account, no token. That receipt is one of more than 6,500 issued today alone, on a live public record that passed 105,400 receipts. If the underlying work had never run, there would be no receipt to open. If anyone edited the saved result afterward, the recompute would fail.
Why the fake fails: three properties of the record
- The platform issues the receipt, not the agent. The agent asks for a tool call; the endpoint executes it and saves the result as it runs. The agent's chat summary is written afterward and can say anything. The receipt was already written by then, by someone else.
- The result is committed at execution time. The receipt carries a SHA-256 hash of the exact saved bytes, fixed at the moment of the call. Changing one byte of the record later changes the recomputed hash, and the mismatch is public and permanent.
- Anyone can recompute it, forever, for free. The record sits at a stable public URL. Independent verifiers exist precisely so the check does not depend on trusting the platform: six independent AER-1 implementations verify receipts against the open draft, and the AER-1 Verify GitHub Action runs the same check inside your own CI pipeline.
The recompute test, step by step
- Ask for the receipt, not the summary. A completion claim that cannot produce a receipt link is a story. Treat it that way.
- Open the record. Every Zambo receipt resolves at zambo.dev/run/ plus its id, and its full JSON at the receipt API, with no login.
- Recompute the hash. Decode the canonical_bytes field, compute SHA-256 over the exact decoded bytes, and compare with output_hash. A match proves the saved result was not changed since the call ran.
- Check the binding fields. Read the provenance_class, the created_at timestamp, and the metadata_hash if present. This is the Section 6 procedure of draft-zambo-aer1-26, written so a stranger can run it.
- Then judge the work. With the record settled as intact, read the outputs and decide if they are good. That judgment is yours. The receipt's job was narrower: the work happened, as recorded.
What this stops, and what it does not
It stops the two moves that make fake completion profitable: claiming work that never ran, and quietly editing the record of work that ran badly. Both die against a receipt the agent cannot write and cannot rewrite. It does not stop an agent from doing poor work in the open: a faithfully recorded bad result is still a bad result. The receipt proves the saved result was not changed, not that the result was right. Anyone who sells you a stronger claim than that is selling you a story about a record instead of the record.
Make completion unfakeable from the start
Work that already ran with no record underneath it cannot be proved after the fact. Run the next job through Zambo and the evidence is produced by the run itself: connect any MCP-capable AI at zambo.dev/add (20 calls and 1 wrap-up free every day, no account), and every call leaves its verifiable receipt as it executes. The checkable record is the whole point: the standard behind it is measured against a public conformance corpus of 143 vectors and 146 checks, and the interop record is public at the AER-1 interop page.
Questions, answered
What stops an AI agent from faking task completion?
A record the agent never gets to write. The platform issues a verifiable receipt at execution time, the saved result is committed by hash at that moment, and the receipt is public for anyone to recompute. A fake has no receipt. An edited record fails the recompute. What remains is work that provably ran as recorded.
My agent says it finished but there is no receipt. Now what?
Then the completion is unproven, however confident the summary sounds. You can ask the agent to rerun the work somewhere that records it as it goes, like zambo.dev/mcp, or treat the claim as unverified and check the outputs by hand. There is no way to retroactively prove an unrecorded run.
Does a verified receipt prove the agent did good work?
No. It proves the saved result was not changed since the call ran. Good is a judgment you make by reading the intact record. The receipt rules out the fake and the quiet edit; grading the output stays with you.