ZAMBO.

Direct answer

They lost it. Resend the delivery, not a recreation.

Months after the job closed, a message arrives: the files are gone. A laptop died, a drive was wiped, the person who filed them left, and can you resend everything. The friendly answer is yes, and the careful answer is yes, from the record. What you resend matters more than how fast you send it. A fresh export, a rebuilt folder, or the newest version off your own machine can quietly differ from what was delivered and accepted, and then a simple favour has reopened the whole job: new files, new questions, new scope. The delivery record is the list of what actually changed hands, in what form, on what date, and in what state of acceptance. Resend exactly that, name it as a resend of that delivery, and log the resend itself. Here is the order.

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 two delivery records quoted below are real and public, with their client decision states read back from the live service on November 2, 2026.

Step 1. Find the delivery before you touch any files

Start from the record of the original job, not from your folder structure. What was the deliverable list: names, formats, versions, sizes if you have them. When was it sent, and through what channel. Was it accepted, and by whom, and did anything ride on that acceptance, final payment, rights transfer, admin access. If your delivery lives on a record like the ones in step 3, this takes minutes: the steps, the outputs, and the decision are in one place. If it lives in an old email thread and a chat window, reconstruct the list from those before you send anything, and write it down. The list is the resend. Anything you cannot place on the original list does not go in the package, however helpful it feels, because a resend that adds material is a new delivery wearing a favour's clothes.

Step 2. Resend the exact delivered copy, not a fresh version

Send the files as they were delivered: the same versions, the same formats, the same names. Resist three temptations. Do not regenerate exports from the source files, because a newer tool version, a changed setting, or a font update can alter the output in ways neither side notices until someone compares. Do not tidy, rename, or improve anything on the way out; an improvement sent silently becomes the new baseline, and the next conversation is about why the work changed. Do not include your raw working files unless they were part of the original delivery; they are a separate item with separate terms. If the exact delivered copy no longer exists on your side either, say so plainly in the resend message, name what you are sending instead and how it differs, and let the client accept the substitute in writing. A named substitute is honest. A silent substitute is a future dispute.

Step 3. Read the two states the original delivery can sit in

A resend months later is only simple if the original delivery was saved in a form whose contents can still be checked. 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, gives the resend its reference: this is the work, in this state, that the client side already checked and closed. The resend is a copy of a closed thing, and the acceptance travels with it, so nobody needs to re-approve the job because the files moved twice. A pending record, 5 of 5 steps checked and release_hint hold, is the exposed shape: the work was checked but never decided, so a resend can blur into a fresh delivery and a fresh review. There, attach one line to the resend asking the client to record the decision on the resent copy, accepts it as the delivery of record, so this favour also closes the job it came from.

Step 4. Send it once, as a named resend, with a small cover note

The cover note does the quiet legal work of the whole favour, in four short lines. Line one: this is a resend of the delivery of the stated date, at the client's request because the originals were lost on their side. Line two: the contents match the original delivery, item by item, with any named substitute flagged. Line three: the resend changes nothing about the job's terms, acceptance, or payment state; it is the same delivery arriving a second time. Line four: please confirm receipt, and keep the files in a place the team can reach, ideally a shared store rather than one person's machine. Send the package once, through one channel, and keep your own copy of exactly what you sent, with the date. If the client asks again in another few months, you resend from that saved resend package, not from a new reconstruction, so every copy in the world traces back to the one delivery.

Step 5. Price the pattern, not the first favour

A first resend of a finished job is normally a courtesy: minutes of work, goodwill earned, no invoice. Say so, and say the boundary in the same message, kindly and in writing: resends and archive retrievals after this one are a small paid service, or covered if the client takes a support arrangement. The boundary matters because of what an unbounded resend promise becomes: your archive turns into the client's filing system, every lost file is your emergency, and each rescue gets less careful than the last. If the client is a repeat loser of files, offer the structural fix instead of the fee: at delivery, the files go into a shared location the client controls, with the delivery record linked from it, and your copy becomes the backup rather than the only copy. Charge for retrieval time when the hunt is long, an old drive, a dead account, a format conversion, because that is work, and name the charge before you start it.

