The retraction layer ends with every dependent proven dead. The claim is withdrawn, the pricing page is re-priced, the contract clause is amended, the config diff is deployed and verified. By every internal measure, the incident is closed.
And then a customer sends an email: "I hired two people to handle the volume your pricing page promised. That was eight months ago. What happens to them?"
Nothing in the retraction ledger has a column for that. The dependent — the customer's hiring decision — was not ours to unwind. It was built on our claim, it is still running, and it is running inside someone else's business, at someone else's cost.
That is the restitution layer. It is the invoice for the error, and it arrives after the announcement, after the rollback, often after the postmortem is filed.
Unwinding is not the same as making whole
A retraction restores our state: the claim is gone, the system no longer acts on it, the documents agree with reality. Restitution restores their state: the customer, the partner, the employee who executed the wrong instruction in good faith.
These are different projects with different owners and different success criteria. The retraction succeeds when nothing internally still depends on the claim. Restitution succeeds when the party who absorbed the cost says, in their own words, that the cost is no longer theirs.
That second sentence is the whole difficulty. It cannot be certified internally, because the evidence lives on the other side of the relationship.
Who actually paid
A wrong claim does not distribute its cost evenly. It lands on whoever moved first and trusted most:
- Customers who acted on it. Bought capacity they did not need, migrated data to a tier that no longer exists, signed annual terms at a price built on a number that was wrong, staffed to a volume that was never real.
- Partners who repeated it. Resold the claim in their own deck, built an integration against the behavior, promised their customers the same thing. They are now wrong in front of their own customers because they trusted ours.
- Employees who executed it. Ran the migration, wrote the runbook, hit the sales target, defended the number in a meeting. They did their job correctly with incorrect inputs, and they are the ones who will be asked why.
- Downstream users who never heard of you. The end customer of your customer. They experience the failure without any relationship to the party that caused it.
Most restitution programs cover the first group, partially, and discover the other three during the first difficult conversation.
The baseline problem
To make someone whole you need a counterfactual: what would their state be if the claim had never been made — or if it had been true? Both are legitimate baselines, and they produce very different numbers.
- Never made: reverse the decision. Unwind the purchase, the migration, the hire, the contract. Clean, expensive, sometimes impossible.
- Had been true: deliver what was promised. Keep the volume, keep the price, keep the integration working. Usually cheaper for the harmed party, sometimes impossible for you.
The failure mode is choosing the baseline that is cheapest for the org and presenting it as the only option. "We can offer a credit" is a remedy, not a baseline. The harmed party is entitled to know which counterfactual you are restoring, because they are the one who has to live in it.
Write the baseline down, per party, before you write the offer.
P1 through P4
Corrections have C1 and C2. Retractions have R1 through R4. Restitution needs four moments too, and the fourth one does not belong to you.
- P1 — the loss is acknowledged, per party. Not "some customers were affected." A list of parties, each with the specific decision they made because of the claim. If you cannot name the decision, you do not yet know the loss.
- P2 — the loss is quantified, with the method stated. Hours, euros, migrations, headcount, contract value. Estimates are acceptable; unexplained numbers are not. The method matters more than the precision, because the harmed party will check it.
- P3 — a remedy is offered, in a form the harmed party can choose. Refund, credit, re-performance, price adjustment, migration assistance, or a combination. The choice of form belongs to the party who absorbed the cost, not to the party who caused it — a credit is not restitution to someone who needed cash, and a cash refund is not restitution to someone who needed the integration to keep working.
- P4 — the harmed party confirms they are whole. In their words, on the record: "this covers it," or "this covers it except X." Not a closed ticket, not a signed release, not an internal note saying "resolved." P4 is the only evidence that restitution happened, and it is issued by someone outside the org.
The distance from P1 to P4 is the honest duration of the incident. Most postmortems stop the clock at R4, which is the moment the org became comfortable, not the moment the cost stopped moving.
Remedy design is where good intentions fail
Three patterns make restitution fail even when everyone means well.
1. The claims process is the filter. Requiring a form, an invoice, a proof of purchase, and a support ticket selects for the customers with the most resources and the least need. The customers who paid the most are often the least able to spend three hours proving it. If the process is harder than the loss, you have designed a program that pays the wrong people.
2. The remedy is chosen for accounting convenience. Credits are cheap, keep revenue on the books, and expire. That is exactly why they should not be the default: a credit converts a present obligation into a future discount, and if the customer never returns, the restitution never happens — but the liability leaves the books anyway.
3. Silence is treated as acceptance. "We offered, they did not respond" is not a P4. It is a P1 with no endpoint. A non-response after a low-friction, clearly explained offer is weak evidence; a non-response after a form and a deadline is no evidence at all.
The restitution ledger
Six columns, one row per party — not per claim, not per remedy type.
| Party (who absorbed it) | Loss (what decision, measured how) | Baseline restored (never made / had been true) | Remedy (form + amount) | Chosen by (party, date) | P4 — their words (date) |
|---|---|---|---|---|---|
Party is a named customer, partner, employee group, or downstream cohort — not "affected users."
Loss names the decision, not the feeling: hired 2 support staff for 8 months, migrated 1.2TB to the archived tier, re-sold the unlimited tier to 14 clients.
Baseline restored forces the choice into the open. If it varies by party, that is fine — as long as each row says which counterfactual it is restoring and why.
Remedy states the form and the amount, and whether it is cash, credit, service, or work.
Chosen by is the column that keeps the program honest. If every row says "us," the remedy was imposed. That can be legitimate, but it should be visible.
P4 — their words is a quote and a date, not a status. "Covers the staffing cost; the migration time is still on us." — 2026-11-19 is a real P4, and it tells you the restitution is partial. A row with no quote is still open, however long the ticket has been closed.
The uncomfortable part
Restitution is asymmetric by design. The party that caused the loss holds the records, the money, and the discretion; the party that absorbed it holds the burden of proving it. Every shortcut in the process — a form, a deadline, a credit that expires, a release that must be signed before payment — moves the asymmetry further in the wrong direction.
The test is not whether the program is generous. It is whether a customer with a legitimate loss and no lawyer can get made whole by someone who is not trying to minimize the number.
That is a higher bar than most incident reviews set, and it is the only bar that survives being described by the customer rather than by you.
Friday version
Take the last claim you withdrew. List every party who made a decision because of it — customers, partners, the team that executed it. For each, write the decision, the method you would use to price it, and which baseline you are restoring. Then send one of them a two-line message: "Here is what we think this cost you and how we calculated it. Is that right?" Their reply is the first real P4 you will have.
If you cannot name a single party, you have not finished R2 — and the retraction is not as closed as the postmortem says.
What comes next
Restitution closes the ledger opened by the retraction: the claim is withdrawn, the dependents are dead, and the cost has moved back to the party that caused it.
The next layer is the one every postmortem promises and few can evidence — the recurrence layer: not "we added a check," but proof that the same failure cannot produce the same outcome again, without claiming a probability of zero.
If your company withdrew a claim and quietly left the invoice with the people who believed it — a customer who hired against a promise, a partner who resold the number, a team that executed the wrong instruction in good faith — say so in the comments. We keep a one-page restitution ledger (each harmed party, the decision they made, how the loss is priced, which baseline you are restoring, who chose the remedy, and their reply in their own words) and I will send it over. No form, no email list.
