ZAMBO.

Direct answer

Delivery is a record, not a memory of pressing send.

The message every freelancer dreads arrives weeks after the work: we never received it, or it was not what we agreed, or the files here are different. At that moment the proof you reach for is whatever the delivery left behind. A sent email and a drive link leave behind an argument, because both describe a delivery without fixing its contents: the email proves a message moved, and the link shows the files as they are today, which may not be the files as delivered. A delivery record is built differently. The outputs are saved into the record when the job runs, each step carries a verifiable receipt, and the client decision lands on the same record. This page builds that record step by step, and shows what to do when the dispute is already here.

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

Updated November 2, 2026. First published November 2, 2026. The two delivery records quoted below are real and public, with their client decision states read back from the live service on November 2, 2026.

Step 1. Fix the deliverable list before the work starts

Proof of delivery begins before delivery. Write the deliverable list where the client can see it: each item named, its format, and what done means for it. The list is the yardstick every later state is measured against, and it takes ten minutes at the start against hours of reconstruction at the end. When the client adds or changes an item mid-job, the changed list is the list, updated in the same place, so there is exactly one version of what was promised. Most delivery disputes are list disputes wearing a delivery costume: the work arrived, and the two sides are holding different lists. One shared list, updated in the open, removes that entire species of fight.

Step 2. Run the work so each step saves its own receipt

Work run through the Zambo endpoint, https://zambo.dev/mcp, returns a verifiable receipt on every call: 153 tools behind one endpoint, 36 on the default surface, no API key and no signup. The receipt follows AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, and it holds the step and the output as saved at run time. That timing is the whole mechanism. Evidence created during the work cannot be accused of being written up afterwards to suit the argument, because its check, at https://zambo.dev/verify/, recomputes whether the saved result still matches the record. For checking that does not rely on the issuing service at all, the public AER-1 conformance corpus at https://zambo.dev/aer1/corpus.json publishes 126 vectors and 129 checks for the format. The free tier is 20 calls + 1 wrap-up free every day; picking up in another AI is always free, which covers a normal client job's shape: a day of steps, then the wrap-up.

Step 3. Deliver the handover, and read its states correctly

The wrap-up seals the session into a handover: the deliverable list as executed, the steps, the outputs, and the decision state, at one address. Send the client that link as the delivery. Then read the record the way the client will:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

The accepted record is the closed job: delivered, checked, and decided, with the decision attributed and dated. The pending record is the exposed one, and it is far more common: work delivered and verified, and the client simply never recorded a decision, so months later either side can describe the state to suit itself. When your delivery sits in the pending state, the follow-up that matters is one line asking the client to record the decision on the handover. Do it while the work is fresh and the goodwill is warm.

Step 4. Answer a delivery dispute from the record, in one message

If the dispute arrives anyway, resist the thread. Send one message built from the record: the deliverable list as agreed, the handover link, the check state of the outputs, and the decision state, each in one line, and a single question at the end: which line is wrong. A dispute framed that way usually ends in the reply, because the client is no longer arguing with your memory, they are reading a record they can open and test. Where no record exists for the disputed job, build the nearest honest thing: the list reconstructed from the brief and the thread, the delivered files audited today through the endpoint so a dated verification exists, and the decision requested in writing. Then deliver the next job the way steps 1 to 3 describe, so the situation never repeats.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not prove the client read the delivery, liked the work, or owes payment under your contract, and it cannot retroactively record a job that ran without one. The record, the agreed list, and the written decision are what the conversation stands on. This page is general information, not legal advice.

Frequently asked questions

How do I prove I delivered the work to a client?

Deliver against a record and send the client the record, not a claim. When the work runs through Zambo, each job returns a verifiable receipt under AER-1, IETF Internet-Draft draft-zambo-aer1-26, and the wrap-up seals the session into a handover that lists exactly what was delivered, step by step, with the outputs as saved. Send the client the handover link, at zambo.dev/handover/ followed by its ID, and ask them to record their decision on it. The proof then has three parts the client can check without you: the deliverable list, the saved outputs with a passing check at https://zambo.dev/verify/, and the acceptance state on the same record.

Why is my sent email not proof of delivery?

A sent email proves a message left your outbox. It does not prove what the attachment contained on that day, because the file at the other end, or behind a drive link, can be replaced, edited, or lost and the email still reads the same. A link is weaker still: it points at whatever the file is today, not what it was at delivery. When a client says the work never arrived, or arrived different, the email timestamps the argument instead of settling it. A delivery record settles it because the outputs were saved into the record at delivery time and the check detects any later change.

What is the difference between delivered, checked, and accepted?

Three states, and confusing them is where delivery disputes are born. Delivered means the outputs were handed over. Checked means the record of those outputs passes verification: the saved result was not changed since it was saved. Accepted means the client recorded a decision on the record. A real public handover shows the full climb: status accepted, decided_by client, 4 of 4 steps checked, decided 2026-10-16T14:31:51.146Z, release_hint ok_to_release, at https://zambo.dev/handover/45434a17-4afc-486a-9646-e689bcee4297. A delivery that is checked but never accepted is unfinished, however good the work is, so close the decision in writing on the record.

The client already has the work and is disputing it. What can I do now?

Work with what was saved at the time, in this order. Gather the delivery record if one exists and check its state. Rebuild the deliverable list from the brief, the sent messages, and the files as delivered, and put the list in one message the client can answer line by line. Rerun the checkable parts of the job through the endpoint today (an audit of the delivered files, a comparison against the brief) so a dated, checkable record of the delivered state exists now, and present it as a verification dated today, never as a record of the original run. Then ask for the decision in writing. The pattern to avoid is arguing from memory in a long thread; disputes close on records, not on recollection.

What does it cost to deliver with proof built in?

The free tier is 20 calls + 1 wrap-up free every day; picking up in another AI is always free, and the endpoint is https://zambo.dev/mcp with no API key or signup. For $0.99, a Day Pass makes it unlimited for 24 hours, no subscription: get the Day Pass. One client job, delivered with its receipts and its acceptance on the record, is exactly a Day Pass shape. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.

Related