Factories forget what they already solved
AI root cause analysis in manufacturing pays off only when the closed case stays findable. Here is what decides it.

What AI root cause analysis in manufacturing actually changes
AI root cause analysis in manufacturing is the use of a model to help an engineer move from a defect to its cause, and to keep the whole case in one record. It does not pick the cause. It shortens the two slowest parts of the work, the description of the problem and the search of what has already been tried, and it decides whether the finished case can be used again.
That last part is the one nobody buys on. It is also the only one that compounds.
A fleet learns. A plant files.
Two weeks ago supervised self-driving was approved for Slovenian roads. It was the sixth market in the European Union to clear it.
That system did not get there by being renamed, or by one model being cleverer than the last. It got there because the fleet reports back. Every kilometre driven becomes something the next version can read.
Now stand in a plant and watch the same defect get solved for the third time.
The engineering is not worse. The people are not worse. The difference is what each side is allowed to keep.
A driving system writes its experience into a form the next version can use. Quality writes its experience into a report. The report is filed, signed and stored. The next engineer who hits the same wall usually does not know it exists, or cannot find it. The learning stops with the person who did the work.
The report was built to be signed
Open any 8D archive and the pattern is the same. The reports are complete. They are also unreadable as data.
The problem statement is prose. The evidence sits in an attachment. The action is a sentence. The file name is a number and a date. Nothing in it answers the question a new engineer actually asks, which is never “show me report 2024-118” but always “has anything like this happened before on this machine”.
That is not a failure of discipline. The 8D form was designed to prove to a customer that a problem was handled. It was never designed to be read by the next case.
Here is the same work seen twice.
| A filed report | A reusable case record | |
|---|---|---|
| Written for | the customer and the signature | the next engineer |
| Problem statement | prose, often under three lines | structured, with what the problem is and what it is not |
| Evidence | attachments beside the file | attached to the cause it rules in or out |
| Found by | report number and date | symptom, part, machine, process step |
| Verification | a date field, often empty | a closed loop, effective or not |
| Value after closure | proof that it was handled | input to the next case |
The table is the whole argument. Both rows describe the same hours of work by the same people. One of them can be used again.
What we measured
Between January and March 2026 we ran ten customer claims through this way of working with Slovenian manufacturers, measured at eight of them. Across that sample, everything produced during the solve stayed attached to the case and stayed searchable afterwards: the problem definition, the ruled-out causes, the evidence and the verification.
Source: pilot sample, 10 claims, Slovenian manufacturers, January to March 2026, measured at 8 manufacturers.
That is a small sample and we say so. It is enough to show the mechanism, not enough to promise a number to a plant we have never seen.
The laptop
Before any of this I sat in front of a laptop that held more than 20 years of one engineer’s work. He was leaving in a week.
Every solved problem and every trial that failed sat in files only he could read. Folder names that meant something to him. Spreadsheets with no header row. Photographs with camera file names.
Nobody else in that building could have opened them and known what to do next. The company had not lost the knowledge yet. It had never held it.
A tool that gets a plant to the cause faster and leaves the same pile behind has moved the problem, not solved it.
What to check on Monday
Pull the last case you closed. Then run three checks, in this order.
One. Ask someone who did not work on it to find it, starting from the symptom and nothing else. Give them five minutes.
Two. Read D2, the problem description. If it is shorter than three lines, the case was closed on a guess that happened to work.
Three. Find the verification date. If the field is empty and the report is closed, the loop was never shut.
If the case fails all three, the next occurrence of that defect will cost the same as the first one. That is the whole cost of a record that cannot be read.
More on galileon.si
References
- Slovenia clears Tesla’s FSD driver assistance, reported 7 September 2026. AOL, republishing Reuters
- Tesla FSD (Supervised) approved in Slovenia, its sixth EU market, 7 September 2026. We Talk Tesla