8D step D4: the root cause and the escape point

The step most 8D reports get returned on, and why.

D4 asks for two root causes, not one. Why did the defect happen, and why did it get past you? A report that answers only the first will come back from the customer.

The two questions

	Occurrence root cause	Escape root cause (escape point)
Question	Why did the defect get made?	Why did the defect get shipped?
Lives in	The process that creates the feature	The control that should have caught it
Fixed in D5/D6 by	Changing the process, parameter or design	Changing or adding the detection control
Typical miss	Naming an operator instead of a mechanism	Not asked at all

The escape point is the earliest point in the flow where the defect could have been detected but was not. It is a different place from where the defect was made, and it almost always implies a different corrective action.

A worked example

Take a pressed terminal on an electronic assembly. The customer reports intermittent open circuits. Containment (D3) is done: suspect lots sorted, 100% continuity check added at shipping. D4 starts here.

Occurrence chain

Why did the circuit open?          Terminal not fully seated in the housing.
Why not fully seated?              Insertion force fell below the set point on 3 of 8 nests.
Why did the force fall?            Nest springs had taken a set after ~400k cycles.
Why did nobody replace them?       Springs were not on the preventive maintenance list.
Why not on the list?               PM list was built from the original BOM, which
                                   treated the springs as part of a bought-in nest.

Stop when the next "why" leaves the system you control. Here the actionable root cause is the PM list construction, not the spring.

Escape chain

Why did it ship?                   End-of-line test passed the part.
Why did the test pass it?           Test measured continuity at rest, not under vibration.
Why was it specified that way?      Test spec was carried over from the previous
                                   connector, which was crimped rather than seated.

Two different causes, two different owners, two different corrective actions. A report that lists only the spring will get a corrective action that never touches the test spec — and the next variant of the same defect ships again.

Verifying a root cause instead of asserting it

A root cause is verified when you can turn the failure on and off with it. That is the test, and it is what separates D4 from a plausible story.

Test	What it shows
Reproduce: set insertion force low on a good nest	The cause is sufficient to create the defect
Remove: restore force, run the same lot	The defect disappears
Explain the data: do the 3 failing nests match the field returns?	The cause accounts for the observed distribution, not just one part

If a cause passes the first two but fails the third — say the failures are spread evenly across all eight nests — you have found a cause, not the cause. Keep going.

The 5 Whys is a format, not a method. Five is not a target. Two whys can be enough; nine can be too few. The stopping rule is the only part that matters: stop when the answer is something you can change and when changing it would have prevented this defect.

Laying D4 out in Excel

D4 is where most 8D templates collapse into one merged cell. Split it so both chains are visible and both can be carried into D5:

Column	Holds
Cause type	Occurrence / Escape — a two-item data validation list
Why 1 … Why 5	One column each, not one merged text box
Root cause statement	The final, actionable sentence
Verification	Reproduce / Remove / Data — how it was proven
Carried to	The D5 action row ID

A simple completeness check that catches the most common rejection, as a formula rather than a reviewer's memory:

=IF(COUNTIF(CauseType_Range,"Escape")=0,
    "D4 incomplete: no escape point identified", "")

Put that in a cell near the D4 heading. It stays blank when the section is complete and says what is missing when it is not.

Before you send it

Both chains present, each ending in something you can change.
No person named as a root cause. "Operator error" is a symptom of a process that permits the error.
Each root cause has a verification, not an assertion.
Every root cause maps to at least one D5 action, and every D5 action maps back to a root cause.
D3 containment is still running until D6 corrective actions are verified effective.

Template

Our 8D Report Excel template lays out D1–D8 with a containment and corrective-action tracker, as plain .xlsx worksheet formulas — no macros, so the checks above are visible and editable. See also the AIAG-VDA FMEA rating guide: an escape point found in D4 is usually a detection rating in the PFMEA that was too optimistic.