Mock Recall Testing for Factory Traceability: SOP and Acceptance Criteria

Being able to “search for a lot number” is different from being able to “identify the destination of problematic products and appropriately isolate only the affected items.” When implementing a traceability system in a Thai factory, design a mock recall test before requesting a quote. Incorporate this test into acceptance criteria after system implementation: this approach helps uncover data gaps and handoffs between departments that are not visible from mere screen function explanations. This article provides concrete scenarios, required data, RFP requirements, and go/no-go criteria for FAT/SAT, focusing on relationships from raw material receipt to production, repackaging, warehousing, and shipping. While the Manufacturing Traceability Implementation Guide covers the overall picture, here we focus specifically on using mock recalls for system selection and acceptance testing. First, have your legal and quality assurance teams confirm the rules applicable to your industry, product, and export destinations. Note that mock recalls are training exercises and cannot substitute for actual regulatory recalls or official notifications.

What Does a Mock Recall Test Prove?

A mock recall test is a drill designed to verify whether participants can, starting from a hypothetical quality issue, trace the relevant raw materials, intermediates, finished products, stock, and shipped destinations and carry out required actions. For example, suppose a “suspicion of foreign matter contamination in raw material lot RM-27.” You would trace every manufacturing order using RM-27, product lots, commingling or rework on the same line, warehouse storage locations, pallets, shipping documents, and customers. In the opposite direction, you may start from a returned finished product lot and try to trace back to the raw materials, processes, inspections, equipment, and time frames involved. To avoid confusion with real stoppages or official notifications, record the involved lots, start times, participants, and data in advance and clearly display “TRAINING” in all communications used in the drill.

GS1’s Global Traceability Standard centers traceability information design on Critical Tracking Events (CTEs)—such as receipt, transformation, packaging, and shipping—and Key Data Elements (KDEs) describing each event. It also links tracked objects and locations, including who, what, where, when, and why. This is not certification for off-the-shelf software, but rather a design framework for factories to decide “what records to keep at which process.” The GS1 Global Trace Check List helps check what information to exchange and the scope of traceability. Even if a system can print barcodes, you cannot determine impact if received lots are not linked to consumed lots.

End deliverables should not be “screenshots of search results” alone. Instead, assemble: (1) definition of suspect lots, (2) rationale for affected and unaffected finished products, (3) an isolation list for in-plant stock, (4) shipped customers/quantities/contact persons, (5) missing data discovered, (6) quantity reconciliation, and (7) a timeline of the exercise. Audit trails should show which records were edited or corrected after-the-fact. These must be executable by following a procedure, not dependent on specific personnel expertise.

Don’t Judge Pass/Fail Solely by Trace Time

Requirements like “traceability completed within 2 hours” are contractual test targets set by the factory, based on product risk, customer agreements, supply chain, and applicable regulations. The timeframes in this article are illustrative and not by law. Traceability cannot be considered a success if affected/unaffected items are misclassified, even if the search is fast. Acceptance criteria should combine completeness of identification, quantity reconciliation, party identification, data reproducibility, and response time.

Test timestamps must also be defined. T0 = when QA records the suspect lot and declares test start. T1 = when a list of isolation candidates in the plant is prepared. T2 = when shipped targets and direct customers are identified. T3 = when QA approves trace results, quantity reconciliation, and exceptions. The time from screen search to result display is not the same as time to business decision. Use a common timezone (e.g., ICT/UTC+7), and do not mix system event times, printed report times, and handwritten record times.

For a pilot, you may provisionally set “Within 60 minutes from T0, identify relevant in-plant inventory; within 120 minutes, confirm the directly shipped customers; explain quantity mismatches,” but understand this is just an example. Real criteria must be agreed by QA, sales, logistics, and legal after baseline measurement. Specify in contracts whether lack of customer return data constitutes a system failure. Any range with missing third-party data should still be reported as unconfirmed, not “traced complete.”

What Relationships to Store from Receiving to Shipping

First, map the product flow and align physical identification units with those used in your system. At receiving, tie together supplier lot numbers, internal receipt lots, and container or pallet IDs. In production, link manufacturing orders, input lot numbers and usage, equipment/line info, start/end time, and generated intermediate/final product lots. For factories with mixing, splitting, reinjection, rework, or repackaging, a simple “one raw material to one product” table is inadequate: capture parent/child relationships where multiple parent lots create a child lot, which may further split into multiple shipped units.

