ZAMBO.

Direct answer

Same filename, five different files. The record, not the name, says which one left.

The client is quoting an old draft back at you: a paragraph you rewrote, a figure you corrected, a page you replaced two rounds ago. They are sure it is the final version, because it is the file sitting open in their folder with the right name on it. You are sure it is not, because you sent a later one. Both of you are arguing from the weakest evidence in the whole job: a filename, which every draft shared, and a folder, which keeps whatever copy happened to land in it. The question underneath the argument is narrow and answerable: which exact file left your hands as the delivery, and can a third reader check it. Here is how to answer it for this job with whatever traces exist, how to close the dispute without a memory contest, and how to deliver from now on so the file itself carries the answer.

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

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

Step 1. Stop arguing from filenames, folders, and timestamps alone

Three pieces of everyday evidence feel decisive and are not. The filename proves nothing, because final, final2, and the clean copy with the plain name are routinely the same string reused across rounds, and a client opening the file they saved first will see that round under the final name. The folder proves nothing, because folders hold the copy that was downloaded, forwarded, or saved by whoever touched it, and an old attachment saved over a newer one looks exactly like the newer one until it is opened and read. Even a timestamp only shows when a copy was written to that machine, not which contents it carried or who sent it. None of this means the client is acting in bad faith. Most version fights are two honest people holding two different files that present themselves identically. Accepting that framing is what lets you move the argument to ground where it can actually be settled: content, compared against a record of what was delivered.

Step 2. Reconstruct this delivery from its traces, and label what each trace can and cannot show

Work through the traces in order of strength. The sent message itself, with its attachment, is the strongest everyday trace: open your own sent copy, not a fresh export from your project folder, and read the exact file you attached. Its contents are what left your hands in that message, whatever you later edited at your desk. Next, the delivery message wording: the round number, the list of changes it announces, the date. A message that says round three, with the pricing page corrected, sitting above an attachment whose pricing page is the old one, tells its own story in either direction, so read them together. Next, size and page count differences between the copies in dispute, which often separate drafts faster than reading does. Then the acceptance trail: what did the client reply to, quote from, or approve after that delivery. Be honest about the ceiling of this reconstruction. Traces can usually show which contents were attached to which message. What they rarely give you is a copy the client can independently check, sealed at delivery time, which is why step 3 matters and why the fix in step 6 exists.

Step 3. Read the two states a delivery can sit in when its version is disputed

A version dispute is settled by whether the delivery sits on a record that binds the exact delivered step to a checkable receipt, or inside two folders. The record format is AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-26), and each step carries a verifiable receipt: a receipt proves the saved result was not changed since it was saved. The two public records below show the states a delivery can carry:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

An accepted record, 4 of 4 steps checked, decided_by client, release_hint ok_to_release, decided 2026-10-16T14:31:51.146Z in that example, is the strong shape: the delivery the client received is a set of named steps, each with its own receipt a stranger can open, and the client checked those steps and accepted them on a date. A claim that some other file was the final version has to explain away a checked and accepted record of a different one. A pending record, 5 of 5 steps checked and release_hint hold, shows the exposed middle: the delivery exists as checked steps, so its contents can still be pointed to exactly, but no decision was ever recorded on it, and a version argument grows in exactly that gap. If your current job sits in neither shape, with delivery by loose attachment and no record at all, step 4 is written for you.

Step 4. Settle this dispute by comparison, then re-deliver the agreed final on a record

Send one calm message built on comparison, not accusation. Name the two files by their contents, not their names: the copy you are working from contains the old pricing on page three, the copy I delivered on the stated date contains the corrected pricing, and here is the passage that differs. Attach or link your sent copy, and invite the client to open their copy at the same passage. Most version fights end at this moment, because the difference, once located in the text, is undeniable and face saving: nobody lied, an old file was simply open. Then close the hole the fight fell through. Re-deliver the agreed final version once, cleanly, as the delivery of record, with a message that says this file, delivered today, supersedes every earlier draft, and keep that delivery where both sides can point to it later. If money or rework hangs on which version was live during a period, date that settlement in the same message, so the comparison you just won cannot quietly reopen next month.

Step 5. Sort any rework the old draft caused by who was working from what

