/five-whys

name: five-whys
description: 'Run an evidence-grounded five-whys RCA: claims verified by fact-checker subagents, causal links stress-tested by a cynic subagent. For internal RCAs, post-mortems, "why did this happen". Not for customer-facing incident write-ups.'

Five whys — grounded and adversarially verified

Build a causal chain from impact to actionable root cause using the classic five-whys technique (https://en.wikipedia.org/wiki/Five_whys), with two additions the classic method lacks: every fact is verified against a primary source, and the finished chain must survive an adversarial review before it ships. The output is only done when a skeptical expert reading it can re-derive every claim from the cited evidence.

Ground rules (non-negotiable)

1. **Every factual claim cites a primary source.** A metric query you ran, a code line (`file:line`), a log entry, a config value read from the live system, a timestamped event. "The incident doc says" and "everyone knows" are not sources. Keep the query, link, or path next to the claim so a reader can re-run it. 2. **Label every claim's epistemic status.**

• **Measured** — you or a subagent observed it directly during this

investigation.

• **Derived** — arithmetic on measured values; show the arithmetic.
• **Inferred** — a best-fit mechanism not yet directly observed. An

inferred claim MUST name the observation that would confirm or refute it ("inference, pending X"). Never present an inference as fact. 3. **Re-verify inherited numbers.** Figures from earlier write-ups, tickets, dashboards, or drafts get re-measured, not copied. Stale blast-radius numbers and wrong mechanisms survive in RCA docs precisely because nobody re-checks them. 4. **Verify mechanisms at the source.** A plausible mechanism is not a verified one. Read the actual code path, config, or vendor source before asserting "X does Y". The most dangerous RCA errors are confident, plausible, wrong mechanism claims. 5. **Normalize timestamps to UTC before any elapsed-time math.** Mixed-timezone subtraction silently corrupts the timeline and every claim built on it. 6. **Honour stated constraints.** If an owner has declared a constraint (for example "this setting is customer-facing and stays where it is"), a fix that violates it can appear only as a labelled break-glass mitigation, never as the standing recommendation. 7. **Claims about people and ownership need the same evidence as claims about systems.** Never assert "no owner" or "team X ignored Y" without proof. Prefer testable framings: "no standing signal prompted review" can be checked; "nobody cared" cannot.

Process

1. Frame the impact

One short paragraph: who was affected, when (UTC), how badly, measured how. Precise numbers, with floors and ceilings stated as such ("at least 1,200 accounts" if the count is a floor). This is "why zero" — every subsequent why must chain back up to it.

2. Gather evidence, then draft the chain

Collect the timeline, metrics, code paths, and configs FIRST. Draft the chain from the evidence, not from the incident channel's first theory. For each why:

• **One causal step per why.** If the answer needs "and also", either split

into two whys or branch explicitly ("two loads coincided: a standing load and an acute trigger") and carry both branches down the chain.

• **Test each link four ways:**
• **Timing** — cause precedes effect on a UTC-normalized timeline.
• **Mechanism** — a named, source-verified path from cause to effect.
• **Magnitude** — the numbers are large enough to explain the effect.
• **Necessity** — hunt for a control or counterfactual: an occasion when

the trigger fired WITHOUT the cause and the effect did not follow. A good control is the single strongest piece of evidence a chain can carry.

• A link that fails any test is not ready for verification — fix it or label

the gap as an open inference.

3. Fact-check every claim (subagents, in parallel)

Dispatch one fact-checker subagent per why via the `Agent` tool, all in a single message so they run concurrently. Default `model: "sonnet"`.

The numbered whys are not the whole document. Dispatch a checker for every other section that carries factual claims too — the impact frame (blast radius, timing, how it was measured), the root causes, and each open inference. These are exactly the claims that get quoted onward, so an uncovered one defeats the promise that every fact in the chain was verified. One checker per section is enough; batch them into the same message as the per-why checkers.

Each dispatch prompt contains:

• The why's full text (question + answer + cited evidence).
• Where the evidence lives and how to reach it: repo paths, query URLs, log

locations. If reaching the evidence depends on a skill (for example one that wraps your metrics, tracing, or error-tracking tools), the dispatch prompt must tell the checker to invoke that skill FIRST — the parent's skill load does not carry into a subagent.

• This instruction, verbatim:

> Independently verify every factual claim in the text below. For each claim > return a verdict: CONFIRMED (you reproduced it from a primary source — name > the source), UNSUPPORTED (you could not find evidence either way), or > CONTRADICTED (the source says otherwise — quote it). Do not assess whether > the causal story is convincing; check only whether the stated facts are > true. Re-run queries rather than trusting quoted numbers. Return a compact > claim-by-claim table, nothing else.

4. Cynic pass (subagent)

After the fact-checks come back clean, dispatch one cynic subagent with the FULL chain (it needs cross-link context). Default `model: "sonnet"`. This is the hardest reasoning stage, so a stronger model is tempting — escalate only if the user asks for it. Its prompt, verbatim:

> You are a skeptical senior engineer reviewing this root cause analysis