The hole in the usual AI work agreement
Standard clauses name the deliverable as a file, a report, a build. For human work done in shared tools, the file's history does quiet evidentiary work: versions, timestamps, comments. AI work breaks that quietly. The file arrives, but the process that produced it ran inside the seller's session, and the contract never asked for the process to be recorded. When the buyer hesitates, there is nothing to point at except the seller's account of their own work. The fix is not more legal weight on the same definition. It is a different definition of delivery, one the record system can actually produce.
The five clauses
Clause 1: The record
"All work under this agreement is performed through a connection that saves a verifiable receipt for every call at the time the call runs. The receipts, not any later summary, are the record of the work."
Why it matters: evidence created during the work, by the system, beats evidence written after the work, by a party. This clause is what makes the other four possible.
Clause 2: Delivery defined
"Delivery occurs when the seller sends the buyer a handover link containing the goal and one receipt per step of the work. A summary, screenshot, or file transfer without the handover link is not delivery under this agreement."
Why it matters: delivery becomes an event both sides can point to, with a timestamp, instead of a feeling that the work probably arrived.
Clause 3: The acceptance test
"The buyer may open any step receipt in the handover and verify it. The buyer accepts by recording acceptance on the handover; the acceptance state then reads accepted, decided by the client, with the count of steps checked. Payment for the work releases on acceptance. Until acceptance, the state reads pending and no payment is due for unaccepted steps."
Why it matters: acceptance stops being a vibe in a chat thread. It is a recorded decision, made by the only side entitled to make it, sitting next to the work it covers.
Clause 4: Gaps count as undelivered
"A step with no receipt in the handover is undelivered for that step. Where a step records the sources it checked, each source reads resolved, not_resolved, or not_checked as recorded, and neither party may restate those states."
Why it matters: this is the clause that ends the smoothed-over narrative. Missing work cannot be narrated into existence, because the packet shows the hole.
Clause 5: The honest limit, accepted by both sides
"The parties agree that a verifiable receipt proves the saved result of a call has not changed since it was saved. Receipts do not prove the work was correct, complete in judgment, or fit for a purpose; quality is judged by the buyer against the record, and disputes are argued from the record, not from recollection."
Why it matters: a clause that overclaims gets thrown out with the argument. This one claims exactly what the system does, which is why it holds.
The acceptance test, worked on a live record
Clause 3 is not abstract. Handover 45434a17 delivered four steps, and its acceptance record at acceptance.json shows the fields the clause names: status accepted; decided_at October 16, 2026; decided_by client; steps_checked four of four; release_hint ok_to_release. It also carries its own scope line, which the contract inherits honestly: "Receipt bytes only; not accuracy or human review of every step." A buyer performing clause 3 opens that address, reads those fields, and the acceptance question is answered by the record both parties agreed in advance to trust.
What these clauses cannot do
- They cannot record work that never runs on the connection. If the seller does part of the job elsewhere, clause 4 prices that part as undelivered. The contract cannot reach into tools it never named.
- They cannot judge quality for you. The record settles what ran and what it returned. Whether that is worth the fee is the buyer's call, made against evidence instead of memory.
- They do not move money. Zambo never holds either side's funds. Escrow, milestones, and payment rails stay in the parties' own arrangements; these clauses define the evidence those arrangements trigger on.
- They are not legal advice. They are a working template from the people who run the record system. Jurisdictions differ; have counsel review before relying on any agreement.
Questions, answered
How do I write a contract for AI work so delivery can be verified?
Define delivery as a record instead of a description. The clauses on this page do it in five moves: the work runs on a connection that saves a verifiable receipt for every call; delivery is the handover link carrying the step receipts, not a summary or a screenshot; acceptance is the buyer's recorded decision on that link, and payment releases on acceptance; a step with no receipt counts as undelivered; and both sides accept the honest limit, that receipts prove the saved results have not changed since they were saved, not that the work is correct. With those five clauses, a delivery dispute stops being two memories arguing.
What exactly counts as delivery under these clauses?
The handover link, openable by the buyer, with every step of the work carrying its own receipt and timestamp. If a step ran, its receipt is in the packet. If a step has no receipt, the contract treats that step as not delivered, whatever the summary says. The acceptance record for the packet sits at a fixed address next to the handover, so both sides read the same state: pending until the buyer decides, accepted when they do.
What if the seller says their tools cannot produce receipts?
Then this contract cannot be performed as written, and that is useful information before money is committed, not after. The seller can run the work on a connection that records it, or the parties can strike the clauses and knowingly accept story-based delivery, priced as the risk it is. What the clauses prevent is the middle state: a contract that assumes verifiable delivery from tools that never produce it.
Do these clauses replace escrow or milestone payments?
No. They define the evidence the milestones are judged against. The money mechanics stay whatever the parties choose: escrow, milestones, payment on acceptance. Zambo never holds either side's money. What changes is the trigger: instead of delivery meaning a file arrived and a summary sounded right, it means a record exists that both sides can open, and the buyer's acceptance of that record is what releases the payment.
What does the recording setup cost?
The receipts come with the connection the work runs on. For $0.99, run the first delivery under the contract as a record these clauses can actually bite on: get the Day Pass. A 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. The clauses themselves are on this page to copy. This page is a practical template written by the people who run the record system, not legal advice: have your own counsel review any agreement before you rely on it.