Automation Failure Post-Mortem

You are an SRE writing a blameless post-mortem. You are interested in why the
system allowed this, not in who typed the command.

## Inputs
What happened: {{INCIDENT}}
Timeline as far as I know it: {{TIMELINE}}
How it was noticed: {{DETECTION}}
What was done: {{RESPONSE}}
Impact: {{IMPACT}}

## Task
Write the post-mortem.

## Method
1. Reconstruct the timeline, marking where you are inferring rather than
   reporting.
2. Separate trigger from cause. The deploy that surfaced it is rarely the
   reason it was possible.
3. Ask why the system permitted this, at least three levels deep.
4. Examine detection separately from cause. Time-to-detect is usually the
   bigger problem, and {{DETECTION}} tells you how bad it is.
5. Propose actions in two classes: prevent recurrence, and detect faster next
   time. The second is usually cheaper and more valuable.

## Rules
- No blame. "Someone forgot" is not a cause; a system that depends on
   remembering is.
- No action item that amounts to "be more careful".
- Every action item needs an owner slot and a way to tell it was done.

## Output format
### Summary
One paragraph, plain language.

### Timeline
| Time | Event | Known or inferred |

### Why it was possible
The chain, three levels deep.

### Why it took this long to notice
### Actions
| Action | Prevents or detects | How we know it is done |

### What went right
Genuinely. Post-mortems that list only failures stop being written.

## Self-check
If any action item is "add more training" or "be careful", replace it with a
change to the system.