The Root Cause Is the Supplier's Job

“Just a moment, that is not the topic what we need.”

A German quality director said that a few minutes into my presentation. I was showing how we take a problem down to its root cause. He let me get to the part about methods, then stopped me. He had to do it more than once before I understood what he actually buys.

Last week I promised to come back with what he taught me. This is the long version.

Two jobs, opposite directions

He buys parts. When one of them fails, the cause sits at the supplier. His job is to prove the fault well enough that the supplier accepts it and pays for it. Until that proof is on paper, nothing moves. He does not get his costs back on an opinion.

The supplier’s job starts where his ends. Once the evidence is accepted, the supplier owes a root cause, a corrective action and a report, usually an 8D on the customer’s clock. Five Signs Your 8D Report Is Closed But Not Fixed covers that side.

Two people hold the same broken part. One owes an explanation. The other owes proof. The proof comes first, and it runs in the opposite direction. The buyer does not ask why. He asks what, exactly, and whether he can show it.

I had spent my first minutes selling the explanation side to a man who lives on the proof side.

What the standard asks of the buyer

ISO 9001:2015 puts the proof on the buyer as a requirement. Clause 8.4.2 says the organisation shall ensure that externally provided products do not adversely affect its ability to deliver conforming products, and it has to define the verification that makes that true. Responsibility for a bought part does not leave with the purchase order.

So the evidence he was describing is what the standard expects of any buyer. The supplier’s 8D is the other half of the same clause, seen from the other side of the contract.

The order of a proof

There is a written path for it. VDI 3822, the German engineers’ guideline on damage analysis, was reissued in December 2023 and replaced the older Blatt 1. It sets the sequence: a full description of the damage and a record of the condition as received, then hypotheses about how it happened, then the choice of methods that can test those hypotheses, then the investigation, then a report that carries the pictures and the measurements.

The order matters more than any single step. A hypothesis written before the evidence is recorded will shape what gets recorded.

Günter Lange and Michael Pohl, in the standard German handbook on the systematic assessment of technical failures, compare the work to medicine: history, diagnosis, treatment, in that order. Their first rule for a fracture surface is blunt. Never touch it. Their second is about cleaning. Sulfur found on a fracture surface under the electron microscope can come from the pickling acid used to clean the part. The analysis then points at a cause that was never there. A cleaned part does not only lose evidence. It can produce false evidence.

The same handbook gives the reason non-destructive tests come before destructive ones. A metallographic section can be cut from the head of a tensile specimen. A tensile specimen cannot be made from a section. Every cut closes a door.

Cleaning belongs late in that sequence, after the condition as received is documented and after the non-destructive work is done. Clean first and the proof is gone before anyone measured it.

One seal, one proof

He showed me one of his own cases. I am leaving out everything that would identify the company. The method is what matters.

A shaft seal on a new machine started to sweat oil after roughly 1,000 operating hours. The customer complained. The returned seal went under a microscope first, as it arrived. The sealing lip was black.

His failure catalogue for seals matched that picture to one cause. Forces at the lip too high, friction heat, burning.

Then the shaft. A roughness measurement on the running surface showed a normal surface and no deep grooves. That cleared the shaft. Whatever made the lip burn, it was not the surface it ran on.

Then the oil. The dipstick range put the oil level low in the area behind the seal. Little oil near the lip means no lubricating film on the lip.

Hypothesis: an oil-laden aerosol reaching the lip, made worse by a higher blow-by rate. A pressure measurement on the assembly confirmed it.

The report followed the same order as the investigation. The problem, the steps with photographs, the roughness data, the oil-level context, the conclusion. A supplier reading it cannot claim the lip was fine, because the picture of the lip is in the report. He cannot blame the shaft, because the roughness trace sits next to it.

That is what proof looks like when it is built in the right order. Nothing in it is an opinion.

The part nobody writes down

