Finding the root cause of rejects: quality analysis with production data

Intercepting rejects is the start, not the goal

More and more manufacturers have their quality control well organised: an inspector at the line, a vision system, an in-line measurement. Bad products are intercepted before they leave the factory, and that is a win. But if all you do is intercept, you keep paying: the material has been used, the machine time has been spent and the capacity is gone. The reject bin gets filled neatly, week after week.

So the real question is not whether a product is good or bad. The real question is why it went wrong. That is the domain of root cause analysis: from the symptom (a reject) back to the cause (a raw material, a setting, a worn part), so you can remove it.

Why finding the cause usually never happens

Ask a production team why rejects occur and you will rarely get an answer based on data. Not because the will is missing, but because the information is scattered:

• Inspection results stay on the screen at the line or in a separate quality log.
• Process data such as temperatures, pressures and cycle times sits in the PLC and disappears there again.
• Batch and order information lives in the ERP, on a delivery note or on paper.

By the time someone has time to investigate a reject spike, the trail is cold. Which raw material batch was running? What were the settings? Which shift was on? Nobody remembers exactly. So the team falls back on experience and gut feeling, and on fighting symptoms: checking more often, tightening limits, extra samples. The rejects themselves do not change.

The key: inspection results next to your production data

Root cause analysis only becomes practical when every inspection result gets context. Every check produces a record: the verdict, the defect class and the timestamp, linked to machine, order and batch. Put those records in the same environment as your machine data and process conditions, and the question "why did we have so many rejects this week?" turns from detective work into a filter.

That is exactly what MeshOS does: it brings inspection results, machine data, downtime and batch information together in one data layer. The source of the inspection data does not matter. It can be a vision system that judges every product, as in AI visual inspection, an in-line measurement or a digital quality log.

At stroopwafel bakery Daelmans, for example, a 3D laser camera measures every stroopwafel on the line: diameter, thickness and shape. Deviations are visible while the batch is still running, and all quality data is logged per line and per batch. A dataset like that, every product measured and enriched with context, is exactly the foundation root cause analysis needs.

Three patterns that give the cause away

Once inspection results and production data sit side by side, the same three patterns keep showing up in practice.

1. Rejects spike after a change

Do rejects rise after a raw material batch, changeover or recipe change? Because every result is linked to order and batch, the connection becomes visible immediately. Think of seal defects that start with a new batch of packaging film, or dimensional deviations after a changeover. Without data, this is the kind of connection that takes weeks to notice; with data, you see it the same day.

2. One machine, mold or shift deviates

The same check, a different outcome: compare defect classes per machine, line, mold or shift and see where the difference arises. One mold cavity causing most of the shape defects. One line structurally showing more contamination. A shift running with different settings than the rest. The difference is the clue: what is that one machine, mold or crew doing differently?

3. Quality drifts with the process

Put defects next to temperature, speed, cycle time or wear and see which process conditions precede rejects. That makes creeping drift visible before limits are exceeded: rejects slowly rising as tooling wears, or a quality dip that keeps coinciding with the same process condition. It makes intervention data-driven: maintenance when the data calls for it, instead of when the calendar does.

From pattern to structurally fewer rejects

A pattern is not a cause yet. The way of working that succeeds in practice is always the same:

1. Spot the pattern in the data: where and when do rejects deviate from normal?
2. Form a hypothesis with the team: operators and technologists know the process and often see a likely explanation in the pattern right away.
3. Make one targeted change: adjust a single thing, for example the setting, the raw material or the maintenance moment.
4. Verify the effect in the same data: do rejects really go down, or was it coincidence?

The data points the way, but interpreting it remains human work. What changes is that discussions are no longer about opinions but about measurements, and that the effect of every intervention is visible in black and white. Quality becomes a process signal you act on daily, just like availability and performance in a live OEE dashboard.

What do you need for this?

Root cause analysis does not require a year-long data warehouse project. At its core you need four things:

• Inspection or measurement that records every result: a vision system, an in-line measurement or a digital quality log, as long as the verdict is logged instead of only displayed.
• Machine data and process conditions: read from existing PLCs and sensors, via an edge computer next to the line.
• A link to order and batch: so every result has context and can be traced back to what was running at the time.
• One environment that brings it together: so quality, process data and batch information sit side by side instead of in three systems.

You can start small: one line, one check that matters now, and build from there. You can find more examples of what that looks like in practice in our client cases.

Frequently asked questions about root cause analysis

What is root cause analysis?

Root cause analysis is tracing a problem, such as rejects or a quality deviation, back to its underlying cause, so you can remove it instead of fighting the symptom. In manufacturing that means: from a rejected product back to the raw material, setting, machine or process condition that caused the defect.

Do I need a vision system for this?

No. Any source that records quality results can be the starting point: a 3D measurement, a checkweigher, a digital quality log kept by operators. That said, the more automated the inspection, the denser the dataset. A vision system that judges every product delivers hundreds of data points per batch where a sample delivers a handful.

What data do I need as a minimum?

The minimum is an inspection result with a timestamp, linked to machine, order or batch. That alone reveals spikes after changes and differences between machines and shifts. Add process conditions, such as temperatures, speeds and cycle times, and drift becomes visible too, letting you trace causes further into the process.

Does the system find the cause automatically?

No, and be wary of vendors who promise that. The data makes connections visible that would otherwise stay hidden, but interpreting those connections and choosing the right intervention remains work for people who know the process. The difference is that they no longer have to guess.

Conclusion: don't stop at intercepting rejects

Quality control that only intercepts keeps the reject bin filled. The real gain is one step further: putting inspection results next to machine data, process conditions and batch information, spotting patterns and removing causes. Root cause analysis becomes a matter of laying data side by side instead of guessing, and rejects go down structurally.

Meshnex builds the chain that makes this possible, from inspection on the line to the data layer that brings everything together. Take a look at our AI visual inspection solution, read how MeshOS brings your production data together or contact us to discuss what is possible in your factory.