Recall Traceability: RFP, Mock Recall and Acceptance Design

When a quality issue occurs, searchable records alone do not make an effective recall traceability system. A manufacturer must be able to start from a suspected item, lot, process or period; reconstruct the affected raw materials, work in process, finished goods and destinations; explain what is included and excluded; and hand the result to quarantine, notification and recovery operations. This guide is written for manufacturing teams in Thailand and covers data design, RFP requirements, FAT/SAT, mock recall tests and contractual acceptance criteria.

Recall traceability must support decisions, not merely store records

Most factories already retain production, inspection, inventory, shipment and label records. Quality assurance, however, needs more than proof that records exist. When an incident is detected, the team needs to decide what must be stopped, how far the investigation should extend, what can safely be excluded and who must be notified—and it must explain each decision with evidence.

If raw-material lot A is suspected, displaying its receipt record is not enough. The system must connect A to production orders, processes and equipment; show transformations into intermediate lots; preserve splits and combinations; identify finished-goods lots, pallets and shipment documents; and reach each direct consignee. Conversely, products made during a similar period should not automatically be recalled if trace evidence shows they did not consume lot A. Without a defensible exclusion reason, they remain part of the conservative scope.

A useful solution therefore does four things together:

1. Expands the candidate population without hiding possible connections.
2. Narrows an unnecessarily broad population using traceable evidence.
3. Exposes missing, duplicated, corrected or unsynchronised events as exceptions.
4. Transfers the included, excluded and unresolved populations to quarantine, communication, recovery and CAPA workflows.

Acceptance should not be based only on an attractive screen or a fast demonstration. The business value lies in turning records into a repeatable recall decision.

Backward traceability, forward traceability and genealogy

Three related views clarify the design.

Backward traceability finds the origin

Backward traceability starts from a finished product or complaint sample and follows the chain upstream to raw-material lots, suppliers, receipts, production conditions, equipment, operations and inspections. It answers: “What went into this product, and under what conditions was it made?”

Forward traceability finds the destinations

Forward traceability starts from a suspected material, process, machine or production period and follows the chain downstream to work in process, finished goods, inventory, shipments and consignees. It answers: “Where could this issue have travelled?”

Genealogy preserves transformations, splits and combinations

Genealogy connects the upstream and downstream views. It is not merely a list of one-to-one movements. Mixing, splitting, merging, rework and substitutions create many-to-many relationships. If those relationships are lost, backward and forward searches stop at the most important point.

The GS1 Global Traceability Standard describes Critical Tracking Events (CTEs), including receiving, transformation, packing, shipping and transport, and Key Data Elements (KDEs) that explain Who, What, Where, When and Why. Its framework includes tracing back to the direct supplier and tracing forward to the direct recipient at minimum. This is a useful design reference, but it is not an identical legal obligation for every industry and jurisdiction.

For the food and feed chain, ISO 22005:2007 sets out principles and basic requirements for the design and implementation of traceability systems. ISO confirmed the standard in 2022, so it remains current. A company should still determine which standards become contractual requirements based on its product, market, customer and certification scope.

Design the starting keys and the lot tracking data model first

A recall investigation depends heavily on what can be used as a starting key. Candidate keys commonly include:

• item code or product identifier;
• finished-goods lot, batch or serial number;
• raw-material or component lot;
• production order, routing step or operation record;
• process, line, machine or tool;
• event time and suspected period;
• case, pallet or logistics unit;
• shipment, delivery or sales-order number; and
• consignee, receiving location or storage location.

These fields must do more than appear as filters. They must reconnect the events unambiguously. A material-consumption event, for example, should link the input lot to its production order, process, quantity, unit, location, event time and operator. A completion event should connect the output lot to all input lots. A shipping event should connect product lots or logistics units to a destination.

Avoid “the timestamps are close, so they must match”

