Proof of delivery for AI work: hand your client a record they can check.

Your AI finished the job. What does your client actually get? Usually a summary, a screenshot, or a transcript: documents written after the fact by the process being asked to prove itself, every one of them editable before it is sent. Zambo is the verifiable work layer for AI, and the instrument for this problem is Handover: the session's receipts, gathered into one link your client opens with no account. They press Verify all and the checks run in their own browser. They can change one character in a step and watch the check fail. Then they accept or flag the delivery, and their answer gets a verifiable receipt of its own. Delivery stops being a claim and becomes a record both sides can check.

Worked example: one live handover, checked the way a client checks it

On October 16, 2026, a five-call session closed at 14:34 UTC into a public handover for a client named Acme. Read it the way the client does. The steps: a live_price call returned BTC at $82,309.00 USD, published as receipt e636bd8a-4c5f-42e6-af68-bf5ae352556e; a prompt_shield scan closed the session as receipt eeadeb75-87fe-4df7-895e-21f5b51c164a. Every step on the page is a redacted publication copy pointing back to its source receipt. The close: summary receipt bdc7422b-fc4b-4793-af38-cd9971c125ae commits to the whole step list under root 8a45f08695599fa3bc5cc231464909801261ed09c421706e472c325b014df825. The check: the public verify endpoint reports the summary receipt and both named step copies verified, with the commitment, canonical payload, provenance binding, and metadata binding checks all passing. Nothing in that paragraph was taken on anyone's word: open the handover, press Verify all, and the same checks run in your browser.

Now the part that makes it proof rather than marketing. The handover's not checked list names two of its own five steps, by receipt identifier, with the reason "tool did not complete successfully": one was a planned action that waited for an approval that never came, and one returned a preview snapshot instead of a completed result. A summary would have smoothed both over. The handover keeps them in the delivery, labeled as not checked, where the client can see exactly what is not covered. It also prints its own not proven list: outside timestamp, issuer identity, and result correctness. Try the client side yourself: the handover is live and open. Press Verify all, then use its break-a-step box, change one character, and watch that step fail its check.

Hold one yourself: the live demo runs one real call and hands you its verifiable receipt, no signup.

Published October 16, 2026. Updated October 20, 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.

Proof of delivery for AI work

The short answer. Delivery is where AI work changes hands, and it is the moment the record usually stops. The run had receipts while it executed; the client receives a paragraph about the run. Proof of delivery closes that gap with the same records the run produced: one link carrying every step's verifiable receipt, the delivered files, and the list of what was not checked, closed under a summary receipt the client verifies in their own browser. The producer does not grade the delivery, and the client does not have to trust the producer's account of it. Both sides read the same committed record, and disagreements get settled against it instead of against competing summaries.

Scope, stated once and applied everywhere on this page: a verifiable receipt proves the saved result was not changed since it was saved. It does not prove the result was correct, and it does not prove an external event happened beyond what the record itself shows. A handover inherits that scope exactly: it proves the delivery is the recorded run, unchanged, with its gaps named. It does not grade the work inside it.

How to hand over AI work to a client

  1. Do the work through Zambo. Every tool call your AI makes gets a verifiable receipt with the hash of what it returned, fixed at execution time. Work done outside the recorded path has no receipts to hand over, so the recorded path is the delivery path.
  2. Ask for the handover. Say "Use zambo to hand this over to" your client, naming them. Zambo gathers the session's receipts, redacts emails, phone numbers, and keys, and publishes redacted copies as new receipts that point back to the originals, closed into one summary receipt. The copies are what the client sees; the originals stay bound behind them.
  3. Send one link. Your client opens it with no account and nothing to install, presses Verify all, can try to break a step, and then accepts or flags the delivery. Their answer gets its own receipt, so the acceptance is as checkable as the work.

Public handovers are free, with browser verification and Accept or Flag included. Private links, your branding, and PDF and JSON export come with the Zambo Pass at $29/month ($290/year, or $19/month for $ZAMBO holders). Hit a free limit mid-job and a Day Pass ($0.99 for 24 hours) lifts it. The full walkthrough, including the tool call and the JSON twin every handover carries, is in the Handover docs.

What an AI work handover includes

  • The goal and the steps. Every step of the session, in order, each with its own verifiable receipt and saved result, so the client reads the run itself rather than a retelling of it.
  • Publication copies bound to originals. Each step is shown as a redacted copy, emails, phone numbers, and keys removed, pointing back to the source receipt it was published from. Redaction protects the producer without unbinding the record.
  • Which AI ran each step. Where the producer states it, the page shows it, labeled as producer-stated. Where it is not stated, the page says unknown rather than guessing.
  • The delivered files. The file list the delivery claims, committed in the summary receipt alongside the step list, so a file added or dropped after the fact breaks the close.
  • The not checked list. Any step that did not complete is named, by receipt identifier, with its reason. The gaps are part of the delivery, printed on it.
  • The summary receipt and root. One receipt that commits to the exact step list, file list, and unchecked list, so the page the client checks is the page that was closed at delivery time.

The receiving side of the same record, what makes any single receipt in it worth relying on, is covered in AI agent trust receipts. Whether the run underneath actually finished is a separate question with its own check, in Did my AI agent really complete the task?

How a client verifies the delivery

  1. Open the link. No account, no install, no cooperation from the producer. The page is the delivery.
  2. Press Verify all. The checks run in the client's browser: the root is compared against the published summary receipt, every step's publication copy is verified, the unchecked list and file list are matched against the summary, and each copy is tied back to the same summary receipt.
  3. Try to break a step. The page offers a step's data for editing. Change one character and that step fails its check on the spot, because the recomputed digest no longer matches the one committed when the step ran. This is the difference between a record and a screenshot: the screenshot cannot answer back.
  4. Accept or flag. If the record holds, the client accepts in one tap. If a step is wrong, missing, or not what was asked for, they flag it, naming the step. Either answer is recorded with a receipt of its own, pinned to the delivery it answers.

Accepted handovers compound. Only accepted handovers the producer opts in are listed, and nothing is shown until a client accepts, so a track record built this way is a list of deliveries a counterparty checked and signed off on, not a portfolio the producer wrote about themselves. The single-receipt version of the same check, against the public endpoint, is in How to verify an AER-1 receipt.

What a handover does not prove

It does not prove the work was correct or good. A receipt over a wrong answer verifies exactly as cleanly as a receipt over a right one, because the commitment is to the saved result, not to its quality; judging the work is still the client's review, now done against the real record instead of a summary. It does not prove who the producer is: AER-1 revision 23 has no issuer authentication, origin is self-asserted, and the verify endpoint reports issuer authentication as not checked. Producer-stated fields, such as which AI ran a step or a payment amount, are claims the record carries, not facts the record establishes, beyond what is anchored. And it proves nothing about anything that was redacted, or about any work that happened outside the recorded steps. The live handover above prints the same limits about itself: outside timestamp, issuer identity, and result correctness, listed as not proven on its own page. A delivery record that names its limits on its face is making the strongest claim it honestly can: this run, these steps, this result, unchanged, with the gaps showing.

The format underneath: AER-1

Every receipt in a handover follows one open format: AER-1, IETF Internet-Draft revision 23 (draft-zambo-aer1-23). AER-1 is an IETF Internet-Draft, not a finalized standard. It defines the per-step verifiable receipt and the workflow record that links the receipts of a run, which is what lets a handover be checked by a receiver with no account on the system that produced it and no cooperation from the operator who ran the agent. Handover is the delivery pattern built on that format: records at execution time, redacted copies at publication time, recompute at receiving time.

To deliver your own agent's work this way: start with the live demo for a single checked call, read the Handover docs for the full flow, then a Zambo Day Pass for a day of calls with a verifiable receipt under each one and a handover at the end of the job.

Questions, answered

What is proof of delivery for AI work?

It is a delivery record the client can check instead of a summary they have to believe. When an AI agent finishes a job, proof of delivery means each step of the work carries a verifiable receipt, fixed at execution time, gathered into one link the client opens with no account. The client presses Verify all and the checks run in their own browser, against records that predate the handover, so an edited step, a dropped step, or a step that never completed shows up in the record instead of being smoothed over in a report. Zambo Handover is that record: one link, every step checkable, and an Accept or Flag answer that gets a receipt of its own.

How do I hand over AI work to a client?

Run the work through Zambo, so every step leaves a verifiable receipt as it executes. When the job is done, say: Use zambo to hand this over to your client, naming the client. Zambo gathers the session's receipts, redacts emails, phone numbers, and keys, and publishes redacted copies that point back to the originals, closed into one summary receipt. You send the client one link. They need no account and install nothing: they open the link, check the steps, and accept or flag the delivery. The full walkthrough is in the Handover docs at zambo.dev/docs/handover.

What does an AI work handover include?

One page with the whole delivery on it: the goal, every step with its verifiable receipt and its saved result, which AI ran each step where the producer states it, the delivered files, and a summary receipt that commits to the step list, the file list, and the unchecked list. It also carries a not checked list naming any step that did not complete, and a what this does not prove list. The page is the delivery and the evidence in one place, so the client never has to reconcile a summary in one message against files in another.

How does a client verify an AI delivery?

They open the handover link and press Verify all. The checks run in the client's browser: the root is compared against the published summary receipt, every step's publication copy is verified, the unchecked list and file list are matched against the summary, and each copy is tied back to the same summary receipt. Then the client can test the record themselves: the page lets them change one character in a step and watch that step fail its check, because the recomputed digest no longer matches the committed one. If everything holds, they accept in one tap, or flag the step that does not. Either answer is recorded with a receipt of its own.

What does a handover not prove?

It does not prove the work was correct or good: a receipt over a wrong answer verifies as cleanly as one over a right answer, because the commitment is to the saved result, not its quality. It does not prove who the producer is: AER-1 revision 23 has no issuer authentication, so origin is self-asserted, and fields the producer states, such as which AI ran a step or a payment amount, are claims the record carries, not facts the record establishes. And it proves nothing about anything that was redacted, or about work that happened outside the recorded steps. The live handover linked from this page lists its own not proven items: outside timestamp, issuer identity, and result correctness.

Freelancers ask the sharper version of this question: what is the best tool for proving freelance work was delivered? The main site answers it with buyer criteria, not a feature list.

Related