Planning a recall scope calculation before you need one
A recall is not the time to discover what your records cannot answer. Run the query now, on a lot you chose at random, and find out.
The clock starts before you are ready
Containment typically starts with a phone call from a supplier or a customer naming a lot code and a date range. From that moment you are being measured on two things: how fast you can bound the affected set, and how confident you are in the boundary.
Most plants can eventually produce a list. The cost is in "eventually", and in how much clean production gets contained alongside the bad.
Proving units clean is half the value
The instinct is that a recall query finds affected units. In practice the money is in the other half: proving which units are demonstrably clean so they can keep shipping.
If your record cannot distinguish within a day's production, every unit built that day is contained. On a 400-a-day line where 60 units actually consumed the lot, that is 340 units held for no reason — and it recurs every single time.
What has to be captured beforehand
| Capture | What it lets you bound |
|---|---|
| Lot code at the operation that consumed it | Which units contain the lot — the primary question |
| Quantity consumed per unit | Exposure, when partial consumption matters |
| Which instrument produced each reading | Containment by drifted machine, a separate axis entirely |
| Build timestamp per unit | The containment window, so you can bound rather than guess |
| Dispatch record and customer | Who has to be notified, and how many each |
| Unit state | Which affected units are still in your building and can be pulled today |
The one most often missing is the second: quantity. The one most often missing entirely is the third.
Sizing the query honestly
A forward trace from a lot code should be an indexed lookup. If a vendor demonstrates it on a thousand units, ask what it does on two million, because that is roughly four years of a modest line and the answer changes completely if consumption is stored as a JSON blob.
The second axis: containment by machine
Not every containment starts with a supplier lot. A torque gun drifts, a gauge loses calibration, a fixture wears. The question becomes: which units did this device touch between the last good calibration check and now?
This is not a genealogy query. It needs the instrument recorded against each reading and an index on device and time. Systems that record only scan events cannot answer it at all, which means every containment of that kind falls back to a date range and over-contains.
Run the drill
- 01Take a component lot code from a supplier invoice, at random, from four months ago.
- 02Without warning anyone, ask for the list of finished units that consumed it, the customers they went to, and the build window.
- 03Time it. Write the time down.
- 04Now ask for the list of units from the same period that provably did not consume it.
- 05Repeat with an instrument and a two-hour window.
Whatever that drill costs you in an afternoon, it is a fraction of what the same gap costs during a live containment. Most plants that run it for the first time find that step four is the one nobody can answer.
What the output should look like
A containment report that is actually usable names: the affected unit identities and serials, the customer each shipped to, the build window from first to last, how many are still in your building, and how many are provably clean. A count on its own is not a containment plan.
Written by Dinesh Kumar G, ElectronIx, Coimbatore. If something here is wrong or incomplete for your process, tell us — we would rather fix it.