How do I find a receipt if I only have the receipt ID?
The ID is the address. Review the receipt and actual deliverable before accepting a handover.
Receipt IDs circulate on their own: in emails, in invoices, pasted into tickets by clients who saved nothing else. The system is built for that moment. The run page resolves the ID to its record, showing the step, its job context, and the receipt itself; the verify route does the checking half, recomputing the record's commitment so you learn not only where the receipt lives but whether its saved result still matches what was committed when the step ran.
The -21 clarification deserves its sentence because it protects exactly this workflow. In the AER-1 format the receipt ID sits outside the committed payload, so a copied ID next to a different record proves nothing by itself. Binding happens one of two ways: you supply the ID you expect and the checker compares, or the ID is resolved to its record and the record's saved result is compared against the commitment. Draft -21 (https://datatracker.ietf.org/doc/draft-zambo-aer1/21/) writes that rule down, and kit 1.5.4's checker reports the ID's state plainly: verified against an expected ID, verified by resolution, or unverified.
Practical habit: when you send a receipt ID, send the run link with it. The recipient gets the resolution and the check in one click, and the binding question answers itself in the process.
Steps: resolving and checking an ID
1. Open https://zambo.dev/run/<the ID> and read the record it resolves to. 2. Run the check at https://zambo.dev/verify/ with the same ID. 3. Read the ID state: verified-expected, verified-resolved, or unverified; treat unverified as a prompt to resolve properly, not as a failure of the receipt. 4. If you hold an ID someone pasted beside a record, supply it as the expected ID so the comparison in step 3 is the binding kind. 5. File the result with the job or ticket the ID arrived in.
Worked example
A real ID from the published test fixture set: 130da435-e157-498e-af90-605866a86a27, the draft's own Section 3 example receipt, reproduced by independent implementations. Run it through the steps above and the machinery behaves exactly as the draft describes, which is what a worked example for an identifier should be: the same ID, the same result, on any conformant checker.
Frequently asked questions
The ID resolves to a record, but the ID state says unverified. What is wrong?
Nothing is broken; the binding step has not been done in the binding way. Resolve the ID to its record and compare the record's saved result, or supply the ID you expected alongside the record. Draft -21 made the distinction explicit so checkers report it instead of hiding it.
Someone sent me only an ID and a claim about what the agent did. What can I conclude?
Resolve and check first. A verified receipt tells you the saved result for that step is unchanged since it was saved. The claim about the work is then judged against that saved result, which is firmer ground than the ID alone could ever give you.
Can IDs be guessed or enumerated?
Receipt IDs are long random identifiers; holding one is the practical key to resolving it. Treat IDs like links worth keeping private to the parties of the job, and share them the way you would share the record itself, deliberately.
By Brennan Zambo, founder of Zambo.
Last verified: 2026-10-17.
Try a handover
A handover gives your client one proof link with verifiable receipts to review, then Accept or Flag.
try it: say 'use zambo to hand this over to <client>' in your ai