ZAMBO.

Direct answer

A screenshot shows a screen. A receipt shows the work.

The screenshot is the default proof of AI work because it is the easiest thing to make, and it fails for exactly that reason. Anyone can produce one, crop one, stage one, or edit one, and the image itself carries no way for the reader to test it. When the proof actually gets challenged, by a client holding back payment, a platform reviewing a dispute, a manager who was not in the session, the screenshot collapses into your word plus a picture. The alternatives below are ranked by what they survive: who controls them, whether they record steps and outputs or only activity, and whether the person receiving the proof can check it without trusting the person sending it.

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 delivery record quoted below is real and public, with its decision state read back from the live service on November 2, 2026.

Alternative 1. The chat export: better organised, same owner

Exporting the full conversation beats a cropped screenshot: the reader sees the request, the run, and the result in sequence. Its weakness is custody. The export is a file you generated from your account, and every reader knows a text file can be edited before it is sent, with no trace. It also buries the deliverable inside the wandering of the session, so the reader has to mine the thread for the output that counts. Use chat exports for context and collaboration. Do not rest a payment, a dispute, or an audit on one, because the person it must convince controls neither its creation nor its checking.

Alternative 2. The platform work diary: activity, not output

Marketplace work diaries and time trackers add timed screenshots and activity counts, which feels like surveillance-grade proof. Read closely, they prove a person sat near a keyboard while a screen changed. They do not record what an agent executed, which tools it called, or what it returned, and the whole record lives inside one platform: close the account or leave the marketplace and the evidence goes with it. For AI work the mismatch is worse, because the agent does the executing while the diary watches the human. It is proof of attendance dressed as proof of work.

Alternative 3. The shared document: a result with a history someone owns

A delivered document with version history is real evidence of a result evolving, and for writing and design work it answers many questions. Its limit is ownership: the history is kept by the platform and controlled by the document owner, versions can be copied into a fresh document with a clean past, and the history shows the artifact changing, not the agent steps that produced each change around it. Keep using shared documents as the delivery vehicle. The mistake is asking the vehicle to also be the record of execution.

Alternative 4. The verifiable receipt: proof the receiver can run

The receipt changes who creates the evidence and who can check it. The executing system issues it at run time, under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26. It holds the steps of the job and the outputs as saved, and the receiver opens it at its own address, https://zambo.dev/run/ plus the receipt ID, or rechecks it at https://zambo.dev/verify/, with no account and no copy supplied by you. Work run through the Zambo endpoint, https://zambo.dev/mcp, returns one of these on every call across 153 tools. The check answers the only question a screenshot never can: does the record still match what was saved when the job ran. For independent checking, the public corpus at https://zambo.dev/aer1/corpus.json publishes 126 vectors and 129 checks for the format.

What the delivery version looks like: one real record

Receipts cover jobs; the handover covers the delivery, and it is the handover that replaces the screenshot bundle in a client thread. The two public records below show the states a delivery can sit in, read back from the live service:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

Send the client the link to a record in the first state and the conversation about proof is over: the steps are checked, the decision is recorded, and the reader verified it personally. A record in the second state is the honest warning: the work is checked and still undecided, so the next move is to get the decision recorded, not to send more screenshots.

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 work was good, the brief was understood, or the price was fair. It replaces the argument about evidence with the argument about quality, on a record both sides can read. This page is general information, not legal advice.

Frequently asked questions

What are the alternatives to screenshots as proof of AI work?

Four, in rising order of strength. A chat export shows the conversation but is text you control and can edit before sending. A platform work diary adds timed captures, but it proves activity on a screen, not the outputs a job returned, and it dies with the platform account. A shared document with version history shows a result evolving, while the history belongs to whoever owns the document. A verifiable receipt is the strongest: the executing system issues it at run time under AER-1, IETF Internet-Draft draft-zambo-aer1-26, it holds the steps and the saved outputs, and the receiver rechecks it at https://zambo.dev/verify/ instead of trusting a copy you sent.

Why do screenshots fail as proof?

A screenshot is an image of a claim. It can be cropped to hide the step that failed, edited in any image tool, staged from a session that never delivered anything, or taken from a different job entirely, and nothing in the image lets a reader test any of that. It also shows the surface at one second: the chat saying done, not the steps the agent ran or the outputs it saved. The moment proof matters, in a dispute, a chargeback question, an audit, the screenshot asks the other side to take your word with a picture attached. Every alternative on this page exists to remove that ask.

What should I send a client instead of screenshots?

Send the receipt link for the job and the handover link for the delivery. The receipt, at zambo.dev/run/ followed by its ID, opens the job record: steps, saved outputs, and check state, readable with no account. The handover carries the session as one record, including which steps were checked and whether the client side accepted the delivery. A real public example: one handover record shows status accepted, decided_by client, 4 of 4 steps checked, decided 2026-10-16, at https://zambo.dev/handover/45434a17-4afc-486a-9646-e689bcee4297. The client checks the record itself rather than grading your screenshots.

Does a verifiable receipt prove the work was good?

No, and it does not claim to. A receipt proves the saved result was not changed since it was saved: the steps and outputs in the record are the ones the job returned. Whether the work was good is judged by reading those outputs, running the tests, and applying the acceptance criteria, the same judgment as any delivery. What the receipt removes is the preliminary fight about what the agent did and whether the evidence was edited on the way to the reader. Quality arguments happen on the record, with both sides looking at the same saved outputs.

How do I switch from screenshots to receipts?

Run the work through the Zambo endpoint, https://zambo.dev/mcp, and every job returns its verifiable receipt as it runs; send the receipt and handover links in place of screenshots from the next delivery on. The free tier is 20 calls + 1 wrap-up free every day; picking up in another AI is always free. For $0.99, a Day Pass makes the endpoint unlimited for 24 hours, no subscription: get the Day Pass. 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