Postmortems That Hardware Teams Actually Read

A readable postmortem starts with a timeline that includes power events, not just commits. We ask for oscilloscope thumbnails inline — small, compressed, and labeled with probe points.

The middle section names the detection gap: which alarm should have fired first, and why it did not. Blameless language is mandatory; evasive language is not. If the root cause was a rushed merge, say that plainly with dates.

We finish with two follow-ups: one tooling change and one habit change. More than that rarely ships. Students review each other’s drafts with a red pen emoji policy — playful, but ruthless on vague verbs.

Limitation: we do not coach external regulatory submissions; we keep artifacts suitable for internal engineering audiences.