KDEKey Data Element

A Key Data Element is a specific, named piece of information that FSMA 204 (21 CFR Part 1 Subpart S) requires you to capture and retain at a specific Critical Tracking Event for any food on the Food Traceability List, structured so that you can hand it to FDA in an electronic, sortable spreadsheet within 24 hours of request.

Three things make KDEs different from the receiving / shipping / production records you already keep:

1. Named fields. FSMA 204 specifies exactly which fields are required at each CTE — not 'something equivalent', not 'enough to identify the lot'. The field names matter for audit.
2. Anchored to the Traceability Lot Code (TLC). Every KDE record carries the TLC that links it to its assignment event and to every downstream CTE record for the same food. The TLC is what makes a 24-hour trace possible.
3. Electronically sortable on 24 hours notice. The records can live in paper, spreadsheets, ERP, WMS, your QMS, or anywhere else — but the legally-binding test is that FDA receives a sortable electronic spreadsheet within 24 hours of asking for it (§1.1455(c)(3)).

The Traceability Lot Code (TLC) is the single most important KDE. It is a unique identifier assigned to a food at one of three trigger events — and from then on the same TLC must travel with every CTE record for that food, all the way to the next transformation.

TLC assignment is triggered by exactly one of:

• Initial packing of a raw agricultural commodity (other than a food obtained from a fishing vessel) — the packer assigns.
• First land-based receipt of a food obtained from a fishing vessel — the first land-based receiver assigns.
• Transformation of a food — the transformer assigns a new TLC for the output(s).

Three KDEs travel with every TLC for the rest of its life: the TLC itself, the TLC source description (location where the TLC was assigned), and the TLC source reference (a unique reference to the location — typically a Location Description that can be tied back to coordinates or a registered facility). A KDE programme that captures TLCs without their source description and source reference is incomplete and will fail a records request.

The seven CTEs each have their own KDE schedule. The table below is the operating summary; the binding text lives in §1.1325–§1.1350.

Two things to notice. First, every CTE except the very first one (harvesting) requires a reference document type and reference document number — typically the bill of lading, the production record, the work order, or the receiving advice. Second, every CTE after TLC assignment requires the TLC source reference, not just the TLC itself; this is the field most often missed by firms that already 'have lot codes'.

FSMA 204 is unusually specific about how the records must be kept and produced. The format and retention rules are at §1.1455:

• Records must be in English (or accompanied by an English translation produced within a reasonable time).
• Records must be retained for two years from the date of creation.
• Records must be producible to FDA — on request — in an electronic, sortable spreadsheet format within 24 hours of the request (§1.1455(c)(3)).
• Original records (paper, electronic, photographic) may be kept in any format; only the response to a records request has the 24-hour electronic-sortable constraint.
• Records may be stored offsite if they can be retrieved and provided to FDA within 24 hours of request.
• Hand-written records must be legible and indelibly recorded.
• Each firm must maintain a written Traceability Plan that describes how records are kept, how TLCs are assigned, which FTL foods are handled, and the point of contact for FDA records requests.

§1.1315 requires every covered firm to maintain a written Traceability Plan. Inspectors typically ask for the plan within the first thirty minutes of an inspection; the plan is the document that says 'here is how this firm meets the rule', and the rest of the inspection tests whether actual practice matches it.

A compliant Traceability Plan contains, at minimum:

1. A description of the procedures used to maintain the records the firm is required to keep under Subpart S, including the format and location of these records.
2. A description of the procedures used to identify foods on the FTL that the firm manufactures, processes, packs, or holds.
3. A description of how the firm assigns TLCs to foods, if applicable.
4. A statement identifying a point of contact for questions regarding the firm's traceability plan and records.
5. If the firm grows or raises a food on the FTL (other than eggs), a farm map showing the areas where the food is grown or raised, with information sufficient to identify each area, including geographic coordinates.

FSMA 204 does not replace anything; it sits on top of an existing US food-regulation stack and links to international expectations.

Two practical points. First, KDE capture does not let you reduce your existing 117.305 records — the FSMA 204 records are additive. Second, KDE records being electronically sortable on 24 hours notice is FSMA 204-specific; the existing PCQI/Produce Safety records have looser format expectations. A firm that meets only the existing records baselines (paper-only, no electronic sort) is non-compliant with FSMA 204 even if it meets every other rule.