Factories sometimes join PLC, MES, ERP, WMS and inspection data by timestamp. A timestamp-only join is fragile. Device-clock drift, time-zone differences, network delays, batch entry, manual input and retries can make representations of the same event arrive with different times.

Assign a unique event_id to every event. Store the business occurrence time separately from the system registration time, together with its time zone or UTC offset. When a record is corrected, do not erase the previous value. Preserve the before and after values, reason, operator, approver and correction time. This lets an auditor reconstruct what changed and what information was available when a decision was made.

Define the system of record field by field

Saying “ERP is the master” or “MES is the master” is too broad. The item master may come from ERP, production execution from MES, machine settings from equipment, inspection results from QMS and logistics units from WMS. Define the authoritative source, synchronisation owner and conflict rule for each field. Also define temporary recording during an outage and reconciliation after recovery.

GS1 identifiers such as GTIN, GLN and SSCC, together with barcodes, EPC/RFID and EPCIS, can connect physical and information flows. They are options, not a claim that one technology is legally mandatory in every market. Select them according to the required identification granularity, reading environment, partner interoperability and maintenance capacity. See our guide to selecting barcode, QR and RFID for traceability for a practical comparison.

Exceptions determine whether the recall scope can be reconstructed

A normal-path demonstration makes traceability look easy: scan a receipt, consume it against an order, print the finished label and ship it. Real recalls become difficult at exceptions.

Transformation, splitting and merging

When one input lot is split across several work orders, every child must remain reachable. When several intermediate lots merge into one output lot, every parent must remain traceable. Continuous processes and mixing vessels also need explicit boundary and carry-over rules.

Rework and substitute material

If a rejected lot is reworked into another lot, the source and reinsertion destination must be linked. If a shortage causes substitute material to be used, the standard BOM cannot reproduce the actual product. Record the approval, actual consumption, quantity and reason as events.

Label reissue and manual correction

A reissued label creates a risk of duplicate use or mislabelling. Preserve the invalidation of the old label, reason, approver, quantity and target unit. A manual correction should preserve the original data and approval history, with permissions preventing an unauthorised edit from silently changing the recall result.

Delay, duplication and offline resend

Events stored during a network outage may arrive out of sequence after recovery. The same event can be delivered more than once. Idempotent processing by event_id, separate occurrence and registration timestamps, and visible synchronisation status are necessary.

Returns

When returned product is restored to stock, repacked or shipped again, connect it to the original shipment and subsequent disposition. Treating a return only as a new receipt can break the chain to the original consignee, storage conditions, reinspection and relabelling.

These cases are not minor items to “handle operationally later.” Put them at the centre of the RFP and acceptance tests, including owners, approvals and outage procedures.

What primary sources say in different jurisdictions

Requirements vary by product, role and destination market. The following sources inform system design but do not create one legal rule for every manufacturer in Thailand.

United States: foods covered by the FDA Food Traceability Rule

The US FDA Food Traceability Rule requires records of KDEs associated with CTEs for foods on the Food Traceability List (FTL). When FDA requests the relevant records, providing them within 24 hours—or within a reasonable time agreed by FDA—is a central requirement. Covered records must be retained for two years and, in specified circumstances, supplied as an electronically sortable spreadsheet. Foreign firms handling FTL foods for the US market can also fall within scope.

The 24-hour period belongs to this particular US FDA rule and its conditions. It is not a universal recall deadline for all products, industries or jurisdictions.

The original compliance date was 20 January 2026. Following a congressional directive, FDA has stated that it does not intend to enforce the rule before 20 July 2028. That should not be read as a reason to postpone preparation. Agreeing data fields, connecting trading partners, resolving exceptions and rehearsing retrieval require sustained work.

FDA reported that its Traceability Readiness Tabletop Exercises, held with industry participants from 9 March to 1 April 2026, asked participants to locate product records for a short specified period and provide them within 24 hours in an electronically sortable tabular format. In this specific regulatory context, the exercise highlights that records must be retrievable and deliverable—not merely retained.

