"Operator error" is not a root cause: how to write a D4 that survives customer review

If you have handled supplier complaints for any length of time, you have seen this D4:

Root cause: Operator did not follow the work instruction.
Action: Operator retrained.

It is short, it is honest in its way, and it is almost always sent back. Not because the customer is being difficult, but because it answers the wrong question. This post goes deep on D4 only: why the common shortcuts fail, what a reviewer is actually looking for, and a way to self-check before you hit send.

(For the broader list of reasons 8Ds get rejected, see the previous post in this series. Here we only cover D4.)

What D4 is supposed to answer

A useful D4 answers two separate questions:

1. Occurrence: why was the defect made?
2. Escape (non-detection): why did it leave your plant without being caught?

Many reports answer only the first. Some answer neither and describe the defect again in different words. A reviewer reading D4 wants to see a causal chain that ends at something you can control - a process parameter, a design of a fixture, a missing check, a system gap - and evidence that the chain is real.

Shortcut 1: "Operator error"

"Operator error" describes who was standing there, not why the process allowed the defect. The follow-up questions write themselves:

• Was the work instruction clear, current, and at the station?
• Could the step be done wrong without anyone noticing? (No poka-yoke, no interlock, no visual cue.)
• Was the operator trained and was that training verified, or just signed?
• Did anything change - shift, staffing, cycle time, part revision, material lot?
• Do other operators on the same step make the same mistake?

If the honest answer is "the process makes it easy to do wrong," then that is the root cause, and retraining is at best a containment measure. If you genuinely believe an individual acted against a clear, error-proofed process, say so and show why the system still allowed it - but expect the reviewer to push.

Self-check: replace the word "operator" with "any trained person." Does your root cause still make sense? If it collapses, you have not reached the system level yet.

Shortcut 2: A cause with no evidence

The second common failure is a plausible cause with nothing behind it. "Root cause: tool wear" - but no tool-life record, no measurement of the worn tool, no comparison of good vs. bad parts.

Reviewers are looking for some form of verification, for example:

• Reproduction: you turned the cause on and the defect appeared; turned it off and it disappeared.
• Data: measurements, process records, or traceability that tie the failed parts to the suspected condition.
• Elimination: other candidate causes considered (fishbone, is/is-not) and ruled out with a reason.

You do not need all three. You need something a third party could look at and agree with. A 5-Why chain without evidence at each step is a story, not an analysis.

Self-check: for every "because" in your 5-Why, can you point to a record, a photo, a measurement or a test? Mark the ones you cannot. Those are your gaps.

Shortcut 3: Missing escape cause

This one is easy to miss. The team does a solid occurrence analysis, then stops. But the customer received the bad part, so something in your detection chain also failed:

• Was there a check for this characteristic at all?
• If yes, why did it not catch it? Gauge capability, sampling frequency, inspection method, lighting, reaction plan not followed?
• If no, why not? Was the characteristic not identified as critical in the PFMEA / control plan?

The escape cause usually leads to a different corrective action than the occurrence cause, and that matters for D5/D6. If you only fix occurrence, the next unrelated defect on that characteristic will escape the same way.

A short guide on the escape point specifically: https://8d-gate.vercel.app/8d-escape-point

Shortcut 4: Root cause that just restates the problem

"Root cause: dimension out of tolerance." That is D2, not D4. A quick test: if your root cause would fit as the problem description, you have not moved.

A D4 structure that tends to hold up

Not a template you must follow, just a shape that makes the reviewer's job easy:

1. Problem recap (one line) - link back to D2, do not repeat it.
2. Method - which tools you used (is/is-not, fishbone, 5-Why, fault tree) and who participated.
3. Occurrence root cause - the systemic cause, stated in one sentence.
4. Occurrence evidence - what verifies it (reproduction, data, elimination).
5. Escape root cause - why detection failed, in one sentence.
6. Escape evidence - same standard.
7. Candidates ruled out - briefly, with reason. This shows you did not jump to the first plausible answer.

If one of these is genuinely unknown yet, say so and give a date. A transparent "verification in progress, due on X" generally reads better than a confident cause without proof.

More detail on writing D4: https://8d-gate.vercel.app/how-to-write-d4-root-cause-8d

Check it before the customer does

I built 8D Gate to do exactly this pre-send check: paste your 8D (anonymised is fine) and it returns Accept / Conditional / Reject with the specific gaps - including "operator error" causes, unverified causes and missing escape analysis. It is free, takes under a minute, and it is not allowed to invent evidence you did not provide.

Free check: https://8d-gate.vercel.app/review?utm_source=devto&utm_medium=article&utm_campaign=weak-d4

Advisory only. 8D Gate gives a pre-send readiness opinion (Accept / Conditional / Reject). It does not replace your customer's SQE, your own quality sign-off, or any IATF/OEM requirement. It will not invent evidence; if something is missing, it says so.

If you review supplier 8Ds for a living, I would genuinely like to hear which D4 pattern you send back most often. Comments are open.