Sometimes the client, or their team, has already done work on top of the old draft: comments, edits, approvals of sections that no longer exist. Sort that pile before pricing any of it. Work they did on the old draft in good faith, before anyone spotted the mix up, is a shared accident, and the fair handling is to carry their usable comments across to the final version yourself where they still apply, because the comments were the point, not the file they were pinned to. Work that has to be redone because it only made sense against the superseded text is priced by cause: if your delivery made the mix up easy, loose naming, several attachments in flight, no superseding message, absorb more of it; if the final was delivered clearly and the old file was kept alive on their side against the record, the redo is a change with a price. Either way, write the sort down. A version accident handled with a written sort and a clean re-delivery strengthens the relationship. The same accident handled as a blame contest costs the client even when you win it.

Step 6. Deliver so the exact file is the record from now on

The durable fix is to make delivery an event with a record, not an attachment with a hope. Deliver each round as a step in a handover the client picks up, so the file that left your hands is the saved result of that step, carrying a verifiable receipt, and the client checks and accepts that exact version rather than a copy of it that drifted into a folder. Name versions inside the record where both sides can see the sequence, round and date, and let the record be the one place the current final lives; attachments can still travel for convenience, but they stop being the evidence. When a later round supersedes an earlier one, it lands as a new step on the same record, so the history shows the old draft, the final, and the order they arrived in, which is the whole anatomy of this dispute, answered in advance. The next time a client opens the wrong file, and someone will, the reply is one link and one sentence: here is the delivery, check the step, that is the file that left my hands.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not prove which file is open on the client's screen, rewrite a delivery that was never recorded, or decide a contract question about which version a client was entitled to rely on. The delivery record, the sent copy, the acceptance, and your written comparison are what this conversation stands on. This page is general information, not legal advice.

Frequently asked questions

My client is working from an old draft and insists it is the final version I sent them. How do I prove which file actually left my hands?

Prove it by contents against the delivery, never by filename. Open your own sent copy, the exact attachment on the delivery message, and locate the passages where the two files differ: the corrected figure, the rewritten section, the replaced page. Send the client that comparison, passage against passage, with the delivery date, and invite them to open their copy at the same place. If the delivery ran on a record, the answer is stronger still: point to the delivery step itself, whose saved result carries a verifiable receipt, and to the acceptance state recorded on it. Then close the dispute the same day by re-delivering the agreed final version once, in a message that states it supersedes every earlier draft, so the settled answer is itself on record. Most version fights are an old file honestly mistaken for the final one, and a content comparison ends them without anyone having to lose an argument about memory.

The client says the file in their folder is the one I sent. Could they be right?

Yes, and checking that possibility first is what makes your answer believable. Deliveries do go wrong at the sending end: the wrong attachment picked from a folder of near identical names, an earlier round sent twice, a corrected file saved but never actually attached. Open the sent message and read its real attachment before you answer, not the project folder copy you believe you sent. If the trace shows the old draft genuinely left your hands, own it in one sentence, re-deliver the final immediately, and carry across any work the client did on the wrong file where it still applies. That admission, made early and without being cornered into it, costs you an afternoon. The same admission extracted after a week of insisting costs you the client's trust in every other record you keep.

We never used any record system for this job. What is my best evidence now?

Your sent items, read carefully. The attachment on the actual sent message is the closest thing to the file that left your hands, and the message text around it, the round named, the changes announced, either supports it or exposes a mismatch. After that, the client's own behaviour: passages they quoted back, comments pinned to the new text, approvals given after the delivery date, all show which contents reached them. Put the strongest two or three traces in one short message with the content comparison from the first answer here, and be plain about what is reconstruction rather than a sealed record. Then make the settlement itself the first recorded act: the agreed final, re-delivered on a record both sides can check from that day forward. An honest reconstruction plus a recorded settlement settles this job and starts the next one on better ground.

How should I name and send versions so this cannot happen again?

Three habits, all cheap. Give every round a name that carries its round and date inside the delivery itself, not just in a filename the client can save over. Send each round as its own delivery with a short message listing what changed, so the announcement and the file can be checked against each other later. And keep one place where the current final lives, a delivery record the client picks up and accepts, so superseded drafts are visibly superseded steps in a sequence instead of identical files scattered across two folders and an inbox. Filenames alone will always fail eventually, because every tool in the chain, mail, chat, shared drives, treats a same named file as the same file. A recorded sequence does not have that failure mode.

How do I deliver a file so its identity can be checked later?

Deliver it as a step on a record instead of a loose attachment. When the work runs through Zambo, the delivery is saved as a step in a handover with a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, so the exact result that left your hands can be opened and checked later, and the client accepts that version on the record. New users get 20 calls and 1 wrap-up free every day, and picking up work in another AI is always free. For $0.99, deliver the next contested file that way and make its identity a link instead of an argument: get the Day Pass. A Day Pass is unlimited for 24 hours, no subscription. 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