European Union: GPSR and the Safety Gate example

The EU summary of the General Product Safety Regulation explains that an economic operator who identifies a dangerous product must act immediately and notify authorities and consumers. It also addresses basic safety and traceability information on products or packaging. Retention periods and duties differ by role and circumstance, so the applicable text should be checked for each business.

The EU Safety Gate 2025 report recorded 4,671 alerts for non-food consumer products in 2025—13% more than 2024 and more than twice the 2022 number—and 5,794 follow-up actions, up 35% year on year. These figures concern the EU non-food consumer-product system. They do not represent a rate or legal duty for general manufacturing in Thailand. They do show why cross-border operations should define notification ownership and evidence by sales destination.

Thailand: recall procedures in the food GMP context

The Thai FDA Food Division’s page for manufacturers provides, in the food GMP context, examples of materials concerning product recall procedures, recall results and records for the disposition of recalled products.

These are Thai food GMP/SOP materials. They should not be extended into a blanket legal obligation for automotive, electronics or medical-device operations. Each factory should confirm the Thai rules applicable to its products, export-market rules, customer-specific requirements and certification obligations with qualified specialists.

Connect trace data to the complete recall workflow

A trace search screen is only one step. Connect it to the operational flow:

1. Detection: register a complaint, inspection failure, process deviation or supplier notice.
2. Provisional scope: define the suspected starting key and initial period.
3. Quarantine: hold candidate stock at the factory, warehouse and in transit.
4. Backward and forward tracing: reconstruct upstream origin and downstream destinations.
5. Scope confirmation: classify included, excluded and unresolved items, with evidence.
6. Notification: after approval, notify the authorities, customers, partners or consumers required for the case.
7. Recovery: manage instructions, quantities, deadlines, contacts and logistics.
8. Reconciliation: reconcile shipped, in-stock, quarantined, recovered, consumed and disposed quantities.
9. Disposition: approve and record inspection, rework, return or destruction.
10. CAPA: track cause, containment, corrective action, preventive action and effectiveness.

Version the scope. If it grows or narrows during investigation, retain who changed it, when and why. Overwriting the latest list makes it impossible to explain why an earlier notification differs. For the related front end of incident handling, see information design for faster manufacturing complaint response.

Twelve requirement areas for a recall traceability RFP

1. System boundary

Draw the boundary across suppliers, receiving, production, inspection, warehouses, shipping and customers. Include manual work and third-party warehouses.

2. Authoritative data source

Define the system of record for each field, including items, lots, execution, inspection, inventory, shipment and consignee. State reconciliation rules where double entry remains.

3. Identification granularity

Specify whether each point identifies an item, lot, container, case, pallet or serial. Finer is not automatically better; balance recall scope against operational burden.

4. Query performance

Define starting keys, date ranges, representative data volume and concurrent users. Any response-time value should be a customer-defined contractual acceptance criterion, not presented as a general regulatory value.

5. Retention

Set retention according to jurisdiction, customer contract, product life and quality period. Do not copy a specific requirement, such as the FDA rule’s two-year retention for covered records, to unrelated products.

6. Permissions and approval

Separate viewing, entry, correction, approval, recall instruction and master-data change. Define emergency delegation and post-use review.

7. Audit trail

Retain and export event_id, occurrence time, registration time, before/after values, reason, operator and approver.

8. Offline operation and retries

Specify local buffering, resend, duplicate prevention, event ordering and unsynchronised-data alerts.

9. External integration

Define interfaces, ownership and reprocessing for ERP, MES, WMS, QMS, PLCs, inspection equipment, label systems and partner EDI.

10. Backup and disaster recovery

Define scope, frequency, retention, restore process, restore tests and alternative operations. Recovery time and tolerated data loss are examples of values the customer must set by contract; they are not universal regulatory numbers.

11. Output formats

Specify who can export the included, excluded and unresolved populations, evidence, quantities, destinations and audit logs, and in which format. Test any authority- or customer-prescribed output with sample data.