Everything above is obvious to him. He has spent more than 20 years in the job and keeps his own knowledge base, sorted by domain: seals, bearings, hydraulics, technical cleaning. He knows which folder holds which answer.

It is not obvious to the engineers he has now. Most of them are young. When one of them gets a part back, the sequence above is exactly what is missing. What to look at first, what to measure, what not to touch.

His team already uses a general AI assistant. He used it himself in that case, to explain to his engineers why a cassette seal without an oil film on the lip will let aerosol through. The answer was correct. It was also useless to anyone who did not already know to ask that question.

That is the gap. A general assistant answers well when you know the question. A search or a context layer finds what already exists, if you know what to look for. A form tool fills in the report once the work is done. A custom automation copies one company’s process and stops there. None of them tell a junior engineer what the next step is, and none of them produce a report the other side has to accept.

Which leaves a question every plant answers for itself. What is still our domain, and what is better left to people who build it every day, on far more cases than any one plant will ever see?

Three things, whatever the job is called

Since spring I have presented to more than 40 companies in Slovenia and more than 5 abroad. The call above changed which method sits on top. It did not touch what sits underneath. Every one of those companies, buyer or supplier, asked for the same three things.

1. A method that walks the engineer through the case, so nobody guesses the next step.
2. A knowledge base that gets smarter with every solved case, so the next engineer starts ahead.
3. A record an auditor or a customer can follow end to end, 100 percent traceable.

Problem solving needs all three. Part investigation needs all three. The proof in the seal case above is nothing else: a sequence, the knowledge of which sequence, and a record the supplier could not argue with.

How we decide what to build

That is also how we decide what goes into SolveR. The three things are fixed. The method on top of them changes with the job: 8D for a customer complaint, a shorter method for an internal deviation, and now the proving side of a delivered part, because the buyers we met this year asked for it.

Process audits look like the one after that to me. Same guided sequence, same knowledge behind it, same audit trail.

We are not building it yet. It starts when two customers ask for it and are willing to pay, and before that it is not even a plan. That rule is what keeps a small team from building features nobody ordered.

What to do with the next claim

Three things a buyer can do this week, without any software.

• Photograph and describe the part as it arrived, before anyone wipes it. The as-received record is the one step that cannot be repeated.
• Write the hypothesis only after that record exists, and name the measurement that would kill it.
• Read the finished report the way the supplier will read it. Every claim needs a picture or a number beside it.

Where else in your work would those three things change something? That is the question I am asking this week, and every answer changes the list.

More on galileon.si

• Five Signs Your 8D Report Is Closed But Not Fixed - the supplier’s half of the same claim.
• Two Years to Describe One Defect - what a description has to contain before anyone can search against it.
• Poka-Yoke for Knowledge - why the knowledge base has to fill itself.
• How SolveR works
• Data handling

References

• VDI 3822:2023-12, Schadensanalyse - Grundlagen und Durchführung einer Schadensanalyse, Verein Deutscher Ingenieure. Product page at Austrian Standards, accessed 14. 9. 2026 - edition date, scope, and that it replaces VDI 3822 Blatt 1 (2004-03) and VDI 3822 (2011-11).
• Polymer Service Merseburg, “Schadensanalyse VDI Richtlinie 3822”, accessed 14. 9. 2026 - the sequence: damage description and as-received record, hypotheses, choice of methods, investigation, report with pictures and measurements.
• Günter Lange, Michael Pohl (eds.), Systematische Beurteilung technischer Schadensfälle, 6th edition, Wiley-VCH, Weinheim 2014, ISBN 978-3-527-32530-6. Publisher page and sample chapter 1, accessed 14. 9. 2026 - history, diagnosis, treatment; never touch a fracture surface; sulfur from the cleaning acid; a section from a tensile specimen, never the reverse.
• ISO 9001:2015, Quality management systems - Requirements, clause 8.4, Control of externally provided processes, products and services. Accessible summaries: Auditor Training Online and ISO 9001 Checklist, both accessed 14. 9. 2026.