In the warehouse, manage finished product lots, box/pallet IDs, storage location, and status (usable, on hold, quarantined, shipped). In shipping, capture links from pallets to delivery notes, sales orders, transport, direct customer, and shipping datetime. If ERP holds original shipment info, avoid duplicate entry into MES or WMS—define which system is the official record per item. If retaining paper QA forms, make sure references to lots can be searched. Not all records must be attached to every product, but you must guarantee traceable data linkage during a mock recall.

GS1 defines that each business at least must trace back one level to the direct supplier and forward one level to the direct customer. This does not mean you can always trace to the final consumer within your own system. Going further requires intercompany data exchange, aligned communications, and harmonized IDs (GTIN, GLN, SSCC, etc). The key implementation issue is mapping GS1 identifiers to your customer codes. Test actual labels, scanners, terminals, and network connectivity before rollout. For detailed design, see the Trace Forward/Backward System Guide.

Mock Recall Scenarios: Avoid Only “Clean, Simple” Flows

Start with a basic “one raw material lot, one manufacturing order, one product lot, multiple customers shipped” scenario to verify elementary forward traceability. Next, try a backward recall from a finished lot. Independently prepare the “correct” answer set, fixed to the records used, by someone other than the system implementer, to catch missing documents or inventory. Compare inventory, shipping docs, production logs, and QA records.

A third scenario should involve mixing, splitting, and rework. For example, split suspect raw material RM-27 into two manufacturing orders, return some leftover to the next shift, and repackage part of the finished product. Systems that only search the first batch and stop will fail this test. The fourth scenario may include label reprints, barcode damage, delayed sync from offline terminals, and manual corrections; any changes must leave an audit trail. The fifth should test holds and returns, checking isolation not just of shippable inventory but also physical items intended for quarantine.

Conduct exercises safely. Where customer contact is needed, obtain approval in advance and use dummy contacts for training, not live customers. Ensure all communications, printouts, and screens state “TRAINING,” so drills are not mistaken for real sales holds or regulatory actions. Omitting physical checks can leave operational gaps; warehouse staff should physically point out pallets for designated lots and reconcile location, quantity, and status with system data. If real safety concerns are discovered, halt the exercise and escalate per normal QA/safety protocols.

Implementation Procedures: Confidential Start Point, Observer Record, Frozen Baseline Data

Even for announced drills, restrict pre-disclosure of the suspect lot and discovery time to a small group (the drill leader and QA). Do not provide participants with the “correct” answers; this tests real search and notification capability. For overall safety and business continuity, executives, legal, and operational contacts should know the drill window and scope. Do not simulate injury or mislead external parties: display “TRAINING” everywhere there’s a chance of outside exposure. Record the drill seed (lot number, assumed nonconformity, discoverer, location, timestamp, and disclosure extent) in a sealed envelope or access-controlled file.

Before the drill, evaluators extract “baseline data” from ERP, MES, and WMS for the period in scope—plus production logs, physical stocktakes, and shipment docs. Do not mix in data changes or inventory movement happening later. Attach extract time, scope, responsible person, and file ID or hash. IT staff must not “tidy up” data during the drill to bias results; any corrections must retain the old value, reason, approver, and timestamp, with pre-correction search results kept. Fixing deficiencies post-exercise is fine, but erasing flaws during the test is not.

Timeline example: At T0, QA leader announces drill start and suspect lot. Investigators trace raw material and work order relationships; warehouse staff physically confirm usable/hold/quarantine items; logistics extract shipped customers and quantities; sales sets up training notification routes. QA differentiates confirmed/unconfirmed areas and logs provisional quarantines. Use separate observers (not executors) to record for each action: start/end, source docs, decision makers, rejections, exceptions, and any info handed off verbally. For every time an observer guides a participant, log it as “assisted,” to distinguish from un-aided completion.

The end of the drill is not displaying the search result. It is when QA can explain “what is where, and what is unconfirmed.” Follow normal QA procedures for actual decisions on isolation, sales stop, or customer notification. Use the drill to tabletop-approve notification flows, including the escalation chart (responsible, backup, contact method, response check). Confirm applicability to night shift/holidays. Treat a phone call not as “notification delivered”; you must log sending, receipt, understanding, and action separately. See FDA’s recall effectiveness checks, but remember: this is a training notification, NOT a real recall.

Minimum Items for Observer Logs

Drill Run Sheet and Pass/Fail Matrix

