Two Years to Describe One Defect: What Toyota's Recall Teaches About Problem Definition
Toyota needed two years to pin down one software defect. The fix took weeks. What the recall file teaches about problem definition in 8D, and how to do it right.
In August 2026 Toyota recalled 508,354 Camry Hybrids in the US. The defect had been reported two years earlier.
The recall file at the US regulator tells the whole story, step by step. Read it slowly.
July 2024: first field reports. The instrument cluster stays blank at startup. Field testing cannot reproduce it.
October 2025: suspicion falls on software. Toyota and its supplier build dedicated diagnostic equipment.
Late 2025: first reproduction on a test bench. April 2026: on-off cycle testing fails to trigger it. July 2026: a whole-vehicle test finally induces the failure.
Two years to the moment they could call up the defect on demand. Then weeks to the fix - a software update to the combination meter.
Why we know this at all
We know this story only because US law requires it. Under 49 CFR 573.6, a manufacturer must submit a written chronology of its investigation with every recall.
The EU has no equivalent document. Safety Gate publishes the alert and the risk, not the path to the cause. This year it lists 278 motor-vehicle alerts, 8 of them naming software - but no investigation timeline in any of them.
Coming from Europe, where we have a form for everything, I still find that surprising.
For a quality engineer, that written chronology is a gift. It shows where the two years actually went.
They were not analysing for two years
Here is the uncomfortable part. For most of those two years, nobody was analysing the root cause. They were trying to answer a more basic question: where does the defect appear, and where does it never appear?
Now look at a pattern I know from my own practice.
In 8D, problem description is step D2. Too often it gets written in three lines. Then root cause analysis has nothing to hold on to. Every meeting produces a new theory, and none gets confirmed.
That is not analysis. That is guessing on top of a description that does not hold.
A problem well stated
Charles Kettering ran research at General Motors for 27 years. He is credited with the line: “A problem well stated is a problem half solved.” Kepner and Tregoe turned it into a method: for every dimension of the problem, record where it IS and where it IS NOT.
A complete description is 5W2H, filled to the end - every line with two answers:
What is wrong - one sentence, no explanation, no culprit. Where it appears and where it never does - which machine yes, which no; which shift yes, which no. When it started - and what changed then. Who is affected - and who is not. Why it seems to happen - suspicion, clearly separated from fact. How it shows itself - and how it does not. How many - pieces, percent, complaints.
The difference between the two columns is the only place the root cause can live.
And one honest test tells you the description is finished: you can reproduce the defect on demand. Toyota’s fix took weeks once they passed that test. It took two years to pass it.
My own seven years
I spent more than ten years in manufacturing quality. One problem followed me for seven of them. We kept solving it without ever describing it to the end.
When we finally sat down and wrote the full description, something else appeared. It was not one problem. It was several, overlapping, each with its own cause.
Over the next three months we found the causes and defined actions for each of them separately.
One of my lessons: if you cannot describe a problem to the end, you are probably solving several problems at once.
Not every problem deserves an 8D
One caveat. Everything above applies to 8D - the method for customer complaints and hard problems. Running internal scrap or a small deviation through a full 8D wastes a week of engineering time. That is what lighter methods are for: 4-Step for internal deviations, PDCA for continuous improvement, Just-Do-It for the trivial. In SolveR, 8D, 4-Step, PDCA run on the same knowledge base, so choosing the lighter method never means losing the record.
The right method shortens the path. The wrong one lengthens it.
Where this goes next
I am convinced the amount of data around every problem will grow by orders of magnitude. AI agents will collect it the way people do today - every step written down, rules explicit. Noise will grow faster than signal.
Then filtering becomes the main job: what belongs to the problem, what is noise, which interpretation is wrong, which data needs to be collected again on a larger sample. The last step will always be human.
The root cause is not found by whoever analyses fastest. It is found by whoever can call up the defect on demand.
More on galileon.si
References
- NHTSA, Part 573 Safety Recall Report 26V511, 2026-08-06. 508,354 units, investigation chronology, software remedy.
- 49 CFR § 573.6 - the US requirement for a written investigation chronology.
- EU Safety Gate, motor-vehicle alerts - checked 2026-08-17. 278 alerts in 2026, 8 naming software, no chronology published.
- Charles F. Kettering, attributed - “A problem well stated is a problem half solved”.
- Kepner, Tregoe, The Rational Manager, 1965 - the Is / Is-Not problem specification.