What Is a Proof Loop? The Check That Ends "Trust Me, It's Done"
A proof loop turns "done" into something a client can check: receipts written at call time, one link, Accept or Flag, payment released on proof.
# What Is a Proof Loop? The Check That Ends "Trust Me, It's Done"
Every client engagement that uses AI now ends with the same sentence. The agent reports back: done, all steps complete, here is the result.
And the client has exactly one way to respond: believe it.
A summary can be polished after the fact. A screenshot can be cropped. A transcript can be edited, and the edited version reads exactly as clean as the original. None of those artifacts can answer the only question that matters at payment time: did the work actually happen the way the record says it did?
A proof loop is the process that replaces belief with a check. It has five steps, and none of them asks anyone to trust a summary.
The loop, step by step
1. The work runs, and each step is recorded as it happens. When an AI works through Zambo, every tool call writes a verifiable receipt at the moment it runs: what was called, what came back, hashed into a record that cannot be quietly rewritten later, because any change breaks the check. The record exists before anyone knows whether the job will matter. That ordering is the whole point.
2. The receipts are gathered into one link. At the end of the job, the receipts for the session are bundled into a single handover page. One URL carries the entire job: every step, in order, each one tied to its receipt.
3. The client checks the record, not the claim. The client opens the link. No account, no install. Every receipt on the page can be re-verified in the browser, which means the check is a recompute: the page re-derives each hash and compares it against the record as saved. If a single character in a step changed after the fact, the check fails on that step, in plain language.
4. The client decides: Accept or Flag. The decision is not an email or a thumbs-up in chat. It is written into the record itself, with who decided and when, and it produces its own receipt. The agent that did the work cannot make this call. On Zambo, an attempt by the creator to accept its own handover comes back with a plain refusal: "Creator authority cannot accept this handover. Send the client link to its recipient."
5. Payment moves on the decision. The acceptance record carries a release state. While the client has not decided, it reads hold. When the client accepts, it reads ok_to_release. Money moves on the second state, not on the summary that announced the work was done.
That is the loop: work, record, check, decision, release. It closes because the last step feeds the first step of the next job: a client who can check is a client who sends more work.
A real loop, already closed
This is not a diagram. One of the first audit handovers run through Zambo, 45434a17, is still live: https://zambo.dev/handover/45434a17-4afc-486a-9646-e689bcee4297
Its acceptance record shows four steps, all four checked. Decided by: client. Decided at: October 16, 2026. Release state: ok_to_release.
Open it and read the record the way the client did. Nothing on that page asks to be believed. Every line of it can be re-derived.
Why a log is not a loop
Teams often answer this with "we keep logs." A log is written by the same system that did the work, stored where the operator can edit it, and produced when someone asks. A receipt in a proof loop is written at call time, before the outcome is known, and verifying it later means recomputing it, not rereading it. The difference sounds small. At a payment dispute, it is the entire difference.
The receipt format underneath is AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-23). Because the format is open, a receipt can be verified offline with the AER-1 verifier, without asking Zambo's server whether Zambo's record is good. The checker does not have to trust the checked.
Run your first loop free
The fastest way to understand a proof loop is to watch one close. The live demo at https://zambo.dev/demo/ runs a real job and produces a real receipt you can open and check. Public handovers are free, and the first proof loop is free: do a piece of work, hand it over, and watch what the client side of the link actually shows.
More on how the pieces fit together lives on the AER-1 hub: https://rambozambodotdev.gitlab.io/aer1-hub/
The honest limits
A proof loop proves a narrow thing, and the narrowness is deliberate. A receipt proves the saved result was not changed since it was saved. It does not prove the work was correct, or good, or worth the invoice. That judgment stays where it belongs: with the client, at the Accept button. The loop makes sure the client is judging the real record. What they decide about it is theirs.
Your AI said "done." For $0.99, prove it: https://zambo.dev/day-pass/