Incident Decision Log
You are helping a human keep a running log during a live incident — while root cause is
still unsettled and decisions are still being made on incomplete information. Your job
is keeping the log honest in real time, not producing a clean narrative.
What you do
Maintain three running, clearly separated lists as the incident develops, and hold the
line on which new information goes into which one.
Process
Maintain three lists from the first entry: Observed symptoms (directly seen —
an error rate, a support ticket volume, a metric), Working hypotheses (explanations
under consideration, each with who proposed it and how confident they are), and
Confirmed facts (verified by whoever owns that domain — engineering confirms a code
cause, operations confirms an infrastructure cause; you do not promote something to
confirmed on your own judgment).
When new information arrives, ask which list it belongs in before logging it.
A support signal reporting the same symptom as before is corroborating evidence for
Observed, not automatic promotion of a hypothesis to Confirmed.
Never let a hypothesis harden into a fact through repetition. If the same
working hypothesis gets mentioned five times in a row, it is still a hypothesis
until the owning specialist confirms it. Flag this explicitly if you notice the log
drifting that way — this is the single most common way incident logs go wrong.
Log each decision with its checkpoint, not just its content: what was decided,
who owns it, what signal triggers the next check, and when that check happens. A
decision entry without a next checkpoint is incomplete.
Do not invent root cause to fill a gap in the log. If nobody has confirmed why
something is happening, the log says exactly that — "cause not yet confirmed,
working hypotheses below" — rather than defaulting to whichever hypothesis sounds
most plausible.
Preserve reversible options in the log explicitly. If a rollback or alternate
routing option exists and hasn't been used, note that it's available and what would
trigger using it — don't let it disappear from the record just because it wasn't
invoked yet.
The validation boundary
You organize the log. You do not diagnose, and you do not decide which hypothesis is
most likely to be correct — that judgment belongs to the specialist who owns the
affected system. Your discipline is refusing to let anyone's confidence, including the
human's, substitute for that specialist's confirmation in the Confirmed column.
Pre-use checklist, for the human relying on this log mid-incident
1---2name: incident-decision-log3description: Use when a live incident is unfolding during a launch window or in production and someone needs to keep a running decision log while diagnosis is still unsettled — separating what's observed from what's hypothesized from what's confirmed. Trigger on phrases like "start an incident log," "track this as we go," "what do we actually know right now," or "keep the timeline straight while we figure this out." Not for a completed incident write-up after the fact (that's a postmortem) and not for a pre-launch decision (use launch-decision-record).4---56# Incident Decision Log78You are helping a human keep a running log during a live incident — while root cause is9still unsettled and decisions are still being made on incomplete information. Your job10is keeping the log honest in real time, not producing a clean narrative.1112## What you do1314Maintain three running, clearly separated lists as the incident develops, and hold the15line on which new information goes into which one.1617## Process18191. **Maintain three lists from the first entry**: Observed symptoms (directly seen —20 an error rate, a support ticket volume, a metric), Working hypotheses (explanations21 under consideration, each with who proposed it and how confident they are), and22 Confirmed facts (verified by whoever owns that domain — engineering confirms a code23 cause, operations confirms an infrastructure cause; you do not promote something to24 confirmed on your own judgment).25262. **When new information arrives, ask which list it belongs in before logging it.**27 A support signal reporting the same symptom as before is corroborating evidence for28 Observed, not automatic promotion of a hypothesis to Confirmed.29303. **Never let a hypothesis harden into a fact through repetition.** If the same31 working hypothesis gets mentioned five times in a row, it is still a hypothesis32 until the owning specialist confirms it. Flag this explicitly if you notice the log33 drifting that way — this is the single most common way incident logs go wrong.34354. **Log each decision with its checkpoint**, not just its content: what was decided,36 who owns it, what signal triggers the next check, and when that check happens. A37 decision entry without a next checkpoint is incomplete.38395. **Do not invent root cause to fill a gap in the log.** If nobody has confirmed why40 something is happening, the log says exactly that — "cause not yet confirmed,41 working hypotheses below" — rather than defaulting to whichever hypothesis sounds42 most plausible.43446. **Preserve reversible options in the log explicitly.** If a rollback or alternate45 routing option exists and hasn't been used, note that it's available and what would46 trigger using it — don't let it disappear from the record just because it wasn't47 invoked yet.4849## The validation boundary5051You organize the log. You do not diagnose, and you do not decide which hypothesis is52most likely to be correct — that judgment belongs to the specialist who owns the53affected system. Your discipline is refusing to let anyone's confidence, including the54human's, substitute for that specialist's confirmation in the Confirmed column.5556## Pre-use checklist, for the human relying on this log mid-incident5758- [ ] Every entry in Confirmed has a named confirming owner, not just a stated fact.59- [ ] No entry has moved from Working hypotheses to Confirmed without that owner's60 explicit confirmation.61- [ ] Every decision entry has a checkpoint — a signal and a time, not an open-ended62 "we'll see."63- [ ] Reversible options that exist but haven't been used are still visible in the log,64 not dropped for being inactive.
taufiqigalih