Why until bedrock: a better Five Whys with contrast, kinds of why, and a real place to stop

A better Five Whys asks “why this rather than that?” at every step, says what kind of why it is asking, lets the answer branch into more than one cause, and stops at bedrock (for example, a cause you can check or change, a law, a value you choose, or a risk you accept on purpose) instead of stopping at the fifth answer.

The Of One method calls this why until bedrock. Its repo puts the whole idea in one line: “The useful idea inside Five Whys is causal descent, not the number five.” This guide shows what to keep from Five Whys, what to fix, and how to run one descent from start to finish.

Where Five Whys comes from, and where it breaks

Five Whys is a question-asking technique from Toyota’s manufacturing tradition. Wikipedia describes it as an iterative technique for exploring the cause-and-effect relationships underneath a problem, credits the modern technique to Sakichi Toyoda, and quotes Taiichi Ohno, the man Toyota credits with helping establish the Toyota Production System, calling it the basis of Toyota’s scientific approach.

It works because it refuses the first answer. Wikipedia’s example begins with bolts cross-threading on a production line and, after five whys, reaches a rusted shelf foot that spilled the cutting tools.

Wikipedia also lists the common criticisms. People stop at symptoms. The method cannot find causes the investigator does not already know about. Two people asking the same whys can reach different answers. It pushes toward a single root cause when there may be several. And there is nothing special about the fifth why.

Of One keeps the descent and addresses most of those problems with four changes: a contrast, a kind, a branching graph, and a typed place to stop. The repo does not claim it can discover a cause nobody thought to look for.

Change 1: ask “why P rather than Q”

“Why did sales drop?” is an incomplete question. It has several different true answers depending on what you compare against.

Why did sales drop rather than hold steady? (Something changed over time.)
Why did sales drop in this region rather than the others? (Something differs between places.)
Why did sales drop for this product rather than the rest of the line? (Something differs between products.)

Each contrast points at a different cause. The repo requires every step down to state its contrast, because the contrast decides what counts as a relevant answer.

Change 2: name the kind of why

“Why” can ask for very different things. Mixing them up is how bad root causes get accepted.

Kind of why	What it is asking for
Cause	An event or condition that made the result more likely
Mechanism	The process by which the cause produced the result
Motive	The reason a person had for acting
Purpose	The job the thing does in a larger system
Justification	Why something should be believed or allowed
Definition	What makes it count as what it is
Enabling condition	What made it possible without causing it alone
Constraint	What ruled out the alternatives
Historical origin	The path by which the present setup came to be

The repo’s warning is plain: a motive is not automatically a cause, a purpose is not a history, and a justification is not evidence that a mechanism occurred. “We changed carriers to save money” is a motive. It tells you nothing yet about why customers stopped coming back.

Change 3: let it branch

A real effect can have several causes at once, causes that only work together, delayed causes, feedback loops, and causes at different scales. So the method draws a branching graph, not a line. It also warns when no alternative cause was considered.

For every causal step, write down a test: what would be different if this cause were absent (a counterfactual test), or what change you could make that should move the result (an intervention test). A cause with no test is still a guess.

Change 4: stop at typed bedrock

The method stops descending when the current answer reaches bedrock, and it says which kind. The repo’s list, in plain words:

Bedrock type	Plain meaning
Decision-sufficient	Going deeper would not change what you do
Observable mechanism	You can watch the process happen
Controllable root cause	A cause you can change
Invariant or law	Something that holds, such as a physical law
Axiom or definition	A starting rule or a meaning you agreed on
Value commitment	A value you choose to hold
Authority boundary	A decision that belongs to someone else
Irreducible randomness	Chance that no further question removes
Inaccessible or unidentifiable	You cannot see further with what you have
Frame boundary	The question now belongs to a different frame
Accepted residual risk	A known gap that a named person has accepted

