6

Root cause, not symptom

Module 3 · Structure. After this lesson you can: apply a five-step diagnostic loop to find and fix the structural cause of any repeating problem, not just its latest symptom.

Consider a team that fixed the same problem three times. Each time, something misbehaved, they asked their AI to investigate, a plausible cause was found and patched, and the problem disappeared. Two weeks later it returned wearing slightly different clothes. Another plausible patch, another apparent resolution. A month later, a third appearance in a third form. Three intelligent fixes, by capable people working with capable tools, and the problem outlived them all.

What each fix had in common was its aim: each one targeted the place that hurt, not what kept producing the hurt. The breakthrough came from a different question: "What would have to be true for this to keep happening?" That question stops looking at the latest symptom and begins mapping the structure that generates symptoms.

The five-beat loop that reliably surfaces the root cause of any recurring problem begins with Reproduce: see the problem happen directly, not through a description of it, because descriptions compress and lose information. Next, Hypothesize: write down two or three candidate causes before acting, because a single first guess has already committed to one answer and is overconfident by construction. Then Isolate: check which hypothesis survives contact with evidence. Fix the cause, not the symptom. Finally, Verify: confirm the fix held and look around it, because structural causes rarely travel alone.

The discipline of writing multiple hypotheses before touching anything matters more than it first appears. The first candidate often echoes the most recent patch, which is why that patch failed to hold. The third candidate tends to be where the structural issue hides. In the scenario above, the third hypothesis identified that two components had quietly disagreed about a shared definition from the beginning. Every bug had been the latest place their disagreement surfaced. Fixing the definition resolved the original problem and, without any additional work, removed two other persistent irritants that had been the same disagreement appearing elsewhere.

A useful technique in the isolate step is asking an AI to argue against the leading hypothesis. Prompted to list evidence against the most appealing explanation, an AI will often surface the counterpoint that reveals the actual cause. The goal is not to disprove the first guess; it is to be certain before committing to a fix.

A recurring problem is never bad luck. It is a structure not yet found. The question "what would have to be true for this to keep happening" converts any repeating breakage into a map of that structure. Problems are diagnostic signals: they reflect how a system actually behaves, not how it was intended to behave.

Stop here. Sit with this question before continuing.

Why did the fix not fix it?

Try this nowUnder 30 minutes
  1. Pick something currently or recently broken. Tech or not. A device, a recurring miscommunication, a process that keeps failing the same way.
  2. Before any fixing, write three candidate causes. Force a full three. The third is usually where the structural cause hides.
  3. Ask your AI to play the skeptic: "Here is the problem and my three hypotheses. What evidence would distinguish them? Argue against the leading one."
  4. Check, then fix the survivor. Aim the fix at the cause that held up, not the symptom that hurt.
  5. Note your hit rate. Was the first hypothesis the actual cause? Track the pattern across multiple breakages. The calibration this builds is the skill being trained.

Two questions before you go

Answer, then say whether you were sure or guessing. Being honest about which is the skill being trained.