ZAMBO.

Direct answer

It worked as delivered. Then their team touched it. Compare before you fix.

You delivered the work, it was checked and accepted, and life moved on. Now a message arrives: the thing is broken, can you fix it. You open it and stare at work you half recognize, because the client's own team has been in it since delivery, changing settings, editing content, swapping parts, following a tutorial, nobody quite remembers. Buried in that fog is a billing question with a clean answer, but only if you resist the first instinct, which is to start repairing. The moment you touch the broken version, your work and their edits blend into one state that nobody can unpick, and the fix becomes yours by default. The order is: freeze, compare, sort, then price. The delivered version on its record is the reference everything gets measured against. Here is the comparison and the sort.

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

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

Step 1. Freeze the scene before anyone fixes anything

Ask the client, in writing, to stop further changes to the broken item until you have both looked at it, and take your own copy of the current state today, files, screenshots, settings export, whatever the work's native form is, dated. This is not suspicion, it is hygiene, and say so: every extra edit between the breakage being reported and the comparison being run destroys exactly the evidence the sorting depends on. Ask one question in the same message: who has changed the item since delivery, and roughly when. Most clients answer honestly, because most post-delivery breakage is innocent, a well-meant improvement, a new hire tidying up, a plugin updated for unrelated reasons. You are not building a case against anyone. You are establishing the one fact the whole page turns on: the current version is not the version you delivered.

Step 2. Put the delivered version and today's version side by side

Now run the comparison, in the open. On one side, the work exactly as delivered: the final files as handed over, the accepted state, in the form the delivery record holds. On the other side, today's version, frozen in step 1. Work the differences in order. Does the delivered version still do the job it was accepted for? Test it, or point at the acceptance that already tested it. Which specific changes sit between the two versions, named one by one, as best either side can reconstruct them from file dates, change logs, admin histories, and the team's own memory. And the decisive question: does the breakage exist in the delivered version, or does it appear only where the later changes reached? A breakage that cannot be reproduced in the delivered version, in an area their edits touched, has answered its own billing question. A breakage sitting untouched in the delivered version has answered it the other way. Everything honest in this conversation comes out of that table of differences, which is why it gets built before any repair quote exists.

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

The comparison only works if the delivered state was saved in a form that cannot quietly drift afterwards. 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 delivered version with a decision on it: this state, checked, closed. When today's working copy disagrees with that state, the disagreement itself is the finding; something after delivery produced it. A pending record, 5 of 5 steps checked and release_hint hold, is weaker ground for everyone: the work was checked but the decision was never recorded, so if their team has edited since, insist on the comparison first and the acceptance of the delivered state as part of closing the matter, so the reference version stops being a matter of opinion. In both states the receipt's promise is narrow and exactly the one needed here: the saved result was not changed since it was saved, so the delivered version can be checked against today's version rather than argued about.

Step 4. Sort every breakage into three piles

Pile one, your defect: the fault exists in the delivered version itself, against what was agreed. Their later edits are a coincidence of timing, not a cause. This pile is yours, fixed free, inside the same honesty as any defect, and owning it cleanly is what makes the other two piles stick. Pile two, their change: the delivered version works, the fault appears only in or after their edits, moved settings, replaced content, removed parts, an update applied over your configuration. Repairing pile two is new work on a version you did not ship, and it is priced like new work, because it is. Pile three, the interaction: your work and their change each behaved acceptably alone and broke in combination, a change of theirs meeting an assumption of yours that the agreement never stated. Pile three is genuinely shared, and the fair shape is a small paid diagnosis stage with a cap, its findings written down, and the repair priced from the findings rather than from the argument. Publish the sort to the client with the comparison attached. Item by item beats pile by pile, and a client looking at their own team's dated edits next to your delivered version rarely needs the conclusion spelled out.

Step 5. Offer the two repair doors, priced, with the restore door first

Door one, restore: put back the delivered version, exactly as accepted, and let their team re-apply the changes they still want, one at a time, testing as they go. Where the delivered copy survives intact, restore is fast and cheap, sometimes free as a courtesy if it is minutes of work, and it returns everyone to a state known to work. Door two, repair forward: you fix the current, edited version in place, keeping their changes and making the whole thing work again. That is a real job on an unknown codebase state, their edits included, so it is scoped and priced as one, with the diagnosis from pile three folded in where relevant. Either door ends the same way: the repaired state is delivered and accepted as its own stage on the record, so there is a new reference version from that day forward, and nobody ever again has to argue about which state a future breakage belongs to. What you never do is repair forward silently and free, because that sets the only precedent this situation can teach: changes made by anyone, at any time, come with your free repair attached.