The exercise manager distributes the following table before the start, while only the evaluator retains the seed content and the correct answer set separately. The “planned” times at each stage are for reference; the actual time limits must be filled in according to contractually agreed values. Observers record both the scheduled and actual times to see where any delays occur.

Do not aggregate the pass/fail into a single overall score; instead, use mandatory gates for judgment. For example: “Extract all lots and direct delivery destinations included in the correct answer set”; “Provide source trace events justifying items excluded from scope”; “Explain all quantity differences between physical goods and documentation”; “Audit trail is left”; “Approval by authorized personnel.” Even if the time target is achieved, if one element is missing, the result is provisionally failed and the cause as well as the need for retesting is documented. If the correct answer set itself is uncertain, the evaluator conducts additional investigation before making a judgment; guessed answers by operators are not promoted to correct.

Write quantity equations with unified units for each product and process step. At the raw material input stage: “Opening raw material inventory + Incoming quantity − Ending raw material inventory − Process input quantity − Approved disposal quantity = Unexplained variance.” At the manufacturing stage: “Opening work-in-process equivalent + Process input quantity − Ending work-in-process equivalent − Finished good output quantity − Process loss/disposal quantity = Unexplained variance.” At the finished goods stage: “Opening finished-goods inventory + Production output quantity + Returned and restocked quantity − Ending inventory − Shipment quantity − Disposal quantity = Unexplained variance.” Use only values for the same lot and accounting period; do not double-count transfers between locations within the factory. If returned products are reshipped, keep original shipments, restocking, and reshipment as separate events to avoid double-counting. For formulations involving unit conversion or moisture changes, predefine conversion factors and their rationales. Any nonzero variance is left as “unexplained” and should not be offset by estimates.

Closeout: Evidence Pack, Corrective Actions, Re-testing

At drill end, assemble into an evidence pack: seeds, frozen baseline data, search conditions and results, forward/backward lot relationship diagrams, quantity reconciliation tables, physical confirmation records, training notifications, approval histories, observer logs, and outstanding issues. Just screenshots are not enough—keep event IDs and original doc numbers. Files with customer names, formulas, or personal info must be managed for access rights and retention per company policy. When reporting to management, always show the confirmed scope, unconfirmed shipments, quantity differences, initial response times, and next escalation steps.

Handle deficiencies by criticality. Critical: missed target lots, wrongly judged items “safe,” failure to quarantine goods, key records lost. Moderate: manual workarounds, slow explanation of quantity gaps, late notification to backup contact. Minor: cosmetic/reporting fixes that do not affect judgments. These categories are only proposed here and are not an official standard. Record the cause, interim correction, permanent fix, responsible person, deadline, and verification method for each issue. Do not pass a drill with critical deficiencies just because “will fix it before next time.”

In re-tests, do not simply repeat the same search on the same lot. After fixing causes, use unseen lots with similar relationships, and check that original flaws are absent. If rework logic changed, ensure regular batch parent/child links remain intact. When comparing repeated drills, always note difference in product, process, and batch complexity. Count reduced time only as one metric; always check in parallel: misses, excessive quarantines, quantity discrepancies, and whether observer support was required.

Quantity Reconciliation: Not Just Number of Search Results

In a mock recall, you must always be able to explain the relationships between input quantities, product output, stock, scrap, and shipments. Directly totaling weights, pieces, boxes, and pallets is not always meaningful: standardize units, and match recipe, yield, and packout at each process step. For example, input 100 kg raw material, output 90 kg finished goods, record 7 kg process loss, and set aside 3 kg for isolation, totaling 100 kg. These numbers are illustrative only, not general industry standards. If you report “found 90 kg finished goods” without accounting for process loss, the disposition of the other 10 kg is unknown.

On the shipping side, classify finished goods into “usable in-plant stock,” “on hold/quarantined,” “shipped to customer,” “returned/re-entered,” and “process waste,” removing any double-counting. Include goods in-transit, consignment, samples, or free goods as appropriate for your product. If ERP and WMS quantities differ, do not simply trust WMS—confirm all corrections, voids, partial shipments, and post-loading adjustments. Rather than pursuing “zero difference” mechanically, judge if the cause, supporting documentation, and corrective owner are identified. Unexplained discrepancies remain as open issues.

Compare true answer sets and search results as:

• Missed = Correct targets – System search results
• Excess = System search results – Correct targets

Record each separately. Misses risk unchecked dangerous products; excesses mean unnecessary quarantine, customer contact, or disposal. Define acceptable thresholds in advance. If you know the “correct” set is itself uncertain, report accordingly—not as “perfect match.” Finer lot granularity may improve targeting, but comes with extra input, labeling, and operational burdens—balance risk and cost.