12. Languages and time zones

Define Thai, Japanese and English labels, descriptions and reason codes. Specify how local time, UTC and daylight-saving time are stored and displayed. Keep translated labels separate from authoritative codes so language changes do not alter genealogy.

For broader programme planning, read our manufacturing traceability implementation guide.

Design FAT, SAT and the mock recall test as different controls

FAT generally verifies requirements and interfaces in the vendor’s configured environment. SAT verifies them with the factory’s equipment, network, devices, permissions and operating conditions. A mock recall tests whether the organisation can use realistic data to determine scope and carry out the workflow. Do not turn all three into the same happy-path demo.

Test data should include:

• an input lot split across several production orders;
• several intermediate lots merged into one finished lot;
• rework reintroduced into production;
• approved material substitution;
• label reissue and old-label invalidation;
• missing mandatory data;
• duplicate delivery of an event;
• delayed data following an offline period;
• correction of an erroneous entry;
• sites in different time zones; and
• a return followed by reinspection or new disposition.

For every scenario, verify not only the included population but also why other lots can be excluded and which exceptions remain unresolved. A system that silently treats missing data as no match can produce an attractively small—but unsafe—scope. Missing evidence should remain unresolved and be escalated.

Use realistic volumes and inconsistencies. A ten-row demonstration cannot reveal production-scale performance, duplicate events or master-data conflicts. With appropriate protection for confidential data, use a representative period, volume, exception mix and integration delay. Quality, production, warehouse, IT/OT and customer-service teams should record start time, decisions, communications, approvals and completion criteria.

The FDA’s 2026 tabletop exercise used a 24-hour provision in the specific FTL-rule context. It does not mean every company should set a universal 24-hour mock recall target. A company should establish contractual acceptance criteria according to its products, hazards, jurisdictions and customer commitments.

Acceptance table: fields for customer agreement, not universal standards

The values below are examples of items to complete in an RFP or acceptance specification. They are not regulatory numbers or industry-wide standards.

If a contract uses values such as “complete the mock recall within two hours” or “match 100% of the known affected lots,” those are examples of factory-defined contractual acceptance criteria based on risk and operations. They are not regulatory values supplied by this article. Define the timer start, completion condition, denominator and missing-data treatment as well as the number.

A four-stage implementation before tool-led expansion

Stage 1: data dictionary, ownership and correction rules

Standardise the meaning and format of items, lots, serials, orders, locations, machines, consignees and reason codes. Assign authoritative sources, entry owners, correction rights, retention and missing-data actions. Establish accountability before selecting extra technology.

Stage 2: mock recall on one product and one line

Select a representative product and line, then perform backward and forward tracing against past production. Include one exception-heavy operation. Classify included, excluded and unresolved records, then correct the dictionary and work instructions.

Stage 3: adjacent processes and warehouse

Extend to receiving, upstream and downstream operations, inspection, packing, warehousing and shipping. Test offline operation, label reissue, returns and stock transfers where responsibility changes between departments.

Stage 4: external trading partners

Agree identifiers, data format, sharing timing, corrections and emergency contacts with suppliers, logistics providers and customers. Everyone need not use the same application, but minimum data and responsibilities for direct suppliers and recipients must be clear.

Run another mock recall at the end of each stage. Do not wait for a perfect dashboard: use the exercise to expose missing records and unclear ownership, then feed them back into design.

Five common failures and how to avoid them

Failure 1: abundant equipment data that cannot be linked to a lot

Collecting large volumes of temperature, pressure or speed data does not support a recall decision if no unique relationship identifies the lot and process step to which each value belongs. Link machine data explicitly to production orders, process steps, equipment and start/end events.

Failure 2: storing only the latest value

If only the corrected value remains, it is impossible to reconstruct what information a person saw when making an earlier decision. Preserve the original value, correction, approval and reason as history.

Failure 3: excluding records with missing data from the query

