Direct answer

Their account, their history, your work, and no record on your side. Fix the route, not the client.

The client gave you access to their own AI account, their projects, their data, their setup, and the work happened in there, which felt convenient for everyone. Then the job ended, the access ended with it, and you realised what you do not hold: no history, no steps, no delivery record, nothing on your side to answer a question, support an invoice, or show the work was yours. The client is not withholding anything; the record simply lives in an account that is not yours. Here is what you can honestly put together for the finished job, the single confirmation to get from the client while relations are warm, and the routing change that keeps your own proof next time without taking the work out of their world.

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

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

Step 1. Name what you actually hold today, without overstating it

Start with an honest inventory of your side of the job. You likely hold more than nothing: the brief and messages that set the work up, your invoices and their dates, drafts or files you prepared locally, notes you took, and the delivered outputs if copies ever passed through your hands. What you do not hold is the execution record: the steps as they ran inside the client's account, in their order, with their dates. Both halves of that sentence matter. Overstating the first half, pretending your fragments are a record, collapses the first time a client or a third reader tests them. Understating it, treating the job as undocumented, undersells the traces that do support you. List the fragments by date, keep them together as this job's file, and mark the file for what it is: supporting traces around work whose step record sits in the client's account.

Step 2. Get one delivery summary confirmed while the job is warm

For this finished job, the strongest record you can still create is a short delivery summary the client confirms now. Write it in an hour, while memories and goodwill are fresh: the job and its dates, what was delivered in plain list form, the main decisions and who made them, the fee and its state, and anything left open. Send it as a document, not a chat message, and ask the client to confirm it in a reply or accept it as the delivery record. A confirmed summary is not the step record you wish you had, and this page will not pretend otherwise. It is a dated, agreed account of the work, created near the event by both sides, and in any later conversation, an invoice question, a scope argument, a reference request, it carries weight that your unconfirmed notes never will. If the client will also export or share the relevant history from their account, ask for it now and file it beside the summary; volunteered today, it may be unavailable in a year.

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

The finished job above sits in a third state: no record on your side at all. The two public records below show the states a delivery sits in when the work ran on a record you hold. 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 those states:

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 a complete answer held by the supplier: steps the client can reopen, and the client's decision attached to them. The pending record, 5 steps, 5 checked, release_hint hold, is a partial answer still worth far more than fragments: the steps are yours to produce at any time, and only the decision is visibly outstanding. Either state beats the position this job left you in, where every question about the work routes back through the client's account and the client's willingness to look. Steps 4 and 5 are about never being routed that way again.

Step 4. Route the work through your own connection, wherever it is delivered

The fix is about the route the work travels, not about where the client reads the result. When you do work for a client, run it through your own connection, so every step lands on a record held on your side as it happens, then deliver the outputs into the client's stack in whatever form they use there: documents in their drive, text in their tools, the result inside their account if they paste or import it. Their world keeps working exactly as they like it; what changes is that the execution record, steps, sources, dates, and saved results, exists on your side from the first call. Agree this in the open at the start of the engagement, in one sentence in your terms: work is produced through my systems and delivered into yours; I keep the production record and you receive the delivery record link for every job. Clients rarely object to a sentence that also hands them a checkable record of what they paid for.

Step 5. Deliver as a record the client accepts, not as loose output in their account

Delivery is the moment the two sides of the record meet. Instead of the work simply appearing inside the client's account, deliver each job as a wrapped record, the steps in order, the outputs as saved results, under one link, and ask the client to check and accept it there. Their acceptance, decider and date on the record, is the piece no arrangement of account access can give you after the fact, and it is the piece that settles invoices, scope questions, and credit for the work. Keep the link with your invoice and in your client index, so the record of a job inside a client's world is still findable from your desk in a year. Where a client genuinely must have work produced inside their account for data or policy reasons, split the difference in writing: the steps that can run through your connection do, the in account parts are summarised into the same delivery record by you at the time, and the summary states plainly which parts ran where. Partial record, honestly labelled, still beats none.

