ZAMBO.

Direct answer

You inherited a pile of chat exports. Here is how to establish what is actually done before you price the rest.

The previous freelancer is gone, and what you hold is not a project record. It is a stack of exported chats: long threads where work was discussed, promised, pasted, and pronounced finished, in no order you can rely on. The client wants a price for finishing the job, and every number you quote from those exports is a guess wearing a spreadsheet. Chats were written to move the work along, not to prove it, so they overstate in the usual places: drafts described as finals, steps announced that never ran, decisions that were really one person thinking aloud. The way out is not to read harder. It is to grade the pile. Turn every claim in it into a list, check each claim against a record that was saved while the work ran, and sort the job into three piles: proven, only claimed, and missing. Then you report the piles, price the missing and the redo honestly, and restart the job on a record of your own, so the next person never inherits your pile. Here is the method, step by step.

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

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

Step 1. Stop reading the exports as a record, and name what they actually are

An exported chat is a copy of a conversation, assembled after the fact by whoever exported it. It shows what was said, in the order the export kept, with whatever the exporter left in. It does not show what ran, what a tool returned, or which pasted draft became the delivered version, and its timestamps are conversation timestamps, not execution records. Treat the pile the way an auditor treats a confident witness statement: useful as a list of claims to check, worthless as the check itself. That one shift protects you twice. You stop inheriting the previous freelancer's optimism as your own baseline, and you stop being the person who told the client the job was nearly done because a chat said so. Everything in the pile starts life in the middle pile, only claimed, and has to earn its way out.

Step 2. Build the claim list before you judge any of it

Work the brief and the exports together and write down every distinct claim of finished work as its own line: each deliverable, each stage, each decision the chats treat as settled. One claim per line, with the source noted beside it, brief section or chat and date. Include the claims nobody made: brief items that appear in no chat at all belong on the list too, marked unsourced, because silence in the exports is exactly where missing work hides. Do not price, promise, or summarise at this stage. A claim list for a mid-size project usually runs to a few dozen lines, and building it takes an hour or two, which is the cheapest hour of the whole takeover: every later argument, yours with the client or the client's with the previous freelancer, gets settled against this list instead of against impressions.

Step 3. Sort every claim into proven, only claimed, or missing

Now grade each line against evidence that was saved while the work ran. Proven: the claim is backed by a step record you can open, meaning a delivery record or handover link for the job, a verifiable receipt for the step behind a link you can recheck, or a delivered file whose contents match the claim and whose delivery the client can confirm. Only claimed: the work is asserted in a chat, a summary, or an email, but no record behind it opens, checks, or matches. Missing: the brief requires it and nothing, record or claim, covers it. Ask the client and, if they are reachable, the previous freelancer one specific question before you grade: are there handover links or receipt links for this job anywhere outside the chats? A job that ran through a recording connection has them, and a single link can move a dozen lines from claimed to proven in minutes, because the record carries its steps, its times, and its decision state in one place.

Step 4. Read the two states a real delivery record can sit in

This is the shape of evidence the exports cannot give you, and the shape to ask for first. 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 decision states a finished or half-finished job can carry:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

The accepted record, 4 steps, 4 checked, decided_by client at 2026-10-16T14:31:51.146Z, release_hint ok_to_release, is what proven looks like at job level: the steps are listed, each one checks, and the client's own decision sits on the record with a date. The pending record, 5 steps, 5 checked, release_hint hold, is the subtler gift to an incoming freelancer: the work is fully checkable and the record says, in the open, that nobody has accepted it yet. Against a record like that, your grading is mechanical. Against chat exports, the same two states collapse into one undated feeling that things went fine, which is why inherited projects blow up in week three, when a claimed final turns out to be a draft and an accepted stage turns out to have been accepted by nobody.

Step 5. Report the three piles to the client in writing, and price only what is real

Send the client the graded list as the takeover baseline: proven lines with the record or file that proves each, claimed lines named as claimed with what would prove them, and missing lines as the work that remains. Price from the piles, never from the pile of chats. Missing work is priced as new work. Claimed work is priced as a verification task with a fork: if it checks out on inspection, it moves to proven at the verification price; if it does not, it is redone at the redo price, and the client chooses with both numbers in front of them. Proven work is not priced at all, and saying so in writing is what makes the rest of the quote credible. Close the message by asking the client to confirm the baseline as the starting state of your engagement. Their confirmation, or their corrections to it, becomes the first decision on your own record, and it is the line that protects you when a claimed item fails later: you never adopted it, you graded it, and the client saw the grade.