System Configuration: Start with Events and Division of Responsibility

Don’t just specify “Traceability system as a whole” in RFPs, or ERP, MES, WMS, and scanner boundaries will be blurred. For each event—receiving, production input, QA, storage, and shipping—list input operators, terminals, master record system, integrations, and fallback procedures. Database designs must hold parent/child relationships for multiple lots and allow both forward and backward search. Also ensure searches can link back to event evidence and original docs. “Having a graph display” is less important than “being able to verify the actual process records building that graph.”

Barcode scanning reduces input error, but if applied to the wrong label at receipt, only “accurate wrong information” is registered. Include checks at each step to prevent misconnections: match item and lot at receiving, verify order before input, and check product and package at boxing. All manual entries due to scan failure must include reason, operator, double-check, and audit logs. If terminals go offline, confirm local buffering, resend patterns, duplicate suppression, and conflict resolution; loss or misordering of events after power recovery can cause mock recall errors.

With contract manufacturers or external warehouses, do not limit your model to internal data. Agree on identifiers, data formats, transmission timings, and correction procedures for handovers. If a supplier cannot provide data, document a fallback route: contact info, report name, expected response time, and drill participation. In acceptance tests, explicitly check both normal integration and partner delay scenarios. Never patch missing information with guesses—reliable recall depends on verified system data.

Move RFP Requirements from Screenshots to Test Cases

In the RFP, attach not only feature names such as “lot search” or “barcode support,” but also anonymized sample production/shipment data and the expected result set for use in the drill. Have vendors execute their demo using the same scenario end-to-end, so you can compare apples-to-apples. Be sure to include multi-ingredient mixes, rework, repackaging, partial shipments, and returns. Provide not just clean demo datasets, but also missing data, duplicates, corrections, and offline cases, to see exception handling. Always anonymize confidential info (real customer names, formulations, prices) in the RFP dataset.

Do NOT compare quotes on initial cost alone—factor in label/scanner/hardware/network, master data, system integration, training, migration validation, support, and repeated drills. Do NOT demand unsupported claims like “X% risk reduction by installing our software.” Instead, baseline current traceability time, unexplained quantities, manual checking burden, and compare actual improvements post-pilot. Judge ROI both on time reduction and on reduction in misses and excessive quarantines.

Distinguish FAT and SAT

FAT (Factory Acceptance Test) uses anonymized data to check identifier matching, parent/child discovery, quantity calculations, CSV output, roles, audit trails, and API resending. SAT (Site Acceptance Test) is performed onsite with actual labels, scanners, wireless, production lines, warehouse, ERP interface, and shift changes. Factors causing a FAT search to pass but SAT to fail include: label quality, scan angle, network dead spots, master data mismatches, onsite exception handling. Assign responsible persons on both supplier and customer sides to approve results and open issues before handover.

For SAT go/no-go, write into the contract the test products and processes, how correct answer sets will be built, start/end times, allowable unconfirmed scope, how quantity differences will be handled, and re-test conditions. “It worked in the vendor’s demo” does not mean SAT is passed. On failures, analyze if caused by data, settings, onsite procedure, or external links, and document who will fix what, when, and which scenario to re-run. If fixes may impact other areas, regression test those as well. QA must have the go/no-go call—never rely on IT alone.

Standards and Foreign Regulations: Check the Scope

ISO 22005:2007 deals with general principles and basic requirements for traceability system design and implementation in food/feed supply chains. As of the latest ISO review (2022), it remains the current version. This is NOT a standard imposing blanket legal duties on all manufacturing. GS1 standards frame interoperability of identifiers and events. Always organize the applicable rules, customer audits, and certification demands for your own products and markets.

As an example of a US-specific regulation for covered foods, the FDA’s Food Traceability Rule requires affected businesses handling Food Traceability List items to record KDEs for each CTE. The FDA FAQ explains scope and exceptions. Current guidance references both the original January 20, 2026 compliance date and a proposed extension to July 20, 2028, stating enforcement will NOT begin before that. For actual coverage and latest deadlines, always check the primary source for your case. This is NOT a general legal requirement for Thai factories. Do NOT confuse the FDA’s “provide records within 24 hours” rule for covered foods with a universal 24-hour completion standard for all mock recalls.

