The gap per-step receipts leave open
A receipt for one tool call proves that call ran and that its saved result was not changed afterward. That is necessary, and it is not enough for a multi-step job. A folder of loose step receipts has no binding over the set itself:
- A missing step is invisible. Drop one receipt from the folder and every receipt left still verifies on its own.
- An added step is invisible. Slip an extra receipt in later and nothing in the set objects.
- Order is a claim. The sequence the steps ran in lives in a summary someone wrote, not in the record.
Anyone auditing the job has to trust that the set they were handed is the set that ran. That trust is exactly what receipts exist to remove.
What a whole-job receipt does differently
When a job closes, its step receipts are bound together in the order they ran, and a single commitment is computed over the step receipt identifiers. In AER-1 that commitment is the workflow root described in Section 8.1 of draft-zambo-aer1-23: the leaves are the step receipt identifiers, not summaries of the work.
That one design choice changes what a checker can ask. Recompute the root from the step receipts in front of you and compare it with the root committed at close:
- Match: the set you hold is the set that was sealed, complete and in order.
- No match: something was added, dropped, swapped, or reordered after the close, and the record itself shows it.
The check needs no account and no trust in the agent or in whoever handed you the receipts. Ask for a zambo receipt for the whole job, not just for the last step.
How to check a whole-job receipt
- Ask for the job record, not the summary. The summary is the agent's account. The sealed record is the evidence.
- Open the receipt at zambo.dev/verify/ and confirm the job shows as closed and sealed.
- Walk the steps in order. Each step receipt names its tool, its inputs, and its saved output, so the job reads as a chain of checkable calls, not a story.
- Compare the deliverable against the final steps. The receipt fixes what ran; your comparison judges whether the work itself was good.
- Keep the receipt link with the deliverable. Anyone downstream can repeat the same check without asking you or the agent.
What it proves, and what it does not
A whole-job receipt proves the saved record of the job was not changed after the job was sealed, and that the set of steps is complete relative to that seal. It does not prove the answer was right, the plan was wise, or the action was authorized.
Zambo issues a verifiable receipt for every job run through it. A Day Pass ($0.99) keeps a full day of runs receipted, and closed workflows stay sealed and checkable. The format is AER-1, an open IETF Internet-Draft, so the record stays readable outside any one product. For the continuity side of the same idea, where a second model picks up a job mid-task, see the cross-AI continuity guide.
Whole-job receipt: FAQ
What is a whole-job receipt?
A single verifiable record for an entire multi-step job. At close, the step receipts are bound in order under one commitment, so anyone can check the set is complete and unchanged.
How is it different from per-step receipts?
Per-step receipts prove individual calls. A whole-job receipt proves completeness across the job: add, drop, or swap a step after the close and recomputing the commitment no longer matches.
What does a whole-job receipt not prove?
It does not prove the work was correct or authorized. It proves the record of the job was not changed after it was sealed.
Can I get a receipt for the whole job, not just the steps?
Yes. Close the job and the step receipts are bound, in order, under one summary receipt with a Merkle root over the step receipt identifiers. The per-step receipts still exist for anyone who wants to drill in, but the object you hand over, file, or check is the whole-job receipt: one link, one root, the complete set. The worked example above is one: three price lookups closed into workflow 7b3afeb4-0c8e-47f8-aef8-0dc3d8ce83f2, checkable at zambo.dev/workflow/7b3afeb4-0c8e-47f8-aef8-0dc3d8ce83f2.
How do I verify a multi-step AI workflow receipt?
In three passes. First, open the workflow receipt and check each step receipt at its verify link; each must report verified, which binds that step's saved output. Second, recompute the Merkle root from the ordered step receipt identifiers exactly as AER-1 Section 8.1 specifies (a SHA-256 leaf per identifier, adjacent pairs hashed together, an odd digest duplicated before pairing) and compare it to the root the workflow carries; a match means no step was added, dropped, reordered, or swapped after the close. Third, read what the record does not claim: verification binds the record of the job, not the correctness of the work in it.
AI workflow receipt
The workflow-level form of the same idea. An AI workflow receipt is the verifiable record of a whole workflow rather than a single call: every step's receipt, bound in order at close, so the complete job can be checked as one object. Single-call receipts answer "did this step run and is this its result"; the workflow receipt also answers "are these all the steps, in this order, with none added, dropped, or swapped afterward". That second question is the one that matters when a job is handed over, billed, or disputed, because a true set of step receipts in the wrong order, or with a step missing, tells a different story than the job that actually ran.
On Zambo, closing a workflow produces this record automatically: the root that binds the steps is computed at close, and anyone with the link can walk the steps and recompute. It is the receipt a client, an auditor, or the next AI session actually wants.
A worked example, minted live on October 16, 2026. One session ran three live_price calls and closed: BTC at $81,465.00 (receipt fc46bdf4), ETH at $2,432.62 (receipt 93bfec91), SOL at $104.07 (receipt 01b5b201). The close produced workflow 7b3afeb4 under summary receipt 9235b09d-25d7-471d-a265-89ba426da838. Each step receipt and the summary receipt report verified at the public verify endpoint, and the workflow's Merkle root, 9a1ede26ee189ee01eec6973566f9b6ca4a8ed51c2b740331900fbc98a011546, was recomputed independently from the three step receipt identifiers using the construction in AER-1 Section 8.1: it matches. Drop any one of the three steps and the recomputation lands on a different root.