What each entry records
For each incident: what the harm was, what was done, who owns it, when the person was told, and how the fix was checked.
A repair log records each repair made after a system harms someone, what it cost the people repaired, and the receipt and owner for each.
A repair log records, in order, each reversal, restoration, and repair made after a system harms someone, and what it cost the people repaired. Each entry links to the receipt, names the owner, and shows whether the repair is finished. Corrections stay visible and can be audited.
Teams use it to show that remedies happened, and to see when the same failure keeps coming back.
A hypothetical case. After an automated account lock is reversed, the repair log records the reversal, the compensation paid, and how long the remedy took.
In the glossary: Repair log.
Mechanism, drawn
Each entry records the harm, the action and its receipt, the owner, when the person was told, and how the fix was checked. It closes when the fix is confirmed in production, not when a postmortem is written. Read in order, the log shows the same rule producing the same harm, and those repeats go to the rule's owner. The entries are hypothetical.
In practice
For each incident: what the harm was, what was done, who owns it, when the person was told, and how the fix was checked.
A postmortem with no follow-up ends up in an archive. Keep each entry open until the fix is confirmed in production.
Publish the counts of open and closed repairs, how often incidents repeat, and proof that the people affected received a remedy or compensation.
Where the standards use it:
The operator or steward responsible for remedy decisions, not the support queue.
That the earlier fix resolved the case and left the cause in place. Repeats under one rule go to that rule's owner, who corrects the rule or records why not.