The proof loop: prove the work, then get paid.

Every freelancer and agency using AI hits the same moment. You deliver, and the client asks the fair question: did the AI actually do this work, and can you show me? A summary cannot answer it. Neither can the agent's own word. A proof loop can. It is the cycle this page names and teaches: the work runs, every step lands as a verifiable receipt, the client opens one link and checks the steps, the client Accepts or Flags, and payment releases on the proof. Zambo is the verifiable work layer for AI; the proof loop is how its deliveries stop being something a client has to believe and become something a client can check.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup.

Published October 17, 2026. Every record quoted below was read live from zambo.dev on the day this page was written. Updated October 17, 2026. Written against AER-1, IETF Internet-Draft revision 23: draft-zambo-aer1-23. AER-1 is an IETF Internet-Draft, not a finalized standard.

The question behind the question

When a client asks whether the AI really did the work, they are rarely accusing you. They are doing the only diligence available to them, because everything they have been handed so far is a retelling: a summary the AI wrote about itself, screenshots you took, a file with no history attached. The side being paid wrote every word of the evidence. That is why the conversation stalls. It is not that the client doubts this delivery in particular; it is that no delivery made this way can be checked at all.

The fix is not a better summary. It is a record made while the work ran, by the connection the work ran through, in a form the client can verify without asking anyone. That record, plus a decision recorded on top of it, plus payment released against the decision, is the proof loop.

The proof loop, stage by stage

  1. The work runs through one connection. One endpoint, https://zambo.dev/mcp, added to the AI doing the work: Claude, ChatGPT, Cursor, Grok, Windsurf, or VS Code. The recording happens during the run, not in a write-up after it, which is the whole difference between a record and a story.
  2. Every step lands as a verifiable receipt. Each call the AI makes leaves a receipt at the moment it runs: the tool, the time, the saved result. A receipt shows that the saved result has not changed since it was saved, and anyone can recompute it and check. Steps that were not checked are not hidden; they are named on the record as not checked.
  3. The steps ship as one handover link. The goal, the step receipts, the not-checked list, and the next steps, packaged behind a single link your client opens in a browser. The mechanics are documented at zambo.dev/docs/handover.
  4. The client checks, then Accepts or Flags. Every receipt on the page opens and verifies. Then the client makes the recorded decision: Accept, which puts the approval on the record with a time and a decider, or Flag, which records the objection and its reason and keeps the work unreleased.
  5. Payment releases on the acceptance. The acceptance state is itself a record the payer can read before paying: hold while the work is pending, ok_to_release once it is accepted. Money moves against proof, not against a promise. The payment order in full is proof before payment.

Name it and clients start asking for it by name: run the proof loop on every delivery, and "did the AI do this?" becomes a link you send, not an argument you have.

A closed loop, opened live

Worked example: handover 45434a17, accepted by its client

Handover 45434a17, goal "Delivery of zambo_universal", delivered October 16, 2026. Four steps ran between 14:31:01 and 14:31:13 UTC, three zambo_universal calls and one prompt_shield call, each with its own verifiable receipt (the first step opens at zambo.dev/run/c7e596e9). The client opened the link, checked the steps, and accepted. Its acceptance record, read live today, reads: status accepted, decided_by client, decided_at 2026-10-16T14:31:51Z, release_hint ok_to_release, 4 of 4 steps checked. The acceptance is itself a receipt, 14cb8b21, recorded against the work it approved.

The record is plain about its own scope, in words quoted exactly: its check scope reads "Receipt bytes only; not accuracy or human review of every step", and the acceptance carries the identity notice "Logged by Zambo on behalf of the visitor. Not identity-verified." A loop that hides its limits would not be proof of anything. This one prints them on the record.

What the loop proves, and what it does not

  • It proves the record. The saved result of each step is unchanged since the moment it was saved. Checking is a recompute anyone can run, not a trust decision anyone has to make.
  • It proves the sequence. Which steps ran, with which tools, at what times, and what each one returned as saved, including the steps nobody checked.
  • It proves the decision. A client accepted at a recorded time, or flagged with a recorded reason, or has not decided yet. All three states are readable on the record.
  • It does not prove correctness. Whether the work is good is a judgment. The loop deliberately ends in a human Accept rather than an automatic one, because checking bytes and judging work are different acts.
  • It does not prove identity. The record carries its identity notice verbatim. The decider is recorded as the client side of the link, not as a verified person.
  • It does not cover work done elsewhere. Work that never ran through the connection was never recorded, and no receipt can be minted for it after the fact.

Run your first proof loop

  1. Connect the AI that will do the work. Add the endpoint https://zambo.dev/mcp to it. One connection covers the work, the receipts, and the handover.
  2. Do the work. Every step lands as its receipt while it runs. Nothing extra to remember, nothing to write up later.
  3. Package and send the handover link. The goal, the steps, the not-checked list. Send the client the link, not a summary. The handover documentation walks the exact screens.
  4. Let the client check and decide. The public page, the browser verification, and Accept and Flag are free for the client. A Flag names the step and the reason; fix that step and the loop turns again on the same record.
  5. Get paid against ok_to_release. The acceptance record is the release document. When it flips, the proof is complete and the invoice points at a decision, not a claim.

The agent-to-agent form of the same loop is handover between AIs, receipts attached. When the client's pushback is about price rather than proof, the dispute packet is the same record aimed at the invoice.

Questions, answered

How do I prove to my client that my AI actually did the work?

Run a proof loop. Do the work through a connection that records every step as a verifiable receipt at the moment it runs, package the steps into one handover link, and send your client the link instead of a summary. Your client opens it, checks any step's receipt in the browser, and Accepts or Flags the work. The acceptance is recorded as its own receipt, and payment releases on that acceptance. Nobody in the chain has to take anyone's word for anything: your claim is the link, and the link checks out step by step. Zambo is the connection that runs the loop: one endpoint, https://zambo.dev/mcp, added to the AI doing the work.

What does my client actually see when they open the link?

The delivery, as a record. The goal, every step with its tool and time, each step's own receipt link, the list of anything that was not checked, and an AI-use statement naming which AI helped with how many steps. The receipts open and verify in the browser, no account needed on the public page. At the bottom sit the two decisions: Accept, which records the approval and flips the release state, or Flag, which records an objection with its reason and keeps the work unreleased until it is resolved.

What happens if my client flags the work instead of accepting it?

Nothing releases, and the disagreement gets specific. A Flag is recorded on the handover with the reason the client gives, the release state stays hold, and the disputed step is the one named in the record, not a general complaint about the whole job. You fix that step, the new work lands as new receipts on the same record, and the client checks again. The loop does not argue with the client; it narrows the argument to one step and one receipt at a time.

Does a proof loop prove the work is correct?

No, and the loop is honest about that on the record itself. A verifiable receipt proves the saved result of a step has not changed since it was saved; checking it is a recompute, not a trust decision. Whether the work is good is a judgment, which is why the loop ends in a human Accept instead of an automatic one, and why the acceptance record carries its scope line verbatim: receipt bytes only, not accuracy or human review of every step. The loop also does not prove who ran the work; the record says so, in its identity notice.

What does it cost to run a proof loop?

The checking side is free: the public handover page, browser verification of every receipt, and Accept and Flag cost the client nothing. On the working side, the free tier covers a first loop end to end. For $0.99, run the proof loop on the next delivery and hand the client a record they can check and accept: get the Day Pass. The Day Pass covers 24 hours; ongoing use is the Zambo Pass at $29 a month or $290 a year, $19 a month for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.

Related