A trace is not an approval
A trace is the machine's diary, written by the system being judged. It can show every prompt, every tool call, every token, and still leave the liability question untouched, because approval is not something the machine did. An approval record needs four things bound together:
- The exact work: a fixed list of steps and outputs, closed so the set cannot be swapped later.
- A decider who is not the producer: the receiver named on the delivery.
- A decision: accept, or flag, recorded as an event, not inferred from silence.
- A time: recorded when the decision happened, attached to the same record as the work.
Bind them loosely and each can be edited separately. Bind them the way a handover does, and changing any one of them breaks the record in a way anyone can detect.
The approval record that exists today
Work done through Zambo leaves a verifiable receipt for every step. When the job is handed over, Zambo gathers those receipts, redacts emails, phone numbers, and keys, publishes redacted copies that point back to the originals, and closes the set into one summary receipt: the fixed body of work. The receiver opens one link with no account, presses Verify all to re-check every step in their own browser, can try to break a step, and then accepts or flags the delivery.
That accept is the approval record. It is the receiver's own action, never the producing agent's, and it mints its own receipt, pinned to the handover's original Merkle root, while the handover status flips to accepted. An agent on the receiving side can do the same through the handover_accept tool. The whole record, steps, unchecked list, and events list included, is readable by anyone on the page or in its JSON twin at /handover/<id>.json, which means an insurer's reviewer, a client, or a script can all read the same approval without asking the producer for anything. The mechanics are documented at zambo.dev/docs/handover.
Since the v5 publish, the record is also downloadable. On the client link for a decided handover, under the words "Approval record: who reviewed this AI work, when, and what was checked. Keep it with your files.", sit two downloads: Download approval record (JSON) and Download approval record (PDF). The JSON carries the reviewer's name and email exactly as entered, decided_at, the decision, the reviewer's note, the flag_reason when the decision was a flag, and one entry per step with its AI label, its checked status, and its receipt link. It also carries the rule on its face, as a statement field: "The acting agent cannot approve its own handover."
The export, and who can see it
The export lives on the client (token) link, not on the public page. The public no-token page withholds it on purpose: its approval card reads "Open the separate client link to download reviewer details." Reviewer details stay with the reviewer; the public record still shows the decision, the time, and the receipt, which is what a stranger needs to check the approval happened. The person the export names gets the file with their own details in it.
The export prints its identity limit too, in an identity_notice field: "Reviewer details are self-reported, not identity-verified." That is the same honesty as the handover event itself, one level down: the name and email in the file are what the reviewer entered, recorded and pinned to the decision, not verified against an identity document. Weigh it the way you would weigh a delivery slip with a name written on it: it evidences that the record was made, by the reviewer named on the delivery, at the recorded time.
Flags export the same way. A flag requires a reason: submit one without a message and the record refuses it, HTTP 400, "Flags require a message of at most 500 characters." With the reason, the decision exports as "flag" with the flag_reason carried word for word, so an objection is as portable as an approval.
One real acceptance, field by field
Handover 45434a17, accepted October 16, 2026
Open the record: the handover page and its JSON twin. The handover was created at 14:31:12 UTC holding four steps: live prices for BTC ($82,212.68), ETH ($2,472.76), and SOL ($106.17), fetched live that minute, plus a prompt_shield screen that came back safe. Its status reads accepted, and the events list shows the decision that put it there: action accept, recorded at 14:31:51 UTC, with its own receipt, 14cb8b21-d163-4c46-a692-b4947e3719ca, naming the original Merkle root of the work (002e64ec909f535c...). The approval cannot be detached from this work and reattached to other work, because the root it names is computed from this exact step list.
Now the limit, which the record prints on itself. The same event carries Zambo's notice, word for word: "Logged by Zambo on behalf of the visitor. Not identity-verified." Read that plainly: the record proves a decision was recorded against this exact work, at this time, from the receiver side of this delivery. It does not independently verify the legal identity of the person who tapped. An approval record that hides that limit would be worth less. This one carries it in the open, and a reviewer can weigh the record accordingly.
Why the agent cannot approve itself here
The producing agent's calls are the steps inside the record; they are the thing being judged. The Accept lives somewhere else, on the receiver's side of a link the producer does not control, and it creates a separate receipt from a separate action. So the two failure modes insurers worry about are answered structurally: an agent approving its own action would have to produce an event it cannot produce, and a missing approval is not a gap in the paperwork, it is the status, open, readable by anyone who opens the record. A flag is recorded the same way as an accept, with its own receipt, so objections are part of the record too, not a separate email thread.
This is not a policy statement; it was exercised. From the creating session, an MCP handover_accept call on its own handover comes back refused, code "forbidden": "Creator authority cannot accept this handover. Send the client link to its recipient." The web respond path under creator authority returns HTTP 403 with the same refusal. The approval can only be minted from the receiver side, and the export states the rule in the file itself: "The acting agent cannot approve its own handover."
Human-review evidence and the EU AI Act (Article 50)
Article 50 of the EU AI Act has applied since August 2, 2026, and the deployer-side transparency duties were not delayed. For AI-generated text published to inform the public on matters of public interest, the disclosure duty falls away where the content has undergone human review and a person or organisation holds editorial responsibility. That exception turns on a fact: a review happened, by someone accountable. If a regulator, a client, or an insurer asks later, the fact needs evidence.
A handover Accept is that evidence in portable form: the receiver named on the delivery, a timestamped decision, over a step list pinned by its root, kept where anyone can re-check it without an account. It fits the small end of the market, the freelancer, the SMB, the solo publisher, who has no compliance department to manufacture review evidence after the fact and needs it created at the moment the review happens.
Evidence is not compliance. Keeping this record does not make any workflow compliant with the EU AI Act or any other law, and nothing on this page is legal advice. Duties depend on your role, your sector, and your facts. What the record gives you is the thing duties like these ask you to be able to show: that a review happened, by the receiver named on the delivery, at a recorded time, over this exact work.
What to keep
Four things, and the packet is complete: the handover link, its JSON twin, the acceptance receipt id, and the approval record export (JSON or PDF) downloaded from the client link, which carries the reviewer details the public page withholds. Anyone reviewing later opens the link, runs Verify all, reads the events list, and holds the same record you hold. For the wider set of records an auditor asks for around agent work, see the auditor packet. And keep the limit with the packet: a verifiable receipt shows the saved result has not changed since it was recorded; it does not prove the result was correct, and the approval evidences a recorded decision by the named receiver, not an identity verification. Stated on the record, and stated here.
Questions, answered
What record proves a human approved AI work?
An approval record binds four things: the exact work approved, the decider, the decision, and the time. A Zambo handover Accept is that record. The work is a fixed list of steps, each a verifiable receipt, closed by a summary receipt. The decider is the named receiver on the delivery, acting from the receiver's side, never the producing agent. The decision, accept or flag, mints its own receipt pinned to the handover's original Merkle root, with the timestamp recorded in the events list, readable by anyone in the page or its JSON twin.
How do I prove to an insurer that a person reviewed the AI output before it went out?
Keep the handover and its acceptance. The delivery shows what the output was, step by step, with receipts a reviewer can verify in a browser. The acceptance event shows the decision, the time it was recorded, and its own receipt id, pinned to the same root as the work itself, so the approval cannot be detached and reattached to different work. State the limit when you hand it over: the record itself notes the visitor's identity was logged by Zambo, not identity-verified, so it evidences a recorded decision by the named receiver, not a biometric proof of who tapped. For the file itself, download the approval record from the client link (JSON or PDF): it carries the reviewer's name and email as entered, the decision and its time, any note or flag reason, and each step with its AI label, checked status, and receipt link.
Can an AI agent approve its own work, and how would I know if it did?
Not through the Accept. The producing agent's calls are the steps inside the record; the Accept is a separate action taken from the receiver's side of the delivery, and it creates a separate receipt. If no receiver ever acts, the status stays open for anyone to see. An audit of eight agent systems found only one that stops an agent approving its own action; in this design the separation is structural, because the approval lives on a page the producer does not control, and its absence is part of the record. The refusal is mechanical, not a promise: a handover_accept call from the creating session returns a forbidden error, and the web respond path under creator authority returns HTTP 403. The approval export prints the rule in the file itself: 'The acting agent cannot approve its own handover.'
How do I prove human review of AI-generated content?
Deliver the content as a handover and have the reviewer accept it on the record. The acceptance names the receiver on the delivery, carries a timestamp, and pins to the exact step list reviewed, so what was reviewed cannot be swapped afterward without breaking the record. Keep the link and the JSON twin with the published piece. That packet is evidence a review happened. It does not, by itself, discharge any legal duty, and it is not a compliance certificate.
Does the EU AI Act require proof that a human reviewed AI content?
Article 50 sets transparency duties for AI-generated content, in application since August 2, 2026. For text published to inform the public, the disclosure duty has an exception where the content has undergone human review and a person or organisation holds editorial responsibility. The Act asks for the review; being able to evidence it is what protects you when a client, an insurer, or a regulator asks. This page describes an evidence record, not legal advice, and keeping the record does not make any workflow compliant.
What exactly does the acceptance receipt pin down?
Four things: the handover it answers, the action taken (accept or flag), the time it was recorded, and the original Merkle root of the work, so the decision is bound to that exact step list. In the live example on this page, the accept was recorded at 2026-10-16T14:31:51Z, 39 seconds after the handover was created, with receipt 14cb8b21-d163-4c46-a692-b4947e3719ca. What it does not pin down is also printed on the record: the visitor's identity is logged by Zambo, not identity-verified, and the correctness of the work is not proven by anyone's accept.