The underlying serial-validation application uses Node.js, Express, React, and MySQL. This case describes the traceability model across the existing application and subsequent development work; newer reengineering is not presented as a completed production rollout.
The organization already received serial data from manufacturing, but the files were not a traceability system by themselves. They described what had been produced. They did not reliably answer where a particular unit went.
Model the chain, not just the identifier.
A common implementation stores serial numbers in one large table and treats lookup as the product. That works until the business needs to explain the movement of a specific unit.
We separated the chain into distinct relationships: serial to manufactured carton, carton to warehouse handling, carton to dispatched order, and serial to public validation status. Each relationship has its own timing and failure modes.
Traceability is a sequence of evidence. The serial number is the key that lets the evidence be assembled.
Do not let public validation expose the operating system.
The customer-facing question was intentionally narrow: is this serial recognized and valid? The internal question was much richer: when was it received, which carton contained it, whether that carton was dispatched, and which order carried it.
Keeping those surfaces separate protects operational detail and makes the public response easier to reason about. A validation page should reveal only what the customer needs, while internal users retain the chain required for investigation.
The architecture emphasized three boundaries
- Factory data entered through a controlled intake process before becoming trusted inventory evidence.
- Warehouse actions linked cartons to fulfillment records without rewriting the original manufacturing evidence.
- Public validation read a purpose-limited status rather than exposing operational tables or order data.
Traceability must tolerate incomplete history.
Real operations do not produce every event in perfect order. A carton can arrive before its file, a file can be resent, or an investigation can begin while an order is still open. The system therefore treats “not linked yet” differently from “invalid.”
That distinction prevents premature conclusions and gives operations a clear place to resolve gaps. It also makes future reporting possible: the business can measure missing links without corrupting the evidence it already has.
Investigate the missing link without changing the evidence
Consider a unit that appears in a manufacturing file while its carton has not yet been linked to a dispatched order. That is a gap in the chain, not enough evidence to declare the unit invalid. An investigation should be able to identify which relationship is missing before anyone changes the underlying record.
Separating the stages gives that investigation a useful shape. The team can ask whether the original file was received, whether the carton was recognized during warehouse handling, and whether the dispatch relationship is present. Those are different questions with different sources of evidence.
The same separation also explains why the public page should remain narrow. A customer checking a serial does not need access to warehouse events, customer orders, or internal exception handling. The external answer and the internal investigation can serve different purposes while referring to the same identifier.
This example describes the reasoning behind the traceability model, not a claim that every later development change is already live. Preserving the distinction between existing application behavior and subsequent reengineering keeps the account accurate and makes the design lesson reusable.
Reusable pattern: preserve each source event, model the relationships explicitly, and publish only the smallest safe interpretation to external users.