If an untraceable record is returned as “zero matches,” it can appear to have been safely excluded. Missing evidence must be shown as an unresolved population and transferred to manual investigation or conservative quarantine.

Failure 4: acceptance testing is only the vendor’s happy-path demo

The customer should prepare split, merge, rework, label-reissue, return and time-zone scenarios and compare the output with a known-answer dataset. Judge separately whether an operation can be performed and whether its result is correct.

Failure 5: copying a regulatory number to another industry

The US FDA values of 24 hours and two years belong to the covered rule and conditions. Do not generalise them to the EU, Thailand, automotive or electronics operations without checking the applicable regulation and contractual requirements.

FAQ

What is recall traceability?

It is the combination of processes, data and systems used to trace from a quality issue to potentially affected materials, work in process, finished goods, inventory and destinations; classify included, excluded and unresolved items with evidence; and support quarantine, notification, recovery, reconciliation and CAPA.

What is the difference between backward and forward traceability?

Backward traceability starts from a finished product or complaint and finds its upstream inputs, suppliers and processes. Forward traceability starts from a suspected input or process and finds downstream products, inventory, shipments and destinations. Genealogy through transformation, splits, merging and rework connects them.

What should a mock recall test verify?

Verify the affected population, exclusion reasons, unresolved exceptions, quantity reconciliation, approvals, communication, logs and exports. Include split/merge, label reissue, missing and duplicate data, delay, correction, time-zone differences and returns. Target time and matching rates should be customer-defined contractual criteria after checking applicable regulations.

Can we start with an existing ERP or Excel?

Yes. Start with a data dictionary, starting keys, authoritative sources, correction history and owners, then run a one-product, one-line exercise. Excel becomes difficult when controlled multi-user editing, audit trails, permissions, deduplication, interfaces and production-scale performance are required. An existing ERP can remain part of the architecture while MES, WMS, QMS or a trace platform fills other roles.

Should we use barcode, QR or RFID?

Choose according to read distance, bulk reading, dirt, metal, moisture, label reuse, data capacity, equipment cost and partner compatibility. Begin with the required identification granularity and exception controls, not a preferred device. Consider GS1 identifiers and EPCIS where partner interoperability requires them.

What determines the cost?

Cost varies with lines and sites, identification granularity, scanners and printers, labels, the number of ERP/MES/WMS interfaces, data quality, exception flows, retention, availability, languages, partner connections, validation scope and support. Define the system boundary and mock recall scenarios before requesting an accurate proposal.

Conclusion: make the mock recall—not the screen—the unit of acceptance

Recall traceability must reconstruct affected scope from a suspected starting point, explain included, excluded and unresolved items, and transfer decisions into action. Design stable starting keys and event_id; keep occurrence and registration times separate; preserve correction reasons and users; and handle transformation, splitting, merging, rework, substitutions, reissued labels, manual corrections, offline retries and returns from the beginning.

The RFP should specify boundaries, authoritative sources, granularity, performance, retention, permissions, audit trails, interfaces, recovery, output, languages and time zones. FAT, SAT and mock recall tests should use realistic exceptions. Acceptance values should be agreed by the customer in the contract for the applicable risks and jurisdictions. A practical first move is to define a data dictionary and ownership, then run a one-product, one-line mock recall that produces included, excluded and unresolved populations.

TOMAS TECH can help at the planning stage with a Thai factory data dictionary, RFP structure and mock recall design that makes use of existing ERP, MES and WMS assets. Contact us with your product scope, current systems and the trace scenario that is difficult today.

Primary sources

• FDA Food Traceability Rule
• FDA Traceability Readiness Tabletop Exercises
• FDA Questions and Answers: Food Traceability Rule
• GS1 Global Traceability Standard
• GS1 traceability overview
• ISO 22005:2007
• EU General Product Safety Regulation summary
• EU Safety Gate 2025 report
• Thai FDA Food Division — knowledge for manufacturers