Independent guidance on traceability, responsible sourcing and market accessIdentity / Events / Evidence
Home / Guides / Implementation

Implementation / Implementation guide

Recall traceback and forward tracing

Test the links from a suspect input to affected outputs and destinations while keeping uncertainty visible.

Published 4 October 2026 · Independent editorial guidance

Use both directions

Traceback starts with a product or incident and investigates earlier inputs, events and locations. Forward tracing starts with a suspect input or batch and identifies related outputs and destinations. A useful incident process often needs both.

Traceability records inform the investigation. They do not automatically decide whether a recall is necessary or which formal response is required. Those decisions depend on the product, evidence and applicable procedures.

Start with the precise object

Record the identity and scope of the suspected issue. Is it a supplier lot, one serialised unit, a production window or a facility process? Include the source of the concern and any ambiguity in the identifier.

An ambiguous input can expand the potentially affected set. Record why that wider scope was used rather than presenting every highlighted output as a confirmed defect.

Follow actual relationships

Find the production outputs linked to the suspect input. Include splits, blending and rework. Then identify dispatches and destinations associated with those outputs. Preserve the query criteria and the time the result was produced.

Distinguish affected inventory still held internally from goods already dispatched. Identify missing relationships and unmatched shipment contents, since these gaps may influence investigation scope.

Reconcile the result

Check quantities against production and dispatch records. Review known exceptions and sample supporting evidence. Contact and decision workflows should follow your incident plan; the graph itself is only one part of the response.

Record which destinations are confirmed and which are inferred from incomplete data. Avoid treating “no result found” as proof that no goods were sent when data coverage is uncertain.

Run a controlled exercise

Choose a historical input lot and ask a team to reconstruct its downstream path. Measure how long it takes to identify outputs, retrieve evidence and explain gaps. Review the process with production, logistics and quality colleagues.

The interactive genealogy shows a small fictional example. Build a realistic exercise into your implementation pilot, including a missing event or repacked batch rather than only a clean case.

Frequently asked questions

Does a highlighted path mean a confirmed defect?

No. It identifies a recorded relationship that may need investigation. Defect confirmation and recall scope require the relevant evidence and decision process. Keep potentially affected and confirmed findings distinct.

What if the query returns no destinations?

Check coverage before concluding none exist. Missing dispatch content, unresolved identifiers or late records can produce an empty result. Record those limitations and reconcile with the physical and transaction records.

Sources and scope

Primary references checked on 4 October 2026. The process examples and implementation suggestions are editorial guidance. Formal standards are distinct from legal requirements.

How this resource handles evidence and corrections