It worked at delivery is not a defense. Here is the record that shows what changed, and when.

Step 1. Name the real question hiding inside the message

"It stopped working" sounds like a bug report. It is almost never one. The client is asking three questions at once: what state was this in when I accepted it, what changed between then and now, and which side of the handover did the change happen on. If you answer those three from memory, the conversation becomes your recollection against their frustration, and the person who delivered the work loses that argument by default. If you answer them from the delivery record, the conversation is over in one reply, because the record is not your version of events. It is the job as it was saved, step by step, while it ran.

Step 2. Start from the accepted baseline, not from the delivery day

Every Zambo job closes as a handover: the steps that ran, the verifiable receipt for each step, and the client's own accept or flag decision recorded on the page. That accepted state is your baseline. It is not "the version I think I shipped." It is the exact set of steps and results the client looked at and signed off, each one bound to an AER-1 receipt that proves the saved result has not changed since it was saved. Anyone can recheck a receipt for free at zambo.dev/verify, including the client, including you, including a third freelancer neither of you has hired yet.

Step 3. Walk the record forward until the two states split

Work that runs through Zambo keeps landing on the same record. A fix you shipped in week two is a step. A settings change the client's team made is visible the moment it runs through the endpoint. A step that ran somewhere else entirely is visible too, as a gap: the record shows the accepted state, then nothing, then a different state, and the gap itself is the finding. Walk from the baseline forward and mark the first step where the live state and the recorded state no longer match. That step, and only that step, is the conversation. Everything before it is proven history. Everything after it is consequence.

Step 4. Sort the break into three piles

The split lands in one of three piles. Your change: a step on the record after sign-off altered the behavior, and the receipt shows it, so you own the fix and the client watches you own it. Their change: the record shows the accepted state intact and a later change on their side, a reconnected account, a swapped key, an edited prompt, and the argument ends without anyone being accused of anything. Outside change: the record is intact end to end and the thing that moved is outside the job, a platform update, an expired credential, a provider outage, and now you are both looking at the same third party instead of at each other. Three piles, three different replies, and none of them starts with "trust me, it worked when I delivered it."

Step 5. Answer in writing, with the links in the message

The reply that ends this thread is short because it carries proof instead of tone. One line stating the accepted baseline and its date. One line naming the step where the states split and which pile it falls in. The handover link and the receipt link, so the client checks both in seconds without asking you for anything. A client who can check the record themselves stops treating every fault as a negotiation, because the record answers faster than suspicion does. This is the whole reason the handover stays living after delivery instead of freezing into a PDF in an inbox: the questions arrive weeks later, and the record has to still be standing there when they do.

Step 6. Put the fix on the same record

When you repair it, run the repair through the same job record. The fix becomes new steps with new receipts, the client accepts the repaired state on the same page, and the handover now tells the whole story: delivered, accepted, changed, split, fixed, accepted again. The next time anything moves, and something always moves, the walk from baseline takes minutes. Freelancers who hand over records instead of files find that the post-delivery weeks get quiet, not because clients stop having problems, but because every problem arrives with its own answer attached.

What a record does not settle

A receipt proves the saved result was not changed since it was saved. It does not prove the original work was good, the strategy was right, or the automation deserved to be built. Judgment stays human, on both sides. What the record settles is narrower and, in a dispute, decisive: what ran, in what order, producing what, accepted by whom, and what changed after. Most post-delivery fights are not really about quality. They are about state, and state is exactly what a record settles.

Frequently asked questions

Can my client check the delivery state themselves, without me?

Yes. The handover page for the job is one link. The client opens it, sees the steps in order, and checks any step's AER-1 receipt against the saved result it names at zambo.dev/verify, free, in seconds. They are checking the record, not your summary of it, which is why the answer holds up when a conversation gets tense.

What if some of the work was changed outside Zambo?

Then the record shows an honest gap: the accepted state, a silence, and a different state. The gap does not tell you what happened inside it, and you should say exactly that. It still settles the question that matters commercially, which is that the accepted delivery was intact at sign-off and the change happened after and elsewhere.

Who owns the accounts and keys the automation runs on?

Write it into the handover at delivery: each account, key, and connection the job depends on, named with its owner. The most common post-delivery break is a credential the client owned expiring or being revoked by someone on their team who never knew the automation used it. A record that names ownership turns that week-long blame thread into a five-minute check.

What should I send the moment a client says it stopped working?

Send the baseline and the split point, not an apology essay. The accepted handover link, the receipt for the step where the live state first differs, and one sentence saying which pile the change falls in. If you cannot find a split because the record is intact, say that and name the outside suspects. Every hour spent reconstructing state from chat threads is an hour the record would have given you for free.

How do I hand over work so this never happens on the next job?

Run the job through Zambo from the first step, at zambo.dev/mcp, and close it as a handover the client accepts on the page. Every step carries a verifiable receipt under AER-1, the standard Brennan Zambo authored and published as IETF Internet-Draft draft-zambo-aer1-26, and the record stays living after delivery. The full checklist version is the freelancer client handover page on this hub.