Step 6. Set delivery up so a lost file is a link, not a rescue

Three habits close this hole for every future job. One: deliver against a record that lists the outputs and their acceptance, so months later the question what exactly did we receive has a one-link answer. Two: keep your own archive of the delivered copy, untouched, separate from your working files, for as long as you keep any client archive at all; the delivered copy is the one thing you never edit in place. Three: hand over into the client's own shared storage, with the file names from the delivery record, and note in the closing message where the delivery lives on their side. Do those three and the lost-files message, when it still comes, gets answered in minutes with the record link and the identical package, and the job stays as closed as the day it was accepted.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not store the client's files for them, cannot recover a copy that no longer exists anywhere, and does not decide who pays for retrieval work. The delivered copy you kept, the delivery record, the acceptance, and your written resend note are what the conversation stands on. This page is general information, not legal advice.

Frequently asked questions

My client says they lost the files I delivered and wants me to resend everything months later. What do I do?

Resend from the delivery record, not from memory. Rebuild the original deliverable list first: names, formats, versions, delivery date, and acceptance state. Then send the exact delivered copy, unchanged and unrenamed, with a short cover note stating that this is a resend of that dated delivery at their request, that the contents match the original item by item, that the resend changes nothing about acceptance or payment, and asking them to confirm receipt and file it in shared storage. Keep your own copy of exactly what you resent. A first resend is normally a free courtesy; say in the same message that later retrievals are a small paid service, and if the exact delivered copy no longer exists on your side, name the substitute and how it differs instead of sending it silently.

Should I charge for resending files?

Not for the first simple resend, and yes for the pattern. A resend that takes minutes from a tidy archive is goodwill, and charging for it buys resentment at a bargain price. Charge, or cover it under a support arrangement, when retrieval becomes work: hunting old drives, reviving dead accounts, converting formats, or repeating the rescue for a client whose filing system is your inbox. The rule that keeps it friendly is to state the boundary in the first resend message, before any fee exists: this one is on the house, archive retrievals after the project archive window are billed at the stated rate. A fee announced after the tenth rescue feels like a penalty. The same fee announced after the first feels like a policy, because it is one.

What if I no longer have the files either?

Say so early and plainly, and work the remaining sources in order. Check your own archive copies, sent-mail attachments, cloud version history, and any shared folder the job used; delivered files hide in more places than the project folder. Ask whether anyone on the client side still holds a partial copy, an email attachment, a printed proof, an uploaded version in their own systems, because a partial original beats a total recreation. If the work truly has to be rebuilt, name it as new work: a reconstruction stage, priced, delivered and accepted as its own job, never presented as the original delivery. What you never do is recreate the files silently and send them as if they were the delivery. The difference will surface eventually, in a version, a date, a missing layer, and it will surface as a trust problem instead of a filing problem.

Can resending files reopen payment or acceptance arguments?

Only if the resend is allowed to blur into a new delivery. An unchanged copy of an accepted delivery, sent with a note that names it a resend and ties it to the original date and record, carries the original acceptance with it; there is nothing new to approve and nothing new to dispute. The blur starts when the resend quietly contains newer versions, extra material, or fixes nobody asked for, because then the client is holding work that was never accepted and everyone has to decide what it is. Keep the package identical, keep improvements and additions for a separate, named stage, and where the original job was checked but never formally accepted, use the resend to close that too: ask for the decision on the resent copy, in writing, so the favour leaves the job more settled than it found it.

How do I deliver so a lost file never becomes a rescue again?

Deliver against a record and into the client's own storage. When the work runs through Zambo, every step carries a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, and the handover lists exactly what was delivered and whether the client accepted it, so months later the resend source is the record itself rather than your memory of a folder. 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 job that way and make every future resend a copy of a closed record: 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