Genealogy is a graph, not a column
Genealogy is the recorded relationship between what came in and what went out. For each unit of production it captures the material lots consumed, the equipment and tooling used, the process parameters in force, the operators and the quality results, all bound to a time interval. Modelled properly it is a directed graph: nodes are lots, serials and equipment; edges are consumption and production events with timestamps and quantities.
It has to be a graph because real production is multi-level. A supplier lot of resin becomes an internal batch of compound, which becomes a run of mouldings, which are assembled with two other components into a serialised finished unit, which is packed into a case that ships to a distributor. Flatten that into a column on the finished-goods record and you can answer one hop; you cannot answer "which finished units contain resin from the supplier lot delivered on the fourteenth", which is the question a recall asks.
Two granularities coexist, and mixing them is normal rather than a design smell. Batch or lot identity applies where units are indistinguishable — a tank of liquid, a hopper of powder, a reel of film — and the quantity is continuous. Serial identity applies where each unit is individually identified, which is what makes per-unit warranty and field history possible. A serialised assembly consumes lots; a lot can also be produced from serialised inputs. Your model needs both node types and a quantity on lot edges, since consumption is partial.
The recall query runs in both directions
Traceability is only useful if it is bidirectional, and the two directions serve different people.
Forward trace, from an input to its outputs, is the containment question. A supplier notifies you that a lot of adhesive was contaminated. You need every batch that consumed that lot, every finished unit derived from those batches, and where each shipped, in hours. That answer defines the recall notice.
Backward trace, from a unit to its inputs, is the investigation question. A customer returns a failed unit. You need the lots that went into it, the equipment that made it, the process settings at the time and the operators involved, so you can decide whether this is one unit or a population. The backward trace usually then triggers a forward trace from whatever it implicates, and that pair of traversals is the whole discipline.
What makes a recall narrow
The commercial value of traceability is entirely in how small the recalled population is, and that is decided long before the incident by two things.
The first is lot granularity. If you define a lot as a day's production, a contaminated input recalls a day. If you sub-lot by shift, by tank charge, or by hour, you recall a fraction of it. Finer lots cost more to administer and are the cheapest recall insurance available.
The second, and the thing candidates miss, is mixing points. Any process that combines material from multiple lots fans out lineage, and downstream of a mixer every output touches every input in the vessel. A blend tank that is topped up while being drawn from does not have clean lot boundaries at all: material from the new charge is in the outflow immediately, and material from the old charge persists for far longer than a volume calculation suggests. Plants assume first-in-first-out through a silo and the physics is frequently plug flow with channelling, or full back-mixing, neither of which is FIFO.
So on a continuous or semi-continuous line the honest answer is a time-based window rather than a lot: everything produced between two timestamps, with a deliberate margin either side sized from how long material actually resides in the system. Being able to say that — that your traceability record is bounded by the process physics and not by your data model — is the mark of someone who has done a real trace.
That is also why the record has to be immutable and time-stamped rather than a mutable current-state row. Corrections happen constantly, an operator mis-scans and fixes it, and the corrected value plus who changed it and when must both survive, because a recall is eventually a legal document.
Statistical process control in engineering terms
SPC treats a manufacturing process as a signal with characterisable noise, and asks whether the latest measurements are consistent with that noise or evidence that something changed. You sample the process, plot the statistic over time on a control chart, and compare it against limits derived from the process's own historical variation, conventionally three standard deviations of the plotted statistic either side of its centre. Which chart depends on what you measure: X-bar and R charts for a statistic computed from small subgroups, an individuals and moving-range chart when you get one measurement per batch and there is no subgroup to average.
The framing that makes this click for a software engineer is that SPC distinguishes two causes. Common cause variation is the process's inherent noise — always present, not worth investigating, and reacting to it makes the output worse, because you are chasing noise with an adjustment that becomes the next deviation. Special cause variation is a change: a new material lot, a worn tool, a different operator, a drifting sensor. The control chart's job is to tell the two apart, and its value is that it does so without waiting for a defect.
Detection is not only about a point outside the limits. Run rules — the Western Electric and Nelson sets are the usual ones — flag patterns that are individually within limits but collectively improbable: eight consecutive points on one side of the centre line, a steady trend, a sudden reduction in spread. Those catch drift and tool wear, which is exactly the class of problem that a threshold alarm cannot see, because every reading is still passing.
There is also a capability question distinct from the control question. Capability indices such as Cp and Cpk compare the process's spread against the specification width, with Cpk also accounting for how far off-centre it runs. Control asks whether the process is stable; capability asks whether a stable process is good enough. Capability is only meaningful once the process is in control, because otherwise there is no single distribution to compute it from.
Control limits are not specification limits
This is the confusion that separates someone who has run a chart from someone who has read about them, and it is worth stating unprompted.
Specification limits come from outside the process: the customer, the drawing, the regulation. They say what is acceptable. Control limits come from inside the process: they are calculated from its own observed variation and say what is normal. There is no arithmetic relationship between them.
The consequences are the two cases people find counter-intuitive. A process can be perfectly in control and still produce scrap, if its natural variation is wider than the specification — the chart is calm, every point is where it should be, and a proportion of output fails inspection. Nothing about the process is drifting; the process is simply not capable, and the fix is engineering, not adjustment. Conversely, a process can be well inside specification and out of control, showing a clear upward trend nowhere near the tolerance. Every part passes and the chart is telling you something changed, which is a warning you get days or weeks before the first reject.
That second case is the whole argument for SPC over a threshold alarm. Putting control limits at the specification values, which is a common and understandable mistake, throws away the early warning and reduces the chart to an inspection report. You find out you have a problem at the moment you start making bad product, which is precisely when it stops being cheap to fix.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).