Food Traceability List (FTL): Covered Food Categories and Scope

Check product identity, form and ingredients

The Food Traceability List is not a broad label for every food that might present a safety risk. It identifies specified foods and categories for which the additional records apply. The wording, product form and any listed-food-as-ingredient condition matter. A product name used commercially may not match the exact regulatory description, so a scope decision should preserve the product specification used to reach it.

Document the scope decision

For a packaged or multi-ingredient product, do not assume that the presence of a listed food automatically settles the answer. FDA explains that the additional requirements can apply to foods containing listed foods as ingredients when the listed food remains in the same form in which it appears on the list. Processing that changes the food’s form can affect the analysis. Document the ingredient, its form at use, the processing step and the specific list entry considered; escalate ambiguous cases for qualified review.

Examples of weak and strong scope evidence

A scope record should include the product’s common and technical name, species or variety where relevant, form, packaging and processing state, ingredient composition, supplier specification, intended use, the exact FTL category considered, the date checked and the person approving the conclusion. Keep the evidence with the product master record so purchasing, quality, warehouse and regulatory teams do not independently classify the same item differently.

Weak evidence: a product is marked “FTL: no” in an ERP field with no explanation. Stronger evidence: the record identifies the exact FTL entry, compares the product specification with the listed description, explains any form or ingredient distinction, links to the current FDA list, and names an owner and review date. Reassess when a formulation, supplier, process or product form changes.

A product-scope worksheet that avoids assumptions

For each candidate product, capture the commercial name, technical description, ingredients, product form, processing steps, supplier specification, intended use and the exact FTL entry reviewed. Add a short explanation of why the description matches or does not match. Where the decision depends on whether a listed food remains in the same form when used as an ingredient, describe the process step and evidence used to assess that condition.

Keep uncertain products out of an unqualified “not covered” category while the question is being reviewed. Use a pending status, name the reviewer, identify the missing evidence and set a review date. This prevents an unresolved assumption from becoming a permanent master-data fact copied into purchasing, warehouse and supplier systems.

Review scope after formulation changes, supplier substitutions, new product formats, cutting or processing changes, repacking, new channels and changes to the FTL or FDA explanation. The product name may stay the same while its form or process changes; the scope assessment should be based on the actual food and process, not just the label.

How to maintain a controlled product-scope register

Give every scope decision a unique reference so purchasing, quality and warehouse teams can refer to the same assessment. Link the decision to the current product specification and record the revision of the specification reviewed. If the ingredient statement, product form or process changes, the system should alert the owner that the prior decision may need review.

For a business with hundreds of SKUs, prioritise products using a documented screening process, but do not let a screening label become the final legal conclusion. A keyword search can identify candidates for review; it cannot reliably decide whether the regulatory description and form conditions are met. Preserve the evidence used for the final decision.

Use a review queue for uncertain cases. Include the question, missing facts, responsible reviewer, official sources consulted and decision date. When a decision changes, notify downstream functions so the product master, supplier requests and event mappings remain consistent.

Product-scope governance across teams

Assign one accountable owner for the final scope decision and identify the functions that must be consulted. Purchasing may know the supplier specification, R&D may know formulation and processing, operations may know the physical form, and regulatory/quality may interpret the list. The decision should combine these facts rather than letting one team infer the answer from a product name.

When a product is sourced from multiple suppliers, compare specifications rather than assuming that a common commercial name means the food is identical for scope purposes. Keep supplier-specific evidence linked to the product master where the differences could affect the conclusion. If a supplier substitutes a raw material, trigger a review before the new product is treated as covered or not covered by default.

Periodically sample “not covered” decisions as well as “covered” decisions. The purpose is to detect drift in product data and assumptions, not to force every product into the rule. Document the sample method, reviewer and resulting corrections.

Example: reassessing a product after a process change

Assume a supplier changes a product from a fresh form to a processed form while the commercial name and SKU remain unchanged. The old scope decision should not be copied automatically. Obtain the revised specification, document the processing change, compare the new facts with the exact FTL wording and record whether the earlier conclusion remains supportable.

Notify purchasing, quality, regulatory, warehouse and customer-data owners of the decision because the scope result may affect the fields requested from suppliers and the events mapped in the system. Retain both the old and new decisions with their effective dates so historical transactions can be interpreted under the facts that applied at the time.

This example illustrates change control, not a conclusion about any particular product category. Product-specific decisions must be based on the actual facts and current rule text.