A customer returns three failed units built in different weeks. You have one shift to say what else is affected. How do you bound it?

Bounding and diagnosing are different jobs on different clocks

The instinct is to work out why the units failed. Resist it for now, because that is not what the shift is for. Two questions are in play and they have different deadlines. What else might be affected has to be answered today, on incomplete evidence, because until it is answered suspect product keeps shipping. Why it happened can take three weeks, and it will.

That separation drives the whole method. A containment boundary is not a conclusion, it is a hypothesis-set: the population you cannot yet rule out. It is expected to be too wide at the start and to shrink as evidence arrives. A root cause is the opposite, a claim you should only make when you can support it. Candidates who merge the two end up waiting for certainty before containing anything, which is the expensive mistake.

Your three units are a biased sample

Before touching the data, be clear about what the three returns tell you. They are units that failed, were noticed, and were sent back, by customers who bothered. Every stage of that filters. Failures that have not manifested yet are absent, as are failures in units still on a shelf, and failures that a customer worked around or discarded.

Two consequences follow. First, three is a floor and not an estimate — you cannot infer a rate from it, so anyone asking "so it's only three units?" needs the reasoning above rather than reassurance. Second, and more usefully for bounding, the absence of returns from a period is not evidence that the period is clean. Field failures arrive with a lag measured in weeks or months, so recent production has had less opportunity to report and will look innocent regardless of whether it is.

Spread across different weeks is itself informative. It rules out a single shift or a single equipment fault confined to one day, and it points towards something that recurs: a supplier lot used intermittently, a tool that is one of several in rotation, a maintenance or calibration cycle, a specific process condition that happens sometimes.

Intersect backwards, then trace forwards from what is left

The mechanical part is a backward trace on each of the three units, pulling the full lineage: every consumed lot at every level, the equipment and tooling, the process parameters in force, the operators, the calibration state of the gauges that measured them, and the software or recipe version running at the time. Then intersect the three sets. What all three share is your candidate factor list.

Take a plausible outcome. The intersection leaves an adhesive lot present in all three, a single mould used in all three, and one gauge whose calibration interval covered all three build dates. Now forward-trace from each candidate independently, because that is what converts a factor into a population.

Shared factor	Forward-trace population	Can it be excluded today
Adhesive lot	12,400 units across five weeks	No, supplier certificate is clean but that is not dispositive
Mould	61,000 units across four months	Not without cavity-level data
Gauge calibration interval	3,100 units	Yes, if the gauge passed its subsequent verification

The boundary you announce is the union of everything you have not excluded, which here is roughly the mould population, not the adhesive population, and certainly not three units. If a factor can be excluded on a record you genuinely trust — the gauge's subsequent as-found calibration result, an unbroken measurement record for a parameter — then exclude it and say what the exclusion rests on. Exclusion by plausibility is not exclusion.

The granularity you never recorded is the boundary you cannot narrow

That table contains the point of the exercise. The difference between 12,400 units and 61,000 is not analysis, it is a field. A multi-cavity mould produces parts that are physically distinguishable in their properties, and if only the mould was recorded rather than which cavity produced each part, then a defect confined to one cavity implicates every part the mould ever made. The trace stops at the resolution of the record, and no amount of urgency or cleverness in the query recovers information that was never captured.

This is the general law of the situation and it is worth stating plainly, because it is the part of traceability design that gets deferred as an optimisation. Every identifier you decline to record — cavity, spindle, head, nozzle, lane, fixture position, sub-lot within a delivery — is a factor you will later be unable to narrow to, at a moment when narrowing is worth a great deal of money. The cost of recording it is a column and some barcode discipline. The cost of not recording it is measured in units you recall unnecessarily, and you pay it once for every escape.

Related gaps to expect, because they are near-universal and you should go looking for them rather than discovering them at hour six. A period when the MES was unavailable and the record was keyed in manually afterwards, which is thinner and less reliable than the surrounding data. Reworked units, which frequently re-enter the flow having lost the link to their original lineage, so a rework population is invisible to both traces and has to be pulled separately. A subcontracted or externally processed operation, where your record often has a delivery note and nothing below it, meaning the trace has no resolution at all through that step. And shipping records kept at case or pallet level rather than unit level, which lets you name a distributor but not a customer, and therefore sets the granularity of the notice you can issue.

Hold what you still control while the query runs

The trace takes hours. Containment of the material you physically hold takes minutes, is reversible, and costs almost nothing, so it should be started in the first hour in parallel rather than waiting for a boundary.

That means placing a hold on finished stock in your own warehouses, on work in progress that has not yet completed, on inbound and in-transit material from the implicated supplier lot, and on inventory at distributors where the commercial relationship allows it. Every unit stopped before it reaches an end customer is a unit removed from the eventual notice, and the cost of holding it for a day and releasing it is a fraction of the cost of retrieving it later.

The same logic applies to the process. If the suspected factor is still in use, stopping its use is a reversible decision made under uncertainty, and continuing to use it is a decision too, just one nobody records as such.

The asymmetry that sets the default

The final judgement is where an experienced answer differs, and it comes down to which error is recoverable.

Include too much and you scrap or retrieve product that was fine. That costs a quantifiable amount of money, once, and it is over.

Include too little and you issue a notice, then find further failures outside your stated boundary and have to issue a second one. The second notice costs far more than the first, and not in units. It tells every customer, auditor and regulator reading it that your first answer was wrong, which converts a product problem into a credibility problem about your entire traceability system. Every subsequent assertion you make about any population is then discounted.

So the default is wide, and the burden of proof sits on narrowing rather than on widening. State the boundary, state which factors it rests on, state explicitly what data you do not have and what that prevents you from excluding, and commit to a date for the narrower answer. An honest wide boundary with its uncertainty written down is a stronger position than a confident narrow one you cannot defend by the end of the week.