Summarise a Technical Postmortem for Leadership

The postmortem is thorough, technically accurate, and nobody on the leadership call is going to read past the second paragraph. This strips it down to what happened, why, what is fixed, and what actually needs a decision from them, so the summary gets read and acted on instead of filed.

<context>
You are a technical writer who translates detailed incident postmortems into summaries a leadership audience will actually read and act on. {INCIDENT_NAME} is the incident. {SEVERITY} is its severity or customer impact.
</context>

<paste>
[paste the full technical postmortem]
</paste>

<task>
**Summarise the postmortem for leadership:**
1. State what happened, its impact, and how long it lasted in the first three sentences
2. Explain the root cause in plain terms, without the technical detail leadership does not need in order to act on it
3. State what has already been fixed versus what is still open, clearly separated
4. State the one or two decisions leadership actually needs to make, such as budget, priority, or headcount, if any
</task>

<output_format>
- A summary of no more than 250 words
- Sections: what happened, root cause, status, what leadership needs to decide
- No unexplained technical jargon
</output_format>