Five Whys with Stop Rule¶

Root-cause method — instantiates Regress Termination Rule

Follows a causal 'why' chain down to the first level where a durable action can be taken, then stops on a named rule rather than chasing causes forever.

Ask "why did this happen?" and the answer invites another why, and another — a causal regress that can bottom out shallow ("human error") or spiral into the unactionable ("because the company exists"). Five Whys with Stop Rule disciplines that descent: it walks the chain of causes deliberately, but pairs the walking with an explicit stopping rule — halt at the first cause the team can actually own and fix with a durable countermeasure — plus a reopening trigger for when the fix doesn't hold. What makes it THIS mechanism is that it operates on the causal regress ("why did it occur?"), not the evidentiary one ("what backs this claim?"), and that the plain iterative technique becomes a termination rule only once the stop level and the review trigger are named.

Example¶

A run of hydraulic pumps ships with leaking seals. The team walks it: Why did they leak? The seals failed. Why? The wrong seal material was fitted. Why? Purchasing ordered against an outdated drawing. Why? The drawing wasn't revised after a design change. Why? There is no step that notifies purchasing when a design changes. Here the stop rule bites: the last answer is the first cause the team can own and durably fix — add a change-notification handshake between design and purchasing — so the chain stops there, rather than sliding one more step into "the org is siloed," which no seal engineer can fix this quarter. It also stops deep enough: halting at "the operator should have caught it" would have blamed a person and left the systemic gap in place. The team records a reopening trigger — if any wrong-spec part recurs after the handshake ships, reopen and go deeper — and moves on.

How it works¶

Iterate why on causes, not claims. Each step asks what caused the prior condition, building a visible causal chain from symptom toward system.
Apply the stop rule. Halt at the first cause that is both systemic (not "someone slipped") and ownable (the team can install a lasting countermeasure), which is usually — not always — a few steps down.
Guard both ends. Refuse to stop at individual blame (too shallow) and refuse to chase causes no one present can act on (too deep).
Wire the reopening trigger. Name the observable — typically recurrence of the same failure — that reopens the inquiry and pushes the chain further.

Tuning parameters¶

Stop-level definition — what counts as "actionable and systemic." Setting it at the team's span of control closes fast; setting it at the organization's invites a bigger, slower fix.
Branching — a single chain versus following several causal branches. One chain is quick but tunnel-visioned; branching catches parallel causes at the cost of sprawl.
Depth cap — a maximum number of whys before escalating rather than deepening. A cap prevents spirals but can freeze the stop above the real cause.
Reopening sensitivity — how strict the recurrence trigger is. A tight trigger reopens on the first repeat; a loose one tolerates noise but may let a bad fix ride.

When it helps, and when it misleads¶

Its strength is cheapness and momentum: with no instrumentation it pushes a team past the symptom to a fixable systemic cause, and the stop rule is what keeps a genuinely useful technique from either blaming a person or dissolving into infinite regress. It shines on operational incidents and recurring defects.

Its notorious failure is stopping at "human error" — a shallow terminus that satisfies the form of the method while leaving the system untouched — or, inverted, treating the deepest imaginable cause as the "true" one and paralyzing action. A single chain also invites narrative capture: the method is easily run backwards to land on the root cause that exonerates whoever is running it. The discipline that guards against this is to require the stop to be systemic and ownable, to sample more than one causal branch, and to hold the reopening trigger so a wrong stop is caught by recurrence.^[1]

How it implements the components¶

regress_chain — the ladder of why-questions is the visible causal regress, made explicit link by link from symptom to system.
stopping_criterion — the "first systemic, ownable cause with a durable countermeasure" rule is the concrete criterion that halts the chain.
reopening_condition — the recurrence trigger defines the observable that reopens the inquiry when the countermeasure fails to hold.

It does not grade whether each causal link is evidentially proven (sufficiency_threshold → Evidence Sufficiency Rubric), name foundational premises (foundational_assumption → First-Principles Statement), or allocate who must justify the fix (burden_of_reopening → Burden-of-Proof Rule).

Instantiates: Regress Termination Rule — it terminates the causal regress at an actionable level.
Sibling mechanisms: Review Trigger Register · Decision Closure Criteria · Evidence Sufficiency Rubric · Burden-of-Proof Rule · Axiom Set · First-Principles Statement · Governance Authority Chain · Research Stopping Rule · Timeboxed Inquiry Record · Assumption Log

Notes¶

The regress here is causal, not justificatory: Five Whys asks why something happened, and a cause is not automatically a reason to act — a durable countermeasure still has to be chosen and justified separately. Treating the discovered "root cause" as a self-justifying mandate is the quiet slippage this method invites.

References¶

[1] The Five Whys originated in the Toyota Production System (attributed to Taiichi Ohno) as a way to reach a systemic root cause rather than a proximate symptom. Its documented weakness — converging on a single, often blame-shaped answer — is exactly what the stop rule and reopening trigger are meant to counter. ↩