We Found a Bad Part. Which Other Parts Should We Check?

Finding a defect creates an immediate question: how far does the problem go?

Was it one part? Everything made since the last inspection? Every part produced with the same material lot? Has any of it already shipped?

A quality team can have inspection records, production reports, and inventory data and still struggle to answer those questions quickly. The information exists, but it sits in different places. Someone has to connect it while production and shipping wait for a decision.

Consider a simple example. An inspection finds a dimension out of tolerance at 10:20 a.m. The previous sample passed at 9 a.m.

Holding everything produced between those inspections might be a sensible first containment step. But the team still needs to investigate. Did a tool change? Was there a machine adjustment? Did the material lot change? Are the suspect parts still at the station, in finished goods, or on a truck?

Those details determine the next action.

A useful quality app should let the team follow the part’s history. Select a serial number or batch and see where it was made, when it passed through each operation, which material it used, and what inspections were recorded. Then look for other parts that share the relevant conditions.

There is a practical distinction here: a part may be potentially affected without being confirmed defective. The system should make that clear. Missing records should also be visible. Nobody should mistake an incomplete history for evidence that a part is good.

The underlying idea is well established. NIST’s work on manufacturing traceability describes ways to organize, link, and query product history across separate systems. The value comes from being able to follow those connections when a question arises.

AI can help the team search that history. Someone could ask, “Which batches used this material lot?” or “What changed before the failed inspection?” The answer should show the records behind it, along with any gaps. A shared machine or material lot gives the team something to investigate; it does not establish the root cause by itself.

You can start small. Choose one recurring defect and connect the records needed to investigate it. A basic app that links an inspection failure to a batch, production window, and inventory location can already make the investigation easier to manage.

This is a good example of why we built SubAssembly.ai around manufacturing context. A quality app needs to understand the relationships between parts, machines, materials, operations, and inspections. Those relationships are what make the information useful.

When a bad part turns up, the team needs a defensible answer to a very practical question: what else do we need to check?