Step 6. Restart the job on your own record from day one

Whatever you finish, redo, or newly build from here should run on a record you control, so this project never produces a second pile of exports. Open your engagement by wrapping the takeover baseline itself as the starting record of the job: the goal, the three piles as the state you inherited, and the client's confirmation as the first decision. Then run your work so each step lands on that record with its own receipt as it happens, and deliver stages as handovers the client accepts or flags, step by step. If you are ever the freelancer leaving, that record is what you hand over, and the incoming side of the next takeover takes an afternoon instead of a week. The habit costs nothing extra while the work runs. It is only expensive to fake afterwards, which is the entire lesson the chat exports just taught everyone on this project.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved. It does not prove the work was good, complete against the brief, or accepted, which is why this method grades claims against the brief and reads the acceptance state separately. Work that never ran through a recording connection cannot be proven after the fact: it can only be inspected, reconstructed, or redone, and honest grading names it claimed or missing rather than dressing it as proven. This page is general information, not legal advice, and it takes no side in any dispute between the client and the previous freelancer: the three piles describe evidence, not fault.

Frequently asked questions

I took over a client project from another freelancer and all I got was a pile of chat exports. How do I establish what is actually done?

Grade the pile instead of reading it as a record. Build one claim list from the brief and the exports together, one line per claimed deliverable, stage, or settled decision, including brief items no chat mentions. Then sort every line into three piles. Proven: a step record, handover link, or verifiable receipt opens and checks, or a delivered file matches the claim and the client confirms delivery. Only claimed: asserted in a chat or summary with no record behind it. Missing: required by the brief and covered by nothing. Ask first whether handover or receipt links for the job exist anywhere outside the chats, because one link can move many lines at once. Report the three piles to the client in writing as the takeover baseline, price missing work as new work and claimed work as verification with a stated redo price, and get the client to confirm the baseline before you build on it.

Can I trust the timestamps and finished messages in the chat exports?

Trust them as conversation history, not as execution evidence. An export shows what was said and roughly when it was said, in the order the exporter kept, and exports can be partial, reordered, or missing the thread where a decision changed. A message saying a step is finished proves the message was sent; it does not prove the step ran, what it returned, or which version of a file it produced. Where a claim matters, meaning money, acceptance, or a stage you would build on, ask for the record behind it: the delivery record, the receipt link, or the file itself, checked against the claim. Claims with no record behind them are not lies by default; they are simply ungraded, and your baseline should carry them as only claimed until something checkable arrives.

What if there are no receipts or records at all for the earlier work?

Then nothing from the earlier work can be proven in the record sense, and the honest method is inspection. Work through the claim list against the actual files, outputs, and systems the job touched: open the deliverables, run or read the outputs, and mark each line as inspected and working, inspected and broken, or not found. That inspection becomes your evidence, written up as the baseline with your name and date on it, and it is weaker than a record saved while the work ran, because you are vouching for the state today rather than showing the state as saved. Price the inspection openly, keep the language exact, and never backfill: a step you inspected today was inspected today, and presenting it as recorded at the time would repeat the original sin of the chat pile in a neater font.

What do I send the client before I quote for finishing the job?

Send the graded baseline, not a quote built on the chats. One document: the claim list sorted into proven, only claimed, and missing, each proven line carrying the record or file that proves it, each claimed line carrying what would prove it, and each missing line carried into the work that remains. Attach the two prices the piles produce: the price for the missing work, and the verification price for the claimed work with the redo price stated if a claimed item fails inspection. Then ask the client to confirm the baseline in writing as the starting state of your engagement. A client who confirms it has accepted your grades as the shared starting point, which ends the most common takeover dispute before it starts: the later discovery that something claimed was never done becomes a priced fork the client already saw, not a surprise you are blamed for.

How do I keep my own takeover work from becoming the next pile of exports?

Run it on a record from the first day, starting with the baseline itself. When the work runs through Zambo, the takeover state you established wraps as the opening handover of the job, every step you run lands with a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, and the client accepts or flags each stage on the record, so proven, claimed, and missing never blur again. 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, open the takeover on that footing and let the finishing work record itself as it runs: 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