Trace forward means starting with a raw-material lot, work-in-process lot, finished product or serial number and finding every downstream product, pack, logistics unit, location and customer that may be connected to it. Trace back follows the opposite direction toward inputs, suppliers and process conditions. Yet records in a database are not proof of traceability. A usable system must traverse transformation, split, merge, aggregation, repacking, rework and outsourced steps; disclose missing links; and produce an output that a regulator or customer can verify within the required response window.
This guide converts a definition into a Buy/Do specification: an RFP, vendor demonstration, FAT, SAT and mock-recall design. FDA’s 24-hour context and EU Digital Product Passport developments are relevant, but applicability depends on product, jurisdiction and role. Confirm legal obligations with quality, legal and the competent authority.
What do trace forward and trace back have to prove?
The GS1 Global Traceability Standard provides a common language for trace back, track/trace forward, the one-step-up/one-step-down principle between trading parties, and information that answers Who, What, Where, When and Why. Buyers should turn that language into three distinctions.
First is direction. Trace back goes from a complaint item or finished serial to materials, receiving, suppliers and conditions. Trace forward goes from a suspect input to all affected output, packing and destinations. One fast direction cannot connect cause and impact.
Second is organizational scope. One-up/one-down is an important supply-chain baseline, but it does not automatically prove which inputs entered a tank, how output was split, or which cases were aggregated. Trading-party links and internal manufacturing links must form one traversable graph.
Third is reproducibility. Store the starting identifier, master-data version, timezone, authorization, filters and query timestamp. If live results can change, freeze the submitted snapshot and query manifest.
| Search direction | Example starting point | Relationships traversed | Expected output |
|---|---|---|---|
| Trace back | Complaint product serial | de-packing, production, inputs, receiving, supplier | material lots, equipment, time, operator, inspection |
| Trace forward | Suspect material lot | transformation, split, packing, aggregation, shipment | products, cases, pallets, warehouses, customers |
| Bidirectional | Any lot or serial | upstream and downstream at one baseline time | cause candidates, impact scope, gaps, exclusions |
Design manufacturing-history tracking as an event graph
A chronological report may look complete while failing to represent splits and joins. Model objects and events as nodes connected by explicit relationships.
GS1 EPCIS 2.0.1 defines ObjectEvent, AggregationEvent, TransactionEvent, TransformationEvent and AssociationEvent, with what, when, where and why dimensions. TransformationEvent can relate inputs to outputs; AggregationEvent can represent parent-child membership. EPCIS 2.0 artefacts include JSON/JSON-LD and REST-related materials. Adoption alone does not guarantee data quality, legal compliance or query performance. An RFP should ask whether the implementation preserves operational meaning and exports testable evidence.
Manufacturing events that must be modeled
| Shop-floor occurrence | Required relationship | Failure if missing |
|---|---|---|
| Receiving | supplier lot → internal lot | cannot return to the external source |
| Transformation or mixing | input lots → output lots | downstream impact stops at production |
| Split | parent quantity → child lots | cannot isolate destinations for each child |
| Packing | product lot/serial → case | product-to-case membership is ambiguous |
| Aggregation | case → pallet/container | logistics-unit history breaks |
| De-aggregation and repacking | old parent → children → new parent | new shipment loses the old label history |
| Rework | rejected output → later input | circular reuse is missed |
| Shipping or transfer | logistics unit → ship-to/location | destination search depends on a separate report |
| Return or disposal | object → disposition | market, quarantine and disposed quantity are confused |
Suppose lots A and B are mixed into C, C is split into C1 and C2, and C1 is packed into case K. A downstream search from A must reach C, both C1 and C2, K and shipment destinations. An upstream search from K must return through C1 and C to A and B. If quantities do not reconcile, yield, samples, waste and measurement variance need reason codes. Deleting a link to make totals look clean is a failure.
Treat time, place, party and reason as strongly as identifiers
Define the uniqueness scope for lot IDs, timezones, device-clock synchronization, physical and business locations, executor and approver, and business-step/reason codes. Preserve the historical master-data version or validity period. Separate event time from record time: when an offline terminal uploads a day late, the system must show whether the record existed at the response cutoff.
Turn destination tracking into a 24-hour RFP requirement
Statements such as “traceable,” “real time” or “EPCIS ready” cannot be accepted. Put input, processing, output, clock, exceptions and evidence in the same requirement.
Scope and boundary
List products, materials, sites, external warehouses, subcontracted steps, sales organizations, retention and identifier granularity. If a partner cannot provide detail immediately, record the inquiry target, timestamp and response state instead of silently treating it as no impact.
A contractible bidirectional query
A practical clause might say: “An authorized quality user can enter any valid lot. The system traverses upstream and downstream relationships without uncontrolled cycles, including transformations, splits, aggregations, repacking and returns, and exports both results and unresolved links.” Base volume and performance limits on representative data, not copied numbers.
Where the 24-hour clock starts
The FDA Food Traceability Rule page explains, for its applicable context, that requested records—including a relevant electronic sortable spreadsheet—generally must be provided within 24 hours or another reasonable time agreed by FDA. FDA’s Traceability Readiness Tabletop Exercises ran from March 9 to April 1, 2026; the June 10, 2026 release describes a timed exercise in which participants received a record request and submitted an electronic sortable spreadsheet within 24 hours.
Translate this into an end-to-end test, not a database benchmark. Start at request receipt and include authorization, scope confirmation, extraction, partner inquiries, exception review, quality approval, file generation and submission. A manufacturer outside the rule can still choose it as a demanding customer or crisis-response target.
Because of a Congressional directive, FDA states that it does not intend to enforce the rule before July 20, 2028. This article does not describe that statement as a final compliance date. Check the applicable products, role and current FDA publication.
Define the submission package
| Deliverable | Contents | Acceptance check |
|---|---|---|
| Summary | request ID, scope, cutoff, author, approver | matches the request |
| Sortable data | IDs, event type/time, location, parties, quantity | columns can be typed, sorted and filtered |
| Relationship file | input/output, parent/child, ship-from/ship-to | same edge is reachable in both directions |
| Exception log | missing, invalid, late, duplicate, partner pending | gaps are not hidden as blanks |
| Query manifest | query, systems, versions, timezone, filters | another authorized reviewer can rerun it |
| Evidence index | source record, signature, attachment, hash/version | access and change history are verifiable |
Electronic is not the same as machine-verifiable. A scanned PDF is difficult to sort and reconcile. Bundle a human summary, sortable rows, relationships and exceptions under one request ID.
How should EPCIS 2.0 be evaluated in an RFP?
Ask a bidder to provide sample events and a live query/export rather than a slide saying “supported.”
- Can ObjectEvent represent observation or state for the target IDs?
- Can TransformationEvent retain multiple inputs and outputs?
- Can AggregationEvent add and remove case/pallet membership?
- Does repacking retain the timeline from old parent to children to new parent?
- Which versions of JSON/JSON-LD schemas and REST artefacts are implemented?
- How are unknown partner extensions isolated and reported?
- Are corrections overwritten, or retained with correction history?
If an integration layer converts native data to a standard format, version the mapping, rounding, units, timezone conversion and code translation. A successful HTTP response can still carry the wrong unit or business step. Test syntax and meaning separately.
Break trace-forward capability during FAT and SAT
A happy-path FAT does not expose what fails in a recall. Use realistic relationships and deliberately inject abnormalities.
Core scenarios
- One input is split into multiple products.
- Multiple inputs are mixed into one intermediate.
- Cases are removed from one pallet and aggregated under another.
- A damaged label is reissued under a controlled procedure.
- Rework is reintroduced on another day.
- An external warehouse splits shipment among several customers.
- A return is partly disposed and partly quarantined.
Exception-injection scenarios
| Injected problem | Expected behavior | Failure example |
|---|---|---|
| late event | mark late and distinguish cutoff completeness | display as if always present |
| duplicate event | identify and prevent double counting | shipment quantity doubles |
| device clock skew | retain original time and correction rule | overwrite evidence silently |
| unknown lot | quarantine as unresolved and notify | omit it without warning |
| unit mismatch | retain original and conversion version | add kilograms to pieces |
| deleted master | reproduce with historical version | rewrite history with current name |
| denied access | log alternate approval or break-glass | use an unaudited shared admin |
| partner pending | show pending scope and inquiry evidence | claim “no affected product” |
FAT should validate event relationships, APIs, queries, export, authorization, correction history and recovery against a fixed dataset. SAT repeats the search with real devices, networks, users, labels and shifts, exposing latency and manual steps across PLC/MES/WMS/ERP and offline recovery.
A hypothetical acceptance pack could contain 500 lots, 10 deliberate gaps and four time anomalies, with a buyer-defined target of approved export within eight hours, 100% gap classification and zero relationship errors. Those figures are assumptions, not market benchmarks or universal KPIs; adapt them to risk, volume and jurisdiction.
The GS1 Global Traceability Checklist contains 73 control points in 12 sections, and its assessment approach expects 100% for mandatory “must” requirements. Borrow the gate logic: bidirectional traversal, gap visibility, authorization, reproducibility and backup recovery can be mandatory even when an average score is high. Do not present an internal score as GS1 certification.
Turn a mock recall from a search demo into an operating drill
Include quality, production, warehouse, purchasing, sales, legal, management and external partners. Do not give participants the correct lot graph at the start.
- An authorized coordinator opens the request ID and clock.
- Quality confirms the starting identifier and scope.
- The system team creates upstream/downstream exports.
- Operations reconciles physical stock, quarantine and shipment records.
- Purchasing asks the supplier; logistics asks the warehouse.
- Exception owners classify missing, late and invalid evidence.
- A quality approver freezes the submitted version.
- An independent reviewer checks reproducibility and omissions.
Measure more than query runtime. Separate time spent finding an authorized person, waiting for a warehouse, classifying gaps and obtaining approval. After meeting a 24-hour target, examine the critical path and manual dependencies.
Data quality and governance must expose gaps
The most dangerous failure is not an error message; it is an incomplete result that looks complete. Distinguish unknown, not captured, failed validation, not applicable and partner pending. Any user exclusion must appear as a filter in the manifest.
| Responsibility | Example accountable owner | Required evidence |
|---|---|---|
| ID issuance | item/logistics master owner | numbering rule, duplicate check, retirement history |
| Event capture | process owner | work standard, device health, training |
| Interface | IT/OT integration owner | mapping, retry, dead-letter queue |
| Data quality | quality assurance | rule, exception review, closure |
| External exchange | purchasing/logistics owner | partner SLA, acknowledgement |
| Emergency export | recall coordinator | authority, runbook, approved template |
| Retention/access | data owner | retention, legal hold, access review |
ISO 22005:2007 covers principles and basic requirements for designing and implementing traceability in the food and feed chain. ISO’s page says the 2007 edition was reviewed and confirmed in 2022 and remains current. Its transferable lesson is to define purpose, scope, responsibility, procedures and records before choosing technology.
Future-proofing for the EU DPP does not mean storing everything
Regulation (EU) 2024/1781 provides an ESPR framework that includes the DPP, while detailed requirements are developed through product-specific delegated acts and related measures. Do not claim that every product immediately has identical mandatory fields.
The European Commission DPP page gives an indicative timeline: registry operational on July 20, 2026, remaining standards in September 2026, and iron and steel in Q4 2026. It also notes dependencies on publication requirements. An RFP should therefore make identifiers, events, data ownership, access policy, versions and evidence links extensible instead of freezing speculative fields.
A trace-forward platform and a DPP are not the same. The former focuses on event relationships and impact traversal; the latter includes access to and exchange of defined product information. Reliable IDs, history, versions, access and external exchange are shared foundations.
Twelve questions for a vendor demonstration
- How do you list every output and destination from this input lot?
- How do you return from a finished product to multiple input lots?
- Which events represent split, merge, rework and repack?
- Can the system distinguish an unresolved link from no relationship?
- Are event, record and correction times retained?
- Can deleted or changed masters be reproduced historically?
- Which EPCIS 2.0 JSON/JSON-LD and REST artefacts are implemented?
- How are nonstandard extensions validated?
- Who approves the 24-hour response package?
- Can sortable data, relationships, exceptions and manifest share one request ID?
- Can the same query result be reproduced after backup recovery?
- May the buyer inject abnormal events during FAT/SAT?
Use a buyer-selected lot in a live session, traverse both directions, drill one row to its source record, and have another reviewer recompute the result from the export.
FAQ: trace-forward RFPs and acceptance testing
What is trace forward?
It is the capability to start with a material, part, lot or serial and follow downstream relationships to products, packing/logistics units, inventory locations and destinations, including transformation, split, aggregation, repacking and returns.
How is trace back different?
Trace back moves upstream from a finished or complaint item to inputs, suppliers and conditions. Trace forward moves downstream from a suspect input to affected output and customers. A recall decision needs both at the same baseline time.
Can an ERP track the entire manufacturing history?
Sometimes it covers the required scope, but transformation, split and de-aggregation may live in equipment, MES, WMS or partner systems. Test required events with representative data. Our Thailand traceability system cost guide helps define scope before estimating.
Is a response within 24 hours sufficient for destination tracking?
No. Scope, completeness, explicit gaps, approval, reproducibility and machine-readable output matter as well. Treat 24 hours as the applicable FDA context or a buyer-defined gate, not a universal deadline.
Does EPCIS 2.0 automatically provide legal compliance?
No. It is a powerful common format for visibility events, but it does not decide applicable law or replace capture, quality, retention, authorization and operating responsibility.
When should serials be used instead of lots?
Choose based on recall granularity, process capability, labeling, scan workload and customer requirements. Serial and lot levels can be connected by packing and aggregation events. See our serial-number traceability guide.
How often should a mock recall be run?
There is no universal frequency here. Quality assurance should use regulation, customer requirements, product risk and major changes. Repeat after significant interfaces or warehouse changes. See the recall traceability design guide.
Does one missing record always fail acceptance?
Not every gap has the same severity. Define impact, alternate evidence and correction limits in advance. A system that cannot detect a gap and presents the result as complete is a serious failure; separate mandatory gates from improvement items.
Conclusion: buy a verifiable 24-hour evidence package
Trace forward and trace back are valuable when they traverse transformations, splits, aggregations and repacking in both directions; explain Who, What, Where, When and Why; disclose gaps; and produce a reproducible package within the response window. Put the graph, output, exceptions, authorization and reproducibility into the RFP. Inject failures during FAT/SAT. Run mock recalls as operating drills that include partners and approval.
Even at the stage of defining an RFP or FAT/SAT around existing ERP, MES and WMS in Thailand, you can contact TOMAS TECH. Share the target lot, process boundary and desired submission format, and we can help structure the data inventory and acceptance scenarios.
References
- GS1 Global Traceability Standard: https://www.gs1.org/standards/gs1-global-traceability-standard/current-standard
- GS1 EPCIS 2.0.1: https://ref.gs1.org/standards/epcis/2.0.1/
- GS1 EPCIS artefacts: https://ref.gs1.org/standards/epcis/artefacts
- FDA Food Traceability Rule: https://www.fda.gov/food/food-safety-modernization-act-fsma/fsma-final-rule-requirements-additional-traceability-records-certain-foods
- FDA Tabletop Exercises report: https://www.fda.gov/media/192993/download
- FDA release, June 10, 2026: https://www.fda.gov/food/hfp-constituent-updates/fda-releases-report-traceability-readiness-tabletop-exercises-and-updated-faqs
- GS1 Global Traceability Checklist: https://www.gs1.org/standards/global-trace-check-list/current-standard
- European Commission, Digital Product Passport: https://single-market-economy.ec.europa.eu/single-market/digital-product-passport_en
- Regulation (EU) 2024/1781: https://eur-lex.europa.eu/eli/reg/2024/1781/oj
- ISO 22005:2007: https://www.iso.org/standard/36297.html
*This article provides general RFP and acceptance-design information, not legal advice, conformity assessment, certification or a product recommendation. Confirm applicable law, customer contracts and quality decisions with qualified owners. All sample times, counts, KPIs and scores are hypothetical.*
