Root cause analysis in quality management: process data analytics and agentic AI
Quality engineers spend much of their time gathering data on a new quality case, finding similar past cases and forming hypotheses. We build a system that combines process data analytics with research across documented experience – into an evidence-ranked, substantiated hypothesis list.
The situation
Every new quality case starts the same search: which lots are affected, what was different on the line, has this happened before? The answers are scattered – across SAP QM, the MES, inspection records and the 8D reports of past cases.
Gathering them costs days during which defective parts may keep being produced. And the experience captured in past cases goes largely unused, because nobody searches it systematically.
Typical data basis
Quality notifications from SAP QM and the lines' defect logs. MES and process data: machine and tool assignment, process parameters per lot or part, shift and batch mapping. Inspection records with measured values, gauge and inspector assignment. Traceability data linking defective part and process step.
In addition, 8D reports, lessons learned and corrective action records from past cases – including the confirmed root cause in each.
Why such initiatives fail
Jargon instead of standard language. Quality notifications are full of free text, abbreviations and shift-floor jargon – identical defects often look completely different in writing.
Scattered data, missing context. The relevant information sits in several systems without a shared data model. The crux is reliably mapping defective parts to the right process step.
Correlation is not causation. Shift, batch or ambient conditions quickly produce apparent relationships. The system has to detect patterns without prematurely inferring causality from them.
History with gaps. For past cases it is rarely cleanly documented what the actual cause was – and which corrective action ultimately worked.
No recommendation without evidence. Quality engineers need traceable justifications and sources. A plausible AI answer alone is not enough.
Approach
Process data first. For each case the system narrows down the affected parts via traceability and compares their process data against a matched reference set of good parts. Control charts and distribution comparisons show which process parameters deviated from their usual behaviour in the period in question. An attribution method on a defect prediction model scores which quantities explain the defect most strongly; rule and pattern mining across the process chain finds combinations such as a particular machine paired with a particular batch. To keep correlation from prematurely becoming cause, shift, batch, tool life and ambient conditions enter the assessment as control variables; where the data supports it, a causal graph orders the candidates by their position in the process chain. Process mining reveals whether affected parts took a deviating route through production.
Experience added. In parallel, a semantic similarity search finds comparable past cases, and retrieval across 8D reports, lessons learned and the quality records surfaces the documented knowledge on the defect pattern. Free text from the notifications is normalised via a maintained synonym and abbreviation register.
Agents orchestrate, one schema ranks. A multi-agent setup orchestrates case intake, statistical analysis, past-case search, document research and consolidation. Hypotheses are ranked by a disclosed schema: strength of statistical evidence, agreement with confirmed past cases, plausibility within the process chain. Every hypothesis names the analyses and cases it rests on – and states what is still missing for its confirmation.
Closing the loop. When the engineer closes a case, the confirmed cause is written back in structured form. This feedback improves ranking and case base with every closed case – which is why the step is part of the delivery, not optional. Assessment and decision stay with the quality engineer; the system delivers hypotheses with evidence, not a diagnosis.
What you get
Faster from defect to cause: data analysis, case comparison and document research run automatically – engineers start exactly where their expertise is needed.
Past cases become usable knowledge: scattered experience and earlier solutions flow systematically into new defect analyses. Expertise where it counts: prioritisation by frequency, cost impact, safety relevance and trend directs engineering capacity to the expensive and critical cases.
Measurable through the time from opening a case to the confirmed cause, the share of cases where the later confirmed cause was among the system's top three hypotheses, and the number of recurring defect patterns. The second value can be checked retrospectively on closed past cases before the project – a good feasibility test.
Where our experience comes from
We have analysed sensor and process data from manufacturing for years – and we make model decisions explainable, so that anomalies turn into substantiated causes.
Last updated: 13 August 2026
