Root cause before fixing

Root Cause Before Fixing

The most salient symptom is rarely the cause, and a signal that pattern-matches a familiar failure may have a different origin this time — evidence has to support the specific fix chosen, not just resemble a case where that fix once worked. Fixes aimed at symptoms make the problem quietly recur, now with less trust and a misleading "already fixed" label on it. The diagnosis happens first; the fix is its output.

Process

1. Pin down the actual failure. State what is observably wrong — the concrete error, number, or behavior — separate from interpretations already attached to it. If the report and the evidence disagree, the evidence wins.
2. Trace backward until the chain stops. Ask why the symptom occurs, then why that occurs, until you reach a cause which, if changed, prevents recurrence (Five Whys). Stopping at the first plausible "why" is how symptom-fixes happen.
3. Name the competing explanations. List the other causes that could produce this same symptom, and identify what evidence would distinguish them.
4. Checkpoint — before any fix is proposed: confirm the evidence in hand supports your specific cause and rules out (or at least disfavors) the alternatives. If it can't distinguish them, say so and either gather what would, or present the fix as conditional on the open question — not as settled.
5. Aim the fix at the demonstrated cause, and note what observation would confirm it actually worked, so a wrong diagnosis surfaces quickly instead of silently.

What this looks like

• Communications: Newsletter opens dropped — before rewriting subject lines, check whether the send list, send time, or deliverability changed that week; the fix differs entirely depending on which one did.
• Operations: A team keeps missing deadlines — before adding an approval step, trace which specific handoff slips and why; more process on the wrong step makes it worse.
• Code: A test fails with a timeout — before raising the timeout, check whether the operation genuinely got slower or is deadlocking; a bigger timeout hides the second.

Output rules

• Never narrate your own diligence ("I carefully verified...", "having ruled out...", "as instructed, I..."). The discipline shows in the work product — a fix that names its cause and why alternatives don't fit — not in self-description.
• Keep output proportionate to the task: a small problem gets a short diagnosis and fix, not a formal report.
• The tracing and ruling-out happen before or while producing the answer; only their results appear in the output, and only where they help the reader trust the fix.

Grounding: Anthropic, Prompting Claude Fable 5 (check evidence supports the specific action; pattern-matched signals may have different causes); Ohno 1988, Toyota Production System (Five Whys); Google SRE Book, Postmortem Culture.