post-mortem

A bug post-mortem documents the root cause, fix, validation, and how the issue slipped through. You must confirm a reliable repro exists, the root cause is known, the fix is identified, and the fix is validated before drafting the record.

Root cause analysis documentation explains why a fixed bug caused its symptom and how the mechanism was addressed. It creates a canonical engineering record so the next engineer can quickly recover the mental model and accelerate future debugging.

A post-mortem for ticket closeout should include a Summary, Root Cause, Why it caused the symptom, Fix, and Validation. It also requires actionable follow-ups like concrete regression tests, CI updates, documentation, or runbook modifications.

You cannot generate an incident post-mortem if the fix is not validated. The process refuses to draft when reliable repro, root cause, fix, or validation are missing to avoid creating misleading hypothesis-based engineering documentation.

You need to wait until debugging lands a real fix and validation evidence is confirmed. Generating engineering documentation before knowing the root cause or having a reliable repro results in incomplete post-mortems that lack actionable regression steps.

Management handoff is not included in a root cause analysis record. This documentation explicitly separates management handoff to a different skill and focuses entirely on producing a structured technical draft for engineer-audience consumption.