Two questions, asked under pressure
Traceability answers two questions and they run in opposite directions. Backward: this finished unit is suspect — what went into it, from which supplier lots, made on which equipment, by whom, on what date? Forward: this raw material lot is suspect — which orders consumed it, which finished units contain it, and which customers received those units? Systems get built for the first and are tested by the second, because the second is the one asked during a recall.
There is a third question standing behind both, and it is the one that decides whether anyone believes you. Show me. Not a screen — a record set, with the certificates, the inspection results, the operator sign-offs and the shipping documents attached to it, dated, and reproducible six months later.
You are probably here because
- A customer audit asked you to walk a shipment back and it took days
- A new contract added traceability or marking language you have not met before
- You can trace one step up and one step down, and nothing in between
- The certificates exist, on paper, in a filing cabinet, filed by supplier rather than by lot
The commingling section explains why most systems break. The four capture points are the minimum that closes the loop. The certificates section is the part auditors pull on hardest.
One-up and one-back is not internal traceability
Many regimes require you to know your immediate supplier and your immediate customer for a given lot. That is a real obligation and it is worth confirming which version applies to you — food, pharmaceutical, medical device, aerospace and defense supply chains each state it differently, and the details are worth reading at the source rather than from a summary like this one.
What matters here is that it says nothing about the middle. If your receiving records identify supplier lot 88213 and your shipping records identify sales order 40921, but the lot identity is destroyed the moment the material is poured into a hopper at operation ten, you have satisfied the letter of one-up and one-back and you cannot answer either of the two real questions. The recall becomes a date-range guess, and a date-range guess is always wider than the truth, which is why it costs more.
Identity dies at commingling points
Walk the process and mark every place where two or more inputs merge without a record. Those points are where traceability is actually decided, and there are usually fewer than a dozen in a plant.
A hopper topped off from a partial bag and a new bag. A bin of fasteners refilled by whoever noticed it was low. A tank with heel remaining from the previous batch. A plating line where a rack carries parts from three work orders. A batch oven loaded with whatever is ready. Shared coolant, shared adhesive, shared solder pot. In every one of these, downstream product is a mixture, and if the mixture is not recorded, the honest genealogy of the output is the set of everything that could have been in there.
You have three options at each point, and picking deliberately is the whole exercise. Prevent the mix — run to empty and record the changeover. Record the mix — capture which lots were present and accept a wider but truthful genealogy. Or accept the loss and treat everything downstream of that point as one blended lot for a bounded period, which is defensible if it is a written decision rather than an accident.
Genealogy is a graph, and it is smaller than the vendors imply
The data model that carries this is not complicated. There are lot or serial instances — nodes. There are consumption and production events linking them — edges, each carrying a quantity, a timestamp, a work order, a location and usually an operation. Backward trace is a walk up the edges from a finished instance. Forward trace is the same walk in the other direction. Recursion handles arbitrary depth, and any competent relational database does this with a recursive query over one well-designed table.
That is the whole engine. It is worth saying plainly because the market for traceability software prices this as though it were the hard part, and it is not. The hard parts are capturing the events at all, capturing them accurately when the plant is busy, and attaching the documents.
Two modeling decisions are worth getting right early. Store quantities on the edges, not just the fact of a link, so a partial consumption is representable and a genealogy can be weighted by how much of a suspect lot went where. And model rework explicitly — when a unit comes back, is disassembled, repaired and reissued, that is a new node with edges to both its original identity and any new material consumed. Rework loops are where most genealogies silently break, because the informal version of rework leaves no trace at all.
Granularity is a cost decision, per material
Serial per unit, lot per batch, or date code per shift are three different price points and three different recall widths. Choosing one policy for the whole plant is the common error in both directions: serializing washers, and date-coding a safety-critical casting.
Decide it material by material, against one question — if this component turns out to be bad, how much product do we want to be forced to pull? Serialization narrows the recall to individual units and costs a mark and a scan at every step. Lot control narrows it to a batch and costs a scan at issue. Date coding narrows it to a shift and costs almost nothing. Cheap, high-volume, low-consequence items belong at the loose end. Anything safety-relevant, expensive, regulated, or subject to a customer's own traceability flow-down belongs at the tight end.
| Capture point | What is recorded | What breaks without it |
|---|---|---|
| Receipt | Supplier lot or heat number, our internal lot, quantity, certificate document, inspection disposition | Nothing upstream is knowable; the chain starts broken |
| Issue to order | Which internal lots were consumed by which work order, in what quantity, when | Forward trace becomes a date-range guess across every order in the window |
| Operation completion | Output lot or serial, equipment, operator, inspection result, and the input lots present | Commingling is unrecorded; the mixture becomes invisible |
| Shipment | Which lots or serials went on which shipment to which customer, with the packing document | You know what you made and not where it went, which is the half that matters in a recall |
Four points close the loop. Everything else — equipment history, environmental readings, torque values, statistical process data — is refinement that makes an investigation faster and does not change whether the trace is possible. Build the four first and resist the temptation to gather everything, because a project that tries to capture all of it at once tends to deliver none of it well.
Certificates are the weakest link, and auditors know it
The genealogy graph is usually the healthiest part of a traceability system. The document chain is usually the worst. Certificates of conformance, mill certificates and material test reports arrive as email attachments, as scans of faxes, as paper in an envelope stapled to a packing slip. They get filed on a shared drive, in folders organized by supplier and month, with names that made sense to the person who saved them.
The link between that PDF and the lot in your system is, in most plants, a naming convention and somebody's memory. That is the thread an auditor pulls, because it is the one most likely to come loose. And when a certificate covers several lots, or one lot arrives against two certificates, or the supplier reissues a corrected version, the convention has no way to express it.
The fix is ordinary. Store the document once, immutably. Link it to lots through a real many-to-many relationship, because that is what the reality is. Keep a hash of the file so that a later copy can be proved identical. Record who attached it and when. And index enough of its content — heat number, chemistry, the certificate's own identifier — that the document is findable by what it says rather than only by where it was filed. For scanned paper, that means text extraction with a human confirming the few fields that matter, not a promise that a model read it correctly.
Marking, identifiers and physical survival
Two identifiers per instance is the usual answer: one a human can read aloud over a radio, and one a scanner can read reliably. In consumer and healthcare supply chains, barcode standards carry structured elements for batch or lot and for serial number, so a single symbol conveys both what the item is and which instance it is. In defense work you may meet item unique identification and machine-readable marking requirements, which are stated in contract clauses and marking standards — the shape is a permanent mark, a globally unique identifier, and registration of that identifier. If your contract carries those requirements, read the actual clause text in your award rather than a general description, because the applicability rules and thresholds are specific.
Then there is physics. A label survives the process or it does not, and the process is often unkind: heat, coolant, wash-down, blasting, paint, cold. A lot identity that falls off in the oven creates an unrecorded transformation, and the operator who finds an unlabeled tote will make a reasonable guess, and the reasonable guess becomes a permanent record. Direct part marking — laser, dot peen, etch — costs more and does not come off. Match the marking method to the harshest step the part will see, and test it there before rollout, not on a bench.
The metric: time to answer
Stop measuring traceability by whether the fields are populated. Measure it by a drill. Pick a shipment at random. Give someone the finished serial or lot and ask for the complete backward trace with documents attached. Time it.
A mature system answers in minutes with a document set. A typical system answers in a day or two with a person walking between systems and a filing cabinet. A system that takes a week is not traceability; it is archaeology, and it will not hold up under a real event, because a real event compresses the timeline and adds a customer waiting for an answer.
Run the drill both ways, run it quarterly, and record the time. The trend of that one number tells you more than any completeness report, and it is the number to show a customer's auditor when they ask whether the system works.
Retention, and the part people forget
Retention periods come from your contracts, your industry's rules and your own quality system, and they vary widely — check yours rather than assuming a general number. The part that gets forgotten is that retaining a record means retaining the ability to read it. A database backup you can no longer instantiate is not a record. A file in a format whose only reader was a discontinued application is not a record.
Two habits solve most of it. Export the human-meaningful trace as flat, open, self-describing files on a defined interval — the graph as tables, the documents as ordinary files, in a structure a person could interpret with no software of yours. And test a restore, at least annually, by actually reconstructing one trace from the archive alone. Also note that in regulated electronic-records contexts there are expectations about audit trails, record copies and system validation. Confirm what applies to you before designing around it.
Where you do not need us
If your ERP has a lot control module that was purchased and never turned on, start there. It will be cheaper than anything custom and it will keep working through upgrades.
If you are a job shop running a few dozen orders a year with a traveler and a binder, the binder is a legitimate traceability system. The drill is what proves it — if you can walk a shipment back in an afternoon, you do not have a problem to solve.
If your process has one commingling point and it is a hopper, the highest-value change is a written run-to-empty rule and a line on the changeover form. That is a quality procedure, not software, and it will do more for the trace than any platform.
Where an outside team earns its keep is the awkward middle: a plant with real commingling, documents scattered across a shared drive and a filing cabinet, several systems that each hold part of the answer, and a customer or contract that has raised the bar. That is an integration and data-modeling problem, and it is a matter of months, not years.
The mistakes that repeat
- One granularity policy for every material, which over-serializes the cheap and under-controls the critical
- Unrecorded commingling, turning a genealogy into a date-range guess
- Certificates linked by filename convention rather than by a real relationship
- Rework and returns outside the model, so the repaired unit has no ancestry
- Labels that do not survive the process, followed by an operator's reasonable guess
- Trace built backward only and never tested in the forward direction
- Retention without readability — archives nobody has ever restored
- Buying a platform before walking the process and marking the commingling points
A sequence that works
- Walk the process and mark every commingling point, then decide prevent, record or accept at each one
- Set granularity per material against the recall you are willing to be forced into
- Instrument the four capture points before adding anything else
- Model rework and returns explicitly, with edges to the original identity
- Store documents once, hashed, linked many-to-many to the lots they cover
- Test the marking method at the harshest step the part will see
- Run the drill both directions and record the time to answer
- Export flat archives on an interval, and restore one every year to prove they read
Bottom line
The engine underneath traceability is a graph of lots and the events that link them, and it is one table and a recursive query. The difficulty is entirely in the plant: the places where two lots become one without a record, the certificates connected to the system by nothing more than a filename, the rework that happens at a bench and leaves no trace, and the label that comes off in the oven. Fix those four and a modest system will answer a recall question in minutes. Skip them and an expensive system will still produce a date range and a shrug.
Frequently asked questions
Decide per material, not per plant, against one question: if this component is bad, how much product are you willing to be forced to pull? Serialization narrows a recall to individual units and costs a mark and a scan at every step. Lot control narrows it to a batch for far less effort. Safety-relevant, expensive, regulated or customer-flowed-down items belong at the tight end; commodity hardware usually does not.
Nearly always because of capture rather than the software. Material issued by backflush rather than at the point of use, commingling points with no record, rework performed informally at a bench, and certificates stored on a shared drive with no link to a lot will defeat any system. Walk the process first and find where identity is lost; the module is usually adequate once the events reach it.
Store the file once, keep a hash so a later copy can be proved identical, and link it to lots through a real many-to-many relationship, because one certificate often covers several lots and one lot sometimes has two. Extract the few fields that matter — heat number, certificate identifier, chemistry — and have a person confirm them. Automated extraction is useful for speed and should not be the last word on a record you may have to defend.
Minutes, with the document set attached, for a mature system. A day or two is common and survivable. A week means the answer is being assembled by a person walking between systems, which will not hold up during a real event when a customer is waiting. Measure it with an unannounced drill, in both directions, and track the trend rather than a completeness percentage.
It depends on your contracts, your industry's rules and your own quality system, and the ranges differ enough that the only correct answer is to read yours. The commonly missed half is that retention means retaining the ability to read the record, not just to store it — so export flat, open archives on an interval and restore one each year to prove the archive is still legible.