Step 6. Write the handover terms that make the next breakage sort itself

Four short lines at delivery time turn this whole page into a formality next time. Line one: the delivered version is identified, by date and by record link, and defects are faults in that version, fixed free inside the stated window. Line two: changes made by anyone other than you after delivery are listed as they happen, a one-line log the client's team keeps, date, person, what changed. Line three: breakage in an edited area is diagnosed at a stated rate or under a stated support arrangement, and repair of other people's changes is priced work. Line four: a support option exists for teams who want their own edits covered, priced as the insurance-like product it is, so the client chooses in advance instead of negotiating after a breakage. Teams who edit carefully sign this happily, because the same lines protect them when a provider blames every genuine defect on the client's one settings change. The log in line two is the line that does the work; insist on it kindly and by name.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not prove whose edit caused a breakage, and it cannot repair one. The delivered copy, the frozen current copy, the change history the client's systems hold, and your item-by-item sort in writing are what the conversation stands on. Where the two versions no longer exist to be compared, say so honestly and price the diagnosis instead of inventing a certainty neither side has. This page is general information, not legal advice.

Frequently asked questions

My client wants me to fix work that their own team changed after delivery. Who pays for the fix?

Whoever's version the fault lives in, and you find that out before fixing anything. Freeze the current state, take a dated copy, and compare it against the work exactly as delivered and accepted. A fault that exists in the delivered version is your defect and you fix it free. A fault that appears only after the client's team edited the work is a repair of their changes, which is new, priced work, with restoring the delivered version offered as the fast first door. A fault born from the combination gets a small capped diagnosis stage and a repair priced from written findings. Publish the sort item by item with the comparison attached. The one move that always loses is repairing the edited version first and discussing it later, because once you have blended your work into their edits, nobody can unpick whose state it is, and the fix becomes yours by default.

How do I prove the work was fine when I delivered it?

You do not prove it with confidence or with your memory of delivery day. You show the delivered version itself: the final files as handed over, in the state the client checked and accepted, opened or run today next to the current broken version. In the worked example on this page, the public record shows the delivery at 4 of 4 steps checked, status accepted, decided_by client on 2026-10-16T14:31:51.146Z, release_hint ok_to_release, and the receipt on each step is a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, which supports the narrow claim that matters here: the saved result was not changed since it was saved. If the delivered version still performs as accepted while today's version does not, the difference between the two, their dated edits, is where the breakage entered, and the comparison makes that visible without you accusing anyone of anything.

The client says their changes were tiny and cannot have broken anything. What do I say?

Agree that size is not the measure, and go back to the comparison. Tiny changes break work constantly, a moved setting, a renamed file, one updated component, precisely because they look too small to check. So do not debate whether the change was big enough. Ask instead that the breakage be located: reproduce it in today's version, then test the same path in the delivered version. If the fault will not reproduce in the delivered version and sits in the area the small change touched, location has answered the question that size could not. Offer the restore door in the same message, because it fits their belief too: if their change really is innocent, restoring the delivered version and re-applying the change carefully will show the fault arriving with it, or not, in minutes, and either result settles the billing without a quarrel.

What if neither side kept a clean copy of the delivered version?

Say so plainly, and change the job you are selling. Without the two versions, the sort cannot be run, and anyone claiming certainty about whose fault the breakage is, on either side, is guessing in their own favour. The honest offer is a capped diagnosis stage: a fixed price to investigate the current state, findings in writing, and a repair quote that follows from the findings, with the split of the diagnosis cost itself a thing you can negotiate as goodwill. Then close the hole the same week: deliver the repaired state as a recorded, accepted stage, keep the delivered copy yourself this time, and put the four handover lines from this page into the client's hands, so the next breakage, if there is one, arrives with its reference version attached instead of as an argument about a state nobody saved.

How do I set up delivery so post-delivery changes are never my free problem?

Deliver every job as a fixed reference version with the client's own edits logged after it: the final state saved step by step with a verifiable receipt on each step, accepted on the record, and a one-line change log, date, person, what changed, that their team keeps from delivery day, with your defect promise written against the delivered version only. When the work runs through Zambo, every step carries a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, so months later the delivered version can still be checked exactly as saved, and any later breakage sorts against it in one comparison. 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 the next fix request a comparison, not a debate: 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