A KDE programme that exists on paper but cannot produce the 24-hour export is the worst of both worlds — full compliance cost, zero compliance value. The KPI suite below is what we monitor for FSMA 204 customers on V5 Ultimate.

1. Per-SKU FTL classification — every item has an explicit ftl: true/false flag (with the FTL category) set at SKU-creation; the kiosk refuses to receive or ship an unflagged SKU into a covered workflow.
2. TLC pattern per food category — configured at the tenant level (e.g. supplier-lot + ISO-date for received foods, WO-id + completion-timestamp for transformations); the system assigns the TLC automatically at the trigger event so operators cannot forget.
3. KDE schema enforced per CTE — receiving, shipping, harvesting, cooling, initial packing, first land-based receiver and transformation each have a typed form with all required KDEs as mandatory fields; the workflow cannot complete with a missing KDE.
4. TLC carry-forward through transformation — when a work order completes, V5 writes every input TLC + product description + quantity to the transformation record alongside the new output TLC, atomically, with an e-signature on the operator and a second on the reviewer per the customer's procedure.
5. Reference document attachment — every CTE that requires a reference document type + number forces the operator to either attach the document (PDF / image) at capture or reference an already-stored document (BOL, production record, work order).
6. Traceability Plan as a controlled document — the plan lives in V5 Document Control with effective dates, two-person e-signature on each revision, prior versions retained 2+ years per §1.1455, and the current-effective version downloadable as a single PDF for FDA.
7. 24-hour electronic sortable export — one button on the Compliance dashboard produces a CSV/XLSX (operator's choice) with one row per CTE record, one column per KDE, sortable by TLC / date / location / CTE type / FTL category; the export carries the V5 Ultimate version stamp + Traceability Plan revision for forensic traceability.
8. Mock-export scheduler — V5 runs the 24-hour export on a monthly schedule (configurable), verifies that every required KDE is populated, and opens a finding in the Quality module for any missing field; this is the operational test that prevents an inspection surprise.

1. TLC not assigned at the trigger event — the food enters the firm with a supplier lot but no TLC, and the supplier lot is then treated as the TLC; this often fails because the supplier's lot rules change without notice.
2. TLC not carried through transformation — the operator records the inputs and the outputs separately, but never the link between them; the forward + backward trace cannot meet.
3. Ship-from location confused with supplier address — they are often different (a co-packer ships from one address while invoicing from another); FSMA 204 requires the location of where the food was shipped from.
4. Reference document number captured but document not retained — the BOL number lives in the system but the BOL itself was thrown out; on records request the firm has the number but not the document.
5. Mixed FTL and non-FTL foods on the same receipt without differentiation — KDEs captured for the whole pallet rather than per SKU; the FTL line item gets buried.
6. Records exist but are not electronically sortable within 24 hours — paper logs, three different spreadsheets across three buildings, a folder structure no one has ever exported from; the underlying data is complete but the format test fails.
7. Traceability Plan stale or missing the farm map — the firm grows an FTL food but never produced the §1.1315(b) farm map with geographic coordinates; this is one of the most common findings on farms.
8. FTL changes not tracked — FDA updates the FTL but the firm's SKU classification has not been re-reviewed; new FTL foods are being received without KDE capture.

Two trajectories matter for any KDE programme decision in 2026:

• FTL expansion. FDA has stated that the current FTL is a starting point. Industry expectation is that the list will expand to additional categories (e.g. seafood beyond the current entries, dairy beyond soft cheeses, fresh produce beyond the current categories) over the next two FTL revision cycles. A KDE programme designed only for the current FTL will need rework; a KDE programme designed as 'capture KDEs for everything, flag the FTL ones for export' will not.
• The 24-hour electronic-sortable export as de facto baseline. FDA has signalled in public meetings that the format expectation in §1.1455(c)(3) will become the operational baseline for non-FSMA-204 records too — i.e. firms will be expected to produce electronic sortable records on short notice for any FDA records request, not only Subpart S. Designing every receiving / shipping / production record system around 'exportable in CSV/XLSX in minutes' is the correct response.

The customers who will struggle in 2026 are not the ones with paper-only records — those firms know they have to change and are budgeting for it. The hard cases are firms with three or four electronic systems (ERP for receiving, WMS for inventory, MES for production, QMS for quality), where the data is technically electronic but cannot be combined into one sortable spreadsheet in 24 hours. The structural decision is one capture point per CTE — the kiosk on the floor — that writes the KDEs once to a single store. That is the V5 Ultimate model.