Direct answer
One questioned step deserves a one link answer, not a week in old chats.
Three months after the job closed, a message arrives: a question about one step. Not the whole project, not the outcome, one stage, one decision, one deliverable in the middle of the work. What did we receive, what was sent, who checked it, was it ever accepted. You know the answer is in there somewhere, spread across a chat thread that has since been buried under three months of other work, an inbox, a folder of exports, and your own fading memory of which round was which. Digging is slow, and what digging produces is weak: screenshots and quotations that the other side can call partial, edited, or out of order. The professional answer to a one step question is a one step record: the step itself, saved at the time, checkable now. Here is how to answer this question from whatever record exists, and how to close jobs from now on so the next one takes a minute.
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. Pin the question to one exact step before touching any archive
Vague questions produce archive sized answers, so narrow first. Reply and confirm the step in one sentence each: the deliverable or stage name, the date it was delivered, and the precise point being questioned, a figure, a file, a choice, a missing item. Half of all late questions dissolve at this stage, because the client was picturing a different step, an earlier round, or work from a different supplier entirely, and naming the step surfaces that before you have spent an hour digging for the wrong thing. The other half become answerable, because a question pinned to one named step on one date has exactly one place where its answer lives. Write the pinned question at the top of your reply when you answer, too. A late question answered against a precisely named step closes; the same answer floating free of the question gets re-asked in a new form next month.
Step 2. Understand why chats, folders, and memory cannot answer a single step cleanly
It helps to know what you are up against, because it explains both the slowness and the weakness of the dig. A chat thread mixes every step together in speaking order, not job order, and rounds interleave with small talk, other projects, and decisions that were later reversed in a call. Exports and screenshots freeze what was said, detached from what was actually run or delivered, and they can be reordered or cropped, which the other side knows as well as you do. Folders hold files, not events: they show that a document exists, not when it was delivered, what it replaced, or whether anyone checked it. And memory, three months on, confidently supplies a step that feels right rather than the step that happened. None of these sources is useless, and step 5 works with them honestly. But none of them was built to answer the question, what exactly happened on step four, as a single checkable fact. That is a record's job, and step 3 shows what it looks like when the record exists.
Step 3. Read the two states a finished job can sit in when one step is questioned
When every step of a job carries its own receipt inside one closed record, a late question opens one link, not an archive. 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 finished delivery can carry:
Accepted: the decision is on the record
- Status: accepted, decided_by client, decided_at 2026-10-16T14:31:51.146Z, release_hint ok_to_release.
- Steps: 4 steps total, 4 checked.
- aer1_version: draft-zambo-aer1-26.
- Open the handover or read its acceptance.json.
Pending: checked, and still waiting on a decision
- Status: pending, release_hint hold.
- Steps: 5 steps total, 5 checked.
- aer1_version: draft-zambo-aer1-26.
- Open the handover or read its acceptance.json.
Look at the structure rather than the topic. The accepted record holds 4 steps, 4 checked, decided_by client on 2026-10-16T14:31:51.146Z, release_hint ok_to_release, and its acceptance data lists one receipt link per step, so a question about step two opens step two: its saved result, checkable as saved, inside a job whose decision state is also on record. The pending record holds 5 steps, 5 checked, release_hint hold: the steps are equally openable, and the record honestly shows the one thing that was never settled, the decision. That honesty is a feature when a step is questioned late. The record separates what happened, which is saved and checkable per step, from what was decided, which is stated plainly, instead of letting a three month old argument blur the two together.
Step 4. Answer from the step record: what ran, what was saved, what was decided
Build the answer in three short parts, each tied to the record rather than to your recollection. What happened on the step: the work it covers, the result that was saved, and its date, quoted from the step itself. Whether it was checked: the step's receipt can be opened by the client and the saved result checked against it, which converts your claim into their verification, a much stronger position than any summary you could write. What was decided about it: the job's decision state, accepted by the client on its date, or still pending, stated without decoration either way. Then stop. The discipline of a step sized answer is part of its credibility: you were asked about one step, you answered that step completely, and you did not volunteer a rambling defence of the whole project that invites ten new questions. If the step answer raises a genuine follow up about a neighbouring step, that step has a record too, and it gets the same treatment, one at a time.
Step 5. If this job has no per step record, reconstruct honestly and label every part
Many older jobs were never recorded step by step, and the honest version of the dig still beats a confident reconstruction. Pull the step's traces together, messages, files, timestamps, and then label what you send in three plain classes. Proven: a trace the client can check themselves, the sent message with its attachment, the file with its date, a reply quoting the step's contents. Claimed: things you believe happened that rest on your word or your notes alone, labelled as such. Missing: parts of the step no trace survives for, named openly rather than papered over. This labelling feels like it weakens your answer and does the opposite: a supplier who marks their own gaps is believed about their proofs. Close the reconstruction by making the settlement itself recorded, the agreed account of that step written down and confirmed by both sides now, so this particular question, at least, never has to be dug for twice.
Step 6. Close every job so any single step can be reopened in a minute
The fix is a closing habit, applied while the job is still warm. Run the work as steps in one job record, each step's result saved with its own verifiable receipt as it completes, rather than reconstructed at the end from chats. At close, wrap the job up: the steps in order, the open items named, the client's decision recorded against the whole, accept or flag per step where the job is large. Keep the record link with the invoice and the final message, in the places your future self will actually look. Retention is part of the habit: a step record answers nothing if it was deleted in a tidy up, so closed job records are kept for years, not months, because late questions arrive on exactly that timescale and are often attached to audits, disputes, or follow on work worth winning. A practice that closes jobs this way answers a three month old question before lunch, with a link, while competitors are still scrolling.
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 step's work was correct, wise, or what the client now wishes had been done, and it cannot recreate a step that was never recorded. The step record, its receipt, the job's decision state, and your labelled reconstruction where no record exists are what this conversation stands on. This page is general information, not legal advice.
Frequently asked questions
A client is questioning one step of a job I finished three months ago. How do I pull up exactly what happened on that step?
Pin the step first: its name, its delivery date, and the exact point in question, confirmed with the client so you are both looking at the same step. Then answer from that step's own record if the job was run on one: open the step inside the job's handover, quote what was saved on it and when, give the client its receipt link so they can check the saved result themselves, and state the job's decision state, accepted by the client on its date or still pending, as a separate fact. If the job was never recorded step by step, reconstruct from messages, files, and timestamps, and label every part of your answer proven, claimed, or missing, so the client can see which parts they can verify. Finish by writing the agreed account of that step down and having both sides confirm it, so the question stays answered.
How long should I keep records of finished jobs?
Years, and longer than feels necessary while the job is fresh. Late questions cluster around a few triggers, tax and audit seasons, disputes that mature slowly, staff changes on the client's side, and follow on work where the new team reopens old decisions, and those triggers routinely fire one, two, or more years after delivery. Storage is effectively free compared with the cost of one unanswerable question about a paid job, so the practical rule is: closed job records, delivery, acceptance, invoices, and the brief, are kept permanently as part of the practice's own archive, in a form you can search by client and by job. What you can safely let go is the clutter around the record, duplicate drafts and working files, once the record itself is safe. Delete copies, never the record.
The record shows the client accepted the job. They are still questioning a step. What then?
Answer the step fully anyway, from its record, and let the acceptance sit beside the answer as a fact rather than a weapon. Acceptance does not make a step unquestionable: clients legitimately reopen steps for audits, for their own reporting, or because a new colleague needs to understand what was done, and a supplier who answers cleanly from the record usually ends the matter in one exchange. Where the question is really a reopening of the settlement itself, the record draws the line kindly and firmly: the step was delivered in this form, checked, and accepted on that date, so any change from here is new work, priced as such, while the historical question has been answered in full. Keeping those two things separate, history answered free and completely, changes priced as changes, is what makes an acceptance record worth having on both sides.
What if only part of the job was recorded step by step?
Answer each part at its own strength and say which is which. The recorded steps get the full treatment: the saved result, the receipt link the client can check, the decision state. The unrecorded steps get the labelled reconstruction: proven traces, claimed events, and missing pieces, named as such. Do not let the strong part of the record lend borrowed certainty to the weak part; a client or a third reader who catches one overstated step discounts the whole file, including the steps you could genuinely prove. Then offer the practical close: the agreed account of the unrecorded steps, written and confirmed now, becomes their record going forward, and the next job runs recorded end to end. Partial records are common and nothing to be ashamed of; presenting them honestly is what separates a record keeper from a storyteller.
How do I close a job so I can answer for any single step later?
Run the job as steps on one record and wrap it up at close. When the work runs through Zambo, every step carries a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, the client accepts the wrapped job on the record, and any single step can be reopened later from its own link. 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, close the next job that way and make a three month old question a one link answer: 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
- 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?
- My client approved the work on a call, nothing was written down, and now they say they never approved it. What do I do?
- How do I prove a whole multi-step job, not just one tool call?
- How do I replay or re-check an agent run later?
- Start with your problem: every problem in this directory, routed to its page