# Blameless Postmortem Writer
Standard postmortem structure for a production AI incident.

_Draft a blameless postmortem for an AI incident. Standard sections, no finger-pointing, action items that are actually actionable._

Used in: Lesson expert/05 — https://vetslearn.com/lessons/expert/05
Source: https://vetslearn.com/resources/templates/prompts#t-postmortem-writer

---

## Context
You are an SRE who has written postmortems for production AI systems. You write blameless postmortems — the goal is to fix the system, not blame the person. You know the difference between a root cause and a trigger.

System: [SYSTEM]
Incident start: [INCIDENT START]
Incident end: [INCIDENT END]
User impact: [USER IMPACT]
What we know about the root cause so far: [ROOT CAUSE — what you know so far]
How it was detected: [DETECTION METHOD]

## Task
Write the postmortem with these sections in order:

1. **Summary.** Three to five sentences. What happened, when, what was impacted, what we did.
2. **Timeline.** Bulleted, timestamped, in order. Include detection, escalation, mitigation, resolution.
3. **Root cause.** What actually broke and why. Distinguish root cause from trigger. If the root cause is still under investigation, say so.
4. **Impact.** Quantified where possible. Users affected, requests affected, dollar impact if known.
5. **Action items.** Each one has an owner, a due date, and a clear definition of done. No vague "improve monitoring."
6. **What went well.** Three things that worked. This is not filler — it is what we preserve.

## Standards
- Blameless. No names attached to mistakes. Roles only.
- Plain language. An exec and an engineer should both be able to read it.
- If I gave you incomplete information, say [UNKNOWN — investigate] and move on. Do not invent.
- One page max.

---

**Why this works**

The sections are the standard SRE structure for a reason — they cover what executives need (summary, impact) and what engineers need (timeline, root cause, action items). The "what went well" section is the one most postmortems skip and most teams regret skipping. Forcing action items to have an owner and a definition of done is what makes the postmortem produce change instead of just documentation.

## Check before you use it

- Check every timeline timestamp against logs and the incident channel.
- Have the engineer closest to the incident read the root cause section.
- Every action item needs an owner who agreed to own it.
- Resolve [UNKNOWN — investigate] items or carry them as open questions. Do not delete them.