Factory traceability: why a scan is only the start of the product record

What the NIST draft contributes

NIST IR 8536’s second public draft, released on 2 July, presents a conceptual structure for manufacturing traceability across different supply-chain environments. It discusses traceability records, links between them and the connection between digital information and physical items.

The draft also identifies limits: privacy risks, differences in data models, identity and access challenges, and dependence on the integrity of contributors and repositories. Its architecture does not remove those problems automatically. They remain implementation responsibilities.

This is a draft framework, not a new certification requirement or proof that a particular commercial platform is trustworthy. Its value is in organising the questions a manufacturer should ask before sharing product evidence with a customer or relying on evidence from a supplier.

For example, a record may be protected against later alteration while still containing an incorrect observation at the point of entry. The company needs both reliable record handling and a credible process for generating the information. Treating either one as sufficient would leave a gap in the assurance offered to the buyer.

Follow the product through a transformation

Consider an illustrative machining business receiving a bar-material lot, cutting it into blanks and producing components across two shifts. Some parts are reworked and a portion is sent to an outside processor. A customer later asks which delivered components came from the original lot.

A list of dispatch scans answers only the final stage. The company also needs the relationships created during cutting, production, rework and subcontracting. If the outside processor returns parts under a different batch identifier, the link must survive that change.

The right level of detail depends on the product and the agreed requirement. Some applications need individual serial numbers, while others can use controlled lot records. Collecting the most detailed possible data without a clear purpose can create unnecessary cost and still fail to answer the customer’s actual question.

A useful design exercise starts with the question the business must answer, then works backwards to the events and records needed. This gives the traceability project a practical boundary and helps prevent software capability from defining the requirement by default.

Give events a shared meaning

GS1’s Global Traceability Standard distinguishes critical tracking events from the data elements describing them. It also calls for recording relationships between inputs and outputs when traceable objects are transformed. These concepts help explain why the same identifier can appear in several systems without those systems sharing a coherent history.

A receiving event, for example, needs a meaning understood by both parties. Does it mean the material reached the gate, passed inspection or became available for production? If systems use the same status word for different events, an automated exchange can transmit ambiguity very efficiently.

GS1’s EPCIS standard provides a common language for event information, including what happened, when, where and why. Version 2.0 also supports sensor information and certification details. These capabilities can help information exchange, but they do not determine whether a factory’s recorded event is accurate or whether its claim is appropriate.

The practical priority is therefore to agree meanings before building interfaces. A modest set of consistently defined events can be more useful than a much larger data feed that each organisation interprets differently.

A digital thread connects engineering and production evidence

The October 2024 roadmap published through NIST examines digital-thread capabilities across four sectors: aerospace and defence, energy, agriculture and food, and pharmaceutical, biopharmaceutical and medical devices. It maps supply-chain risks against proposed capabilities, rather than measuring a universal financial return from installation.

The roadmap’s lifecycle perspective connects design information with production, quality and service records. That is relevant when a customer asks not only where a part came from but which specification and process revision were used to make it.

An illustrative factory might preserve a material lot perfectly while losing the connection to a revised inspection plan. Its origin record would be intact, but the evidence needed to explain conformity with the order could remain incomplete. Traceability requirements should therefore be discussed with engineering and quality, not assigned solely to warehouse scanning.

The business case should identify the decisions those connections support. Faster containment of a quality issue, less manual reconstruction of records or more reliable customer evidence are different benefits with different measures. A project should test the relevant one instead of promising that every digital connection will improve productivity.

Chain of custody does not prove every claim

ISO 22095:2020 provides a framework and terminology for chain-of-custody models. Its public scope explicitly cautions that the framework alone does not establish the characteristics of a material or product. That distinction is useful whenever a buyer asks for evidence of origin, recycled content or another attribute.

A manufacturer needs to define the claim and the evidence that supports it. Knowing which organisation handled a component does not necessarily establish its material properties. Similarly, a test result must be connected to the relevant item or lot and interpreted within the test’s actual scope.

The sales promise should match that evidence. A supplier can describe the traceability it provides without implying that a record system certifies every environmental, safety or quality attribute. Clear limits make the information more useful to a customer assessing its own requirements.

This is particularly relevant when several certificates travel with a shipment. The question is how each document relates to the product, not how many documents have been attached to the invoice.

Share enough information, with controlled access

Traceability across organisations raises commercial questions about who can see supplier relationships, process details and customer destinations. A supplier may be willing to prove a particular claim without disclosing its entire production history to every trading partner.

The information agreement should therefore define the purpose of sharing, authorised users, retention and correction responsibilities. The technical design can then support those boundaries. Starting with unrestricted access and trying to remove sensitive information later can make both the architecture and the commercial relationship harder to manage.

A practical pilot might allow a customer to obtain the evidence needed for a specific lot while keeping unrelated orders outside the shared view. The pilot should test the permission boundary as well as the successful query. A demonstration that works only when everyone has administrator access has not resolved the real operating problem.

The same attention is needed when an organisation leaves a platform or changes suppliers. The business should understand which records remain accessible and how it will support products already delivered. A traceability claim may need to outlast the commercial relationship that originally generated the data.

Test the difficult cases before scaling

A strong pilot includes a split lot, a merged batch, a reworked item, a missing record and a corrected entry. These cases reveal whether the proposed system preserves meaning when production departs from the simplest route.

Measure the time needed to answer an agreed query and the amount of manual interpretation required. Also check whether the answer can be explained by someone outside the implementation team. A record that only its software developer can interpret is a weak basis for routine customer assurance.

NIST’s draft gives manufacturers a structure for this work, while GS1 and ISO clarify complementary aspects of events and custody. The operational result should be straightforward: when a buyer asks what happened to a product, the factory can provide a coherent, bounded and verifiable answer.