Every bedrock carries three notes: that it is relative to this question, why you stopped, and what would make you start digging again. The repo is explicit that bedrock is relative to the question you are asking: the traversal “never claims final metaphysical explanation.”

Before you stop, run the repo’s bedrock test in short form. Is the step typed? Is it more than a restatement of the problem? Does it match the kind of why you asked? Is there evidence, or is it clearly marked as a hypothesis? Does a causal claim have a test? Did you consider other causes? Would going deeper be worth less than it costs? Is there a condition that reopens it?

Mistakes the method is built to catch

The repo names the failure modes it checks for:

Arbitrary depth: stopping because you reached five.
Circularity: P because Q, and Q because P.
Tautology: restating the problem in other words (“sales fell because fewer people bought”).
Mono-causal story: squeezing several interacting causes into one neat line.
Motive substitution: treating the reason someone gave as the mechanism that actually happened.
Correlation substitution: treating “it predicts” as “changing it will change the result.”
Root-cause theater: picking the most controllable cause instead of the one best supported.
Bedrock laundering: calling something you cannot see a resolved root cause.

A worked descent (illustrative)

This example is invented to show the steps. It is not a real business.

The effect. A small online tea shop sees repeat orders fall this quarter.

Step 1. Why did repeat orders fall this quarter rather than hold steady? (Kind: cause.)

Three candidate branches:

A. Seasonality. Tea sales slow in summer.
B. A competitor’s discount. A larger shop ran a sale in the same weeks.
C. Slower delivery. The shop switched shipping carriers at the start of the quarter.

Branch A is rejected. The shop’s own records show repeat orders held steady in the same quarter last year. The contrast (this quarter rather than a normal year) rules seasonality out as the main cause. Reopening condition: if two more years of records show a summer dip, A comes back.

Branch B stays open, as a contributor. The competitor’s sale is real, but repeat orders fell among customers in every region, including those unlikely to have seen the sale. Status: hypothesized, low confidence. It is kept on the tree, not deleted.

Branch C is supported. The drop is concentrated among customers whose last order shipped with the new carrier. Counterfactual test: a few orders during the switchover still went out with the old carrier, so those customers should show a smaller drop if C is right, and they do.

Step 2. Why did delivery slow down rather than stay the same after the switch? (Kind: mechanism.)

The new carrier picks up once a day, in the morning. Orders placed after pickup wait almost a full day before they move. The old carrier picked up in the late afternoon.

Step 3. Why a morning-only pickup rather than a later one? (Kind: historical origin, then constraint.)

The shop chose the carrier’s cheapest plan, and that plan includes only one fixed pickup. The motive (“save money”) explains the choice, but it is not the cause of lost repeat orders. The cause is the pickup time.

Bedrock: controllable root cause. The pickup schedule is something the shop can change: pay for a later pickup, go back to the old carrier, or move the packing shift earlier.

Why stop here: the next question (“why is the cheap plan cheap?”) belongs to the carrier and would not change the shop’s move. That is also an authority boundary.
Intervention test: send half of the orders on a later pickup for four weeks and compare repeat rates between the two halves.
Reopening condition: if repeat orders do not recover in the later-pickup half, reopen the tree, starting with branch B.

Notice what the descent did not do. It did not stop at “we changed carriers,” which is a symptom. It did not blame the owner’s motive. It did not throw away the competitor branch just because it was not the main story. And it ended in something the shop can test within a month.

Do it today

Write the effect in one sentence, with a contrast: “X rather than Y.”
List at least two candidate causes. Name the kind of each why.
For each cause, write the test that would support or reject it.
Reject branches only with a reason, and give each rejection a reopening condition.
Keep going down the supported branch until you reach a bedrock type from the table.
Write down why you stopped and what would reopen it.

This descent is one of the challenge checks Of One requires before a decision is released; the others are in Kill tests. To see where the descent sits on the whole map, read What goes on a decision map. The /ask/ tool includes a short “why this goal and not another?” step, and the method page covers bedrock in full.