This is not about outages. An outage is honest: the product is down, everyone can see it, nothing was claimed, and trust takes almost no damage because there was nothing to believe.
This is the other failure. The product asserted something specific, in a confident voice, it was wrong, and somebody acted on it.
That damages trust differently, and the difference is the whole design problem. They start doubting every earlier answer they did not check, and there are a lot of those, because the value proposition was that they would not have to check. Repair has to reach the back catalogue.
Which is why an apology does almost nothing here. It addresses one incident. The user's question is about a category.
Six steps, in order.
Detect. How you find out ranks how bad things already are: the system's own check caught it, the user corrected it in the product, the user complained, somebody outside noticed publicly. Design owns one lever, which is making in-product correction the easiest path available. If reporting a wrong answer takes more effort than shrugging, you have chosen not to know, and that choice got made in a design review where nobody framed it that way.
Admit, in the same place the wrong answer appeared. Say wrong, not "may not have been fully accurate." Say it in the first sentence. Write this copy in advance, because during an incident the version that ships is whatever somebody typed in a hurry with legal reading over their shoulder.
Contain. Tell them the blast radius before they ask, and name what was not affected, because that does more work than naming what was. "This affected the usage summary between the third and the ninth. Billing and exports were not affected." Without the second half the user assumes everything, which is free for them and expensive for you. If you do not know the radius yet, say so and say when you will know.
Correct visibly. The corrected value, labelled as corrected. What changed, not just the new state. A path to unwind anything they did on the old answer. Never quietly swap the wrong value for the right one, because a user who noticed now knows the product edits history without telling them.
Prevent, visibly. This is the skipped step and it does most of the repair. One sentence about the mechanism: a check that catches date range mismatches before the summary renders. "We take accuracy seriously" repairs nothing. A named check tells the user the class is closed rather than the instance. The strongest version is not a message at all but a new state they can see: a confidence signal where there was none, a source citation, a confirmation step.
Adjust the confidence posture. After a confident error, the product's voice on that class of output changes for a while. Move up a rung on the disclosure ladder, add the source, drop the assertive phrasing, and put a revisit date in the decision record so moving back is a decision rather than a thing that quietly never happens. This step is what separates repair from apology. It costs something, which is why it is believable.
The artifact is four sentences per surface, written before you need them. Plain statement that this was wrong. What was affected and explicitly what was not. The corrected state, and how to unwind anything done on the old one. The specific check now in place.
Two ways repair fails anyway. Repairing in a channel the user does not read, since a status page is a record of a repair rather than one. And apologizing more than correcting, where the ratio to aim for is about three to one in favour of the fix.
This week: write the four-sentence script for the surface where a confident error would cost you most, then get it approved by whoever would have to approve it during a real incident. Approval on a calm Tuesday is worth more than any amount of polishing.
The full sequence with owners and the severity table is in The Trust Repair Sequence. The argument is in Recovery and Trust Repair.