latent-sre/save-toolkit/postmortem

Blameless postmortem

Whoever applies this skill, scribe's postmortem mode or the main thread, first gathers the supplied incident timeline, severity, and the incident record's root-cause evidence (the advisor's closeout packet and any sre-assistant slices); given only an incident ID, ask for them rather than drafting placeholders. Preserve every [verified], [sourced], and [unverified] label; never upgrade one.

Use the postmortem template: full for P1/P2 or an explicit full review; abbreviated for P3/P4 and near-misses unless policy or the owner requires full depth. Keep unknown severity as YAML null; draft the full form when the evidenced impact was customer-visible or multi-service, otherwise abbreviated, state the choice and its reason, and confirm it with the owner before finalizing. A summary/explanation request gets only that answer, not a completed postmortem by implication.

Fill the selected form's required facts from evidence, marking missing facts [unverified] and genuinely inapplicable requirements n/a — why. Omit the unselected form and optional empty sections. Use the template's nullable times; preserve impact end separately from human resolution confirmation.

For full causal analysis, fit the evidence: Five Whys, a fault tree, causal graph, or another method. Name it, preserving branches and uncertainty rather than forcing a line count or linear story.

Blameless stance

Explain decisions from the information available then. Human error is not the root cause; identify system conditions. Separate trigger from mechanism and failed defenses; aim to reduce recurrence or impact, never promise zero recurrence.

• "No data loss" needs evidence — state explicitly

what was checked (row counts, checksums, replay of the write path) or mark it [unverified].

• Assess detection, not who detected it. Name the source, delay, available signals, and noise.

Human detection is not automatically a gap. Propose observability-engineer follow-up when evidence supports an actionable, earlier signal worth its paging cost.

Action items that reduce risk

• Prefer systemic risk reduction over "be more careful." Tag actions mitigative (impact/recovery)

or preventative (recurrence), with the risk reduced and remaining limits; no category quota.

• Every action has an artifact and proof-of-done check, owner, due date, and tracking link.
• When proof depends on missing instrumentation, include that prerequisite with the action and keep

it blocked until the signal, exporter, code, or pipeline/config change lands. Unrelated actions need no instrumentation field.

• Route resilience and toil/automation design and economics to reliability-engineer, accepted

implementation to software-engineer, detection/SLO to observability-engineer, open causal questions to sre-assistant (operational evidence) or software-engineer with root-cause (code), deploy/rollback safety to the human release owner, and operating documents to scribe.

• Resolved impact does not require a known cause. Mark unconfirmed causes [unverified] and give

unresolved causal questions an owner and next check; do not block the write-up on certainty.

Operational learning closeout

Keep one Follow-ups record with incoming IDs; after the write-up, knowledge closeout (operational-learning) enriches those rows with artifact dispositions.

Lessons — include "where we got lucky"

Use evidenced successes, gaps, and narrowly avoided failures. A revealed risk warrants a justified follow-up or explicit accepted risk, not an invented action to fill the template.