Step 6. Close every engagement with your side complete

Make the end of each job a short closing ritual on your side, done before access lapses and attention moves on. The delivery record accepted or its pending state noted. The confirmed summary filed if any part of the work ran outside your record. The invoice linked to the record link. Your client index updated with dates and links. Anything you were lent, access, files, credentials, noted as returned or ended. Five minutes at close, while everything is warm. The supplier who does this can answer for any job they ever ran, for any client, from their own desk, which is precisely the position this job showed you the cost of missing. It is also, quietly, a selling point: a practice that hands every client a checkable record of every job is easy to brief, easy to trust, and easy to pay.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not recreate work that ran inside a client's account with no record, give you rights over a client's account or data, or decide who owns the outputs of a job. Your confirmed summary, your supporting traces, the agreement about routing, and a delivery record on your side from the next job on are what this answer stands on. This page is general information, not legal advice.

Frequently asked questions

The work was done inside my client's own AI account, so I have no record of any of it on my side. How do I keep my own proof next time?

Keep the record by changing the route, not by asking for the client's account. From the next job on, run the work through your own connection, so each step is saved on a record you hold as the work happens, and deliver the outputs into the client's tools in the form they use there. Agree it in your terms in one sentence: work is produced through my systems, delivered into yours, and you receive the delivery record link for every job. Deliver each job as a wrapped record the client checks and accepts, and file the link with the invoice. For the job already finished, do the honest repair now: assemble your supporting traces, brief, messages, local drafts, invoices, into one dated file, and get a short delivery summary confirmed by the client while the job is warm, asking them to share any history export they are willing to give.

Can I ask the client to give me access again so I can copy the history?

You can ask, and for a specific, current need, tying up a loose end both sides want closed, a polite request often works. As a system, it fails in every direction: access may have been removed for good reasons, staff change, the history may have been edited, pruned, or buried, and what you copy is still excerpts in their account, not a record on your side. Ask once, for a defined purpose and a short window, and file whatever you receive beside your confirmed summary with its date and source noted. Then never build your proof on borrowed access again. The lesson of this job is not that clients lock you out; it is that a record you only hold by someone else's permission was never yours, and the routing fix in this page is what makes the next one yours outright.

The client insists the work must run inside their account. Is there any middle way?

Yes, a written split, agreed before the job starts. Some work genuinely belongs inside a client's account: their private data, their configured projects, tools only they license. For that work, agree three things in writing. You will keep a contemporaneous production note on your side, dated entries as the work happens, what was done, what was decided, what was delivered, which you send to the client as the job proceeds rather than reconstructing later. Outputs delivered to you or through you, drafts, reports, exports, are filed on your side as they pass. And at delivery, the whole job, in account parts included as your summarised steps, is wrapped into one delivery record the client accepts, with the record stating plainly which steps ran in their account. You hold less than a full step record, and far more than fragments, and the limits are agreed instead of discovered.

What should my engagement terms say about records?

One or two plain sentences, agreed before work starts, cover it. Work is produced through the supplier's systems and delivered into the client's tools; the supplier keeps the production record of each job and provides the client a delivery record link for checking and acceptance. If part of the work must run inside the client's account, the supplier will record that part by dated production notes included in the same delivery record. That is the whole clause most practices need. It sets expectations while relations are good, gives the client something valuable, a checkable record of what they bought, and removes any surprise when you later produce your record in answer to a question. Terms are general information here, not legal advice; have your own documents reviewed if the work is large or regulated.

How do I keep my own proof when the work has to land in the client's stack?

Run it through your own connection and let the delivery land wherever the client works. When the work runs through Zambo, every step carries a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, on a record held on your side, and the wrapped delivery gives the client one link to check and accept the job, decider and date kept. 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, run the next client account job that way and hold your own proof from the first step: 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