A real product recall involves additional decision-making: hazard assessment, recall scope, customer communication, regulatory response, and execution verification. The FDA’s Product Recalls Guidance describes required information and notification under FDA-regulated recalls. A mock recall can use these as references for notification flows and direct customer contact lists, but mock recall completion alone does NOT mean your recall is finished. Actual cases depend on internal procedures, local law, and customer contracts.

Three-Stage Implementation, Drilling at Every Step

Step 1: Draw your current data map. Select one product, gather receiving labels, production logs, QA records, warehouse ledgers, and shipping docs. Ask site staff to “list all finished products using this raw lot,” and record time required, missing info, quantity differences, and reliance on individuals. Without this baseline, post-implementation improvement cannot be explained. Include a high-risk example such as rework or 3rd party storage, not just typical products.

Step 2: Pilot unique IDs and event recording on one line and warehouse area. Finalize master data for product/unit/lot numbers, limit scanner usage trials, check data entry time/location feasibility, and log read errors. Repeatedly do both forward and backward mock recalls at this stage, adding any missing fields found. Don’t rush to full rollout—or invalid codes/rules will spread. Only after fixing exceptions and solidifying training, move horizontally site-wide.

Step 3: Drill full integration with ERP/MES/WMS and external warehouse/customer linkages. Output quantities per direct customer, with QA verifying. Warehouse reconciles actual vs system; sales/logistics test the notification chain (using dummy contacts). Test nights, holidays, absentee scenarios, and network failures—can you reach all essential personnel? Categorize issues as “data,” “system,” “procedure,” “training,” or “supplier,” and re-test after each fix. Frequency of drills should match product risk and customer requirements—do NOT use a one-size-fits-all industry value.

Pre-RFP Checklist

• Has QA defined the target product, market, potential hazards, and mock recall trigger conditions?
• Are all events and responsible parties mapped: receipt, input, transformation, rework, packaging, storage, shipping, returns?
• Are identifiers linking supplier lot, internal lot, order, box, pallet, shipping doc, and direct customer established?
• After mix, split, or repack, can parent/child and quantity/unit relations still be tracked?
• In both forward and backward directions, can system search results be compared with independently prepared correct answer sets?
• Can isolated stock in-plant be physically confirmed, and shipped quantities be approved by a responsible party?
• Do test scenarios cover missing data, corrections, offline entry, returns, and contract storage?
• Can the root event, change log, and approver for each search result be reproduced?
• Are go/no-go criteria, measurement methods, retest conditions, and division of responsibility for FAT and SAT specified in the contract?
• Are all training notifications clearly separate from real recall notices, and real emergency steps defined?

Frequently Asked Questions

How quickly must a mock recall test be completed?

No universal time. Decide for your product risk, partner contracts, applicable regulation, and scope. Measure separately: time from T0 to confirming plant isolation candidates, to identifying direct customers, to explaining quantity differences, and QA approval. Even if search screens respond fast, drills are not complete until physical items are located and actually approved. Establish improvement targets in contracts, based on observed baseline.

Can we run a mock recall test before implementing traceability software?

Yes. In fact, running a mock recall with paper records, ERP shipments, and warehouse ledgers highlights where items, integration, or training are lacking. Turn the results into an anonymized RFP scenario and answer set, then compare vendors under uniform conditions. After rollout, repeat SAT with same scope to confirm improvements.

Is it necessary to contact actual customers during drills?

Normally, use internal dummy recipients or pre-approved training destinations. If you need to contact real customers, get sales/QA/legal approval and clearly state “training”. If a real hazard is suspected, halt the drill and follow normal QA/recall procedures.

TOMAS TECH in Thailand can map physical and information flows together when evaluating data collection from equipment, sensors, terminals, and MES/ERP integration. By starting with mock recall acceptance criteria, we clarify the necessary processes and responsibilities even before choosing software or products. Contact TOMAS TECH with your target product, processes, current record-keeping, existing systems, and planned mock recall scenarios to tailor your initial discussion.

References

1. GS1 Global Traceability Standard — CTE/KDE, cross-company/internal tracking design.
2. GS1 Global Trace Check List — Traceability requirements checklist.
3. GS1 Traceability Standards — Overview of identifiers and data sharing.
4. ISO 22005:2007 — Design principles for food/feed supply chains.
5. FDA FSMA Food Traceability Rule — Covered foods traceability, current deadlines example.
6. FDA Food Traceability Rule FAQ — Scope and exception Q&A.
7. FDA Product Recalls Guidance — U.S. product recall requirements.