Direct answer

Hand the work over. The next pair of hands should not have to trust you.

Someone is leaving, going on leave, or handing a client job to the next person, human or AI. The usual handover is a chat summary and a folder of files, and it loses the same three things every time: what is actually done, what is still open, and any way for the receiver to check either one. Here is the handover that keeps all three.

See one before you build yours: open a real handover that a client checked and accepted, step by step, then run any receipt through the free verifier. No signup.

Updated October 20, 2026. Both records quoted below are real and public, with their decision states read back from the live service on publication day.

Why handovers lose the work

A summary is written from memory, and memory rounds in the writer's favor: nearly-done becomes done, the blocked step becomes a small note, the file that was never sent gets described as sent. The receiver then has two bad options. Trust the summary and build on a state that may not exist, or redo the checking from zero, which quietly doubles the cost of the job. Multiply that by every handoff in a team, every shift change, every "can you pick this up", and the losses stop looking like accidents. They are the format. A chat was never built to be a record of work.

What a good handover contains

Five things, and no story. The goal of the job, in a sentence or two of plain words. The steps, in the order they ran. What each step produced, attached or linked, never just described. The state of each step: done, open, or blocked, with the blocker named out loud. And the decision state: accepted, flagged, or not yet decided. If the receiver can start work from the record without sending you one question, the handover is complete. If they have to ask "wait, is this part done?", the handover is a summary wearing a record's clothes.

The receiver checks, then accepts or flags

The other half of a handover is the decision at the end of it. The receiver opens the steps, not the summary. Each step carries a verifiable receipt, so the checking takes minutes: what ran, what it produced, when it was saved. Then the receiver accepts the handover, or flags the one step that is wrong or missing. Flagging a step is not rejecting the job; it points at the exact place work remains, which is what makes it safe to accept a job mid-stream. And the decision is recorded against the record itself, so the state of the job is never again a matter of who remembers the meeting correctly.

Two real handovers

Accepted: the receiver checked it and signed off

Still open: the record waits for a decision

Both records run on the same format: AER-1, an open IETF Internet-Draft (draft-zambo-aer1-23). Open matters here. A handover locked inside one company's workspace can only be checked by that company's tool, on that company's say-so. A record in an open format can be checked by the receiver, the client, or a third party, with any tool that implements the draft, which is the difference between handing over work and handing over an assertion.

Handing over to another AI

Everything above applies twice when the next pair of hands is another AI: when a session ends, a limit hits, or a different model is simply better at the next step. A fresh AI has no memory of your job at all, so the record is not a courtesy, it is the whole transfer. The receiving AI picks up the handover, reads the steps and their receipts, and continues from the step that is actually open, instead of re-asking you what happened or confidently inventing it. The sister page on checking a false "done" covers the test to run before you trust the pickup.

When it goes wrong anyway

Sometimes the dispute comes later: the client says the job they accepted is not the job that was delivered, or a teammate insists a step was finished at handover that the record shows open. This is where the handover earns its keep a second time. The same record is the dispute pack: the steps, their outputs, the times they were saved, and the acceptance state, who accepted, who flagged, and when. It does not argue. It shows the state of the job as it was written down while the job was live.

What a handover record cannot do

A verifiable receipt proves the saved result was not changed since it was saved, and the record shows the acceptance state. It does not prove the work was good, and it does not prove who produced it. It cannot force a receiver to decide: a handover can sit pending, like the second record above, until a person accepts or flags it. And it only covers what ran through it: steps done outside the record are exactly as checkable as they ever were, which is to say, on trust.

Frequently asked questions

How do I hand work over to someone else and prove what was already done?

Hand over a record, not a summary. The handover lists the job as steps, attaches what each step produced, and marks what is done, what is still open, and what is blocked. Every step carries a verifiable receipt, so the person receiving it does not have to take your word for the state of the job: they open the record, check the steps themselves, and accept it or flag the specific step they dispute. Their decision is recorded against the record, so weeks later nobody has to reconstruct who agreed to what. When a job runs through Zambo, that record is built as the work happens and arrives as one handover link. The receiving side needs no account to check it.

What should a handover include?

Five things. The goal of the job in one or two plain sentences. The steps, in the order they ran. What each step produced, attached or linked, not described. The state of each step: done, open, or blocked, with the blocker named. And the decision state: whether the receiver has accepted the work, flagged part of it, or not decided yet. Leave out the story of the job; stories are where handovers go to blur. If the next person can start working from the record without messaging you a single question, the handover is complete.

How does the person receiving it check the work?

The same way you would check any delivery: open the steps, not the summary. Each step in the record carries a verifiable receipt; the receiver opens them, or runs them through the free verifier at zambo.dev/verify, and sees what ran and what it produced. Then they make the decision the record is waiting for: accept the handover, or flag the exact step that is wrong or missing. Flagging a step is not a rejection of the whole job; it is a pointer to the one place work remains, which is what makes mid-stream handovers safe to accept.

What if there is a dispute about the handover later?

The record is the dispute pack. It shows each step, what it produced, and the time it was saved, plus the acceptance state: who accepted, who flagged, and when, or that nobody has decided yet. Most handover disputes are really memory disputes, two people remembering different states of the same job. A record ends the memory part of the argument, because the state was written down as it happened rather than reconstructed afterward. What it cannot settle is taste: whether the work is good is a judgment, and the record's job is to make sure the judgment is about the real work.

What does it cost to hand a real job over this way?

Checking a handover is free, for anyone, at zambo.dev/verify. Creating one is part of running the job through Zambo: for $0.99, a Day Pass covers 24 hours of recorded work with handover links, no subscription: https://zambo.dev/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. The receipts follow AER-1, an open IETF Internet-Draft (draft-zambo-aer1-23), so the person receiving your handover can check it with any tool that implements the draft, not only ours.

Related