The Same Outage, Three Times

All three are changes to human behavior, and none is falsifiable.

• "Double-check config changes" - there is no way to verify this happened, no way to know it worked, and no mechanism. Given a 45-minute outage and a Friday afternoon, every engineer will double-check. Given a normal Tuesday, nobody will.
• "Add a second reviewer" - a reviewer who is looking at a diff cannot see that routing.flag=true will send 40% of traffic into a black hole. Review catches typos and intent mismatches, not semantics. This action item looks like a control and functions as a ritual.
• "Remind the team to follow the process" - the process was followed. That is what makes this one damning: it asserts the failure was a discipline problem when the evidence says it was a system problem.

Why they failed: they were written to close a ticket, not to change a system. Marking them closed after a Slack message is the completion criterion working exactly as designed - the design is wrong.

A real action item is a change to a system, with an owner, a date, and a test that can fail:

• "Config schema validation in CI rejects any routing flag change unless a matching routing test passes. Owner: A. Due: 14 days. Verified by: the next Thursday push cannot merge without it."
• "Canary push to 1% of traffic with automatic rollback when the error-rate SLI exceeds threshold for 60 seconds. Owner: B. Due: 30 days."
• "Rollback completes in under 2 minutes, measured by a quarterly game day. Owner: C. Due: 60 days."

Note that the third one addresses the actual worst part of the incident: not that the change was wrong, but that it took longer to undo than to make.

Blamelessness is a precondition for learning, not a substitute for it. It removes the incentive to hide information. It does not, by itself, produce a single change to a system. Teams routinely achieve perfect blamelessness and zero improvement.

What is missing is accountability - which is different from blame.

Blame	Accountability
Who caused this?	Who owns the fix?
Backward-looking, personal	Forward-looking, structural
Ends the inquiry	Extends the inquiry

Concrete mechanisms to add:

1. Named owner and due date on every action item, tracked in the same backlog and the same sprint reviews as feature work. An action item in a separate doc is an action item that will not happen. Feature work always wins against a document.
2. A completion standard: "no system change, not done." A Slack message does not close an item.
3. A recurring review - 30 minutes monthly, walking open actions and their aging, attended by an engineering manager with authority to reprioritize.
4. A repeat-incident signal: when an incident matches the class of a previous one, that reopens the predecessor and escalates it. Track the repeat rate as a first-class metric.

The framing that keeps this blameless: "We are not asking who did this. We are asking why the system made this the easy thing to do, and what we are changing so it isn't." The two engineers involved should be the ones designing the guardrail - they have the most context, and giving them the fix is the opposite of blame.

Now (48 hours):

1. Get the change classified before it ships. Someone reads the diff specifically for blast radius: does it touch routing, auth, or money? If yes, it is not a normal push.
2. Manual canary. Push to one instance or 1% of traffic, watch the transaction success rate for 10 minutes, then proceed. This is imperfect and slow and it costs an hour. It is also the only guardrail that can exist by Thursday.
3. Name a rollback owner and pre-compute the rollback path before the change starts. Write down the expected rollback duration. If it is longer than the push, that is the real finding.
4. Do not interpret "be careful" as a mitigation. Ship the manual process and log it as a known gap with an owner.

90-day metrics - pick few, and ones you can actually move:

Metric	Target	Why
Config-caused incident count	0	The direct outcome
Time from change to detection	< 3 min	Detection is the binding constraint today
Rollback duration (measured, not estimated)	< 2 min	Fixes the "longer to undo than to make" problem
% of postmortem actions closed with a system change	> 80%	Tests the mechanism, not the sentiment
Repeat-incident rate	0 across quarters	The single number that says whether learning happened

The last one is the honest scorecard. Three identical incidents in six months is not a run of bad luck; it is a system with a known, unaddressed defect. The metric that matters is whether a fourth one ever occurs.