postmortem ref

Status: ready — not yet trained.

Traits

Root Cause Depth

Identifies systemic root cause beyond the immediate trigger ↔ Stops at surface trigger or avoids causal analysis

Whether the postmortem identifies a genuine systemic root cause — the architectural gap, missing guardrail, or process failure that allowed the incident — versus stopping at the surface trigger ("a bad deploy", "human error") or hand-waving with "we're investigating."

Timeline Specificity

Concrete timeline with timestamps and observable events ↔ Vague narrative with no chronological anchor

Whether the postmortem provides a concrete chronological account with timestamps, actors, and observable state changes — versus a vague narrative that skips over what happened when, or collapses hours of incident response into a single paragraph.

Remediation Commitment

Named follow-up actions with owners and deadlines ↔ Vague reassurances with no concrete commitments

Whether the postmortem names specific follow-up actions with owners and timelines — architectural changes, new alerts, runbook updates, process fixes — versus vague promises like "we will do better" or "we are taking steps to ensure this doesn't happen again."

Blamelessness

Focuses on systems and process gaps, not individual fault ↔ Blames individuals, deflects to vendors, or scapegoats

Whether the postmortem focuses on systemic factors and process gaps rather than individual fault — treating human actions as symptoms of missing guardrails rather than personal failures — versus finger-pointing, naming individuals negatively, or deflecting blame to vendors/users.

Impact Transparency

Honestly quantifies blast radius and user impact ↔ Minimizes, hedges, or omits impact details

Whether the postmortem honestly quantifies the blast radius — affected users, duration, data loss, SLA breach, revenue impact — versus minimizing, hedging with "some users may have experienced," or omitting impact entirely.

About

Scores the quality of an incident postmortem or post-incident review.

What it measures

Whether a postmortem serves its purpose: helping the organization learn from failure and preventing recurrence. The model rewards postmortems that dig past the surface trigger to identify systemic root causes, provide a concrete timeline of what happened when, commit to specific remediation actions with owners, maintain a blameless tone focused on systems rather than individuals, and honestly quantify the impact rather than minimizing or hedging.

Feed the full postmortem text (or the body section of a published incident report) as input. Works for both internal PIRs and public incident communications.

Limitations

• Optimized for structured incident reviews in English. Brief status-page updates ("we experienced an outage, now resolved") will score low — they aren't postmortems.
• Does not verify factual accuracy of the timeline or root cause analysis — only whether the structure and depth are present.
• Postmortems for minor incidents may legitimately be shorter; the model doesn't penalize brevity per se, but rewards depth of analysis regardless of incident severity.

Pairs well with

• u22a8.crisis-comms — score the public-facing communication during the incident itself

Docs

• Tiers — categorical labels (Strong, Solid, Developing, Weak) assigned per trait
• Breaks — the per-trait trained boundaries between tiers