My Client Won't Pay Until They Can Check the Work. Good. Here's the Packet I Send.
The handover packet that releases payment: every step a receipt, sources counted honestly, an acceptance record the worker cannot approve on its own.
# My Client Won't Pay Until They Can Check the Work. Good. Here's the Packet I Send.
A client who has been burned by AI output does not have a trust problem. They have an evidence problem, and it is rational. They paid once for a deliverable that read beautifully and fell apart under the first real question. Now every "done" gets held at the door, and payment waits for a check that a summary email cannot survive.
So the packet changed. What goes out the door now is not a summary of the work. It is the record of the work, built so the client can check it without asking permission and without taking anyone's word. Here is exactly what is in it.
The anatomy of the packet
Every step, as a receipt. The job runs through Zambo, and each step writes a verifiable receipt at call time: the call, the result, hashed as it happened. The packet is those receipts in order, behind one link. Nothing in it was typed up afterward.
What was not checked, listed. A packet that only shows successes is a highlight reel. The handover page names what did not run or was not checked, in its own section. On the two live packets below, the unchecked count is zero, and the record prints the zero instead of leaving the question open.
Sources, counted as numbers. When a job cites outside sources, the acceptance record carries a rollup: how many sources resolved, how many did not, how many were not checked. A source that fails prints as not_resolved. It is never silently dropped to make the counts prettier. On the two packets below the rollup reads zero across the board, because neither job cited outside sources, and the record says that plainly too.
The acceptance record. The packet closes with the decision surface: Accept or Flag, one tap, no account. The decision is written into the record with who decided and when, and it carries the release state the invoice depends on.
A lock the sender cannot pick. The agent that did the work cannot accept its own packet, and neither can the account that created the handover. The attempt comes back refused, in plain words: "Creator authority cannot accept this handover. Send the client link to its recipient." The approval has to come from the other side of the desk or it does not exist.
Two packets, two states
Both of these are live records, readable right now.
The first, https://zambo.dev/handover/45434a17-4afc-486a-9646-e689bcee4297 , is a four-step audit job. Its acceptance record reads: status accepted, decided by client, decided October 16, 2026, all four steps checked, release state ok_to_release. That is the packet in its released state: checked, judged, cleared for payment.
The second, https://zambo.dev/handover/bd7e5325-33fd-4c5e-b029-76b781fa2f51 , is a five-step job whose client has not decided. Status pending. Decided by: nobody yet. Release state: hold. The record does not nudge that into softer language. Until the client checks the work and accepts, the packet says the money does not move, because the work is still unproven.
The release rule
That is the whole discipline, and it fits in one line: pending means hold, accepted means ok_to_release.
Freelancers and agencies can feel the difference immediately. There is no chase email, no "just following up on the invoice," no argument about what the summary meant. There is a link, a check the client runs in their own browser, and a decision that either releases the payment or names what got flagged.
The packet also changes when the conversation happens. The check runs before the invoice is due, not after it is disputed. A flag lands while the job is still warm, with the step it objects to named in the record, instead of surfacing three weeks later as an argument about a summary nobody can reconstruct.
The fastest way to feel the difference is to watch a packet assemble itself. The live demo at https://zambo.dev/demo/ runs a real job and produces the record on the spot, receipt by receipt, the same record a client would open.
What it costs, plainly
Public handovers are free. Private links, your own branding, and PDF and JSON export come with the Zambo Pass at $29 per month. The receipts underneath are AER-1, an open format published as an IETF Internet-Draft (draft-zambo-aer1-23), and they verify offline, so the client's check never has to trust Zambo's server to vouch for Zambo's records.
For agent-to-agent delivery, where one AI hands its work to another instead of to a person, the same packet mechanics are written up here: https://rambozambodotdev.gitlab.io/aer1-hub/agent-to-agent-handover.html
The honest limits
The packet proves the saved record of the work was not changed since it was saved. It does not prove the work was right. A client can check every receipt, find the record intact, and still flag the job, and the packet treats that as a legitimate outcome, because the judgment was always the client's to make. What the packet removes is the argument about what was delivered. What was delivered is the record. The record is checkable. The rest is a business decision, made on evidence instead of on faith.
Your AI said "done." For $0.99, prove it: https://zambo.dev/day-pass/