Key Data Elements (KDE)

This glossary term is part of the SG Systems Global regulatory & operations guide library.

Updated January 2026 • traceability KDEs, event-based data capture, lot identity, trading partner linkage, quantities & UOM, time/location stamps, CTE mapping, FSMA 204 readiness, EPCIS alignment, 24-hour dataset response • Primarily Food Supply Chain Traceability (FTL foods, recall readiness, audit readiness)

Key Data Elements (KDE) are the specific, required data fields that describe what happened during a traceability event: who was involved, what product moved or changed, which lot(s) were involved, how much was involved, and when/where the event occurred. KDEs matter because traceability doesn’t fail from lack of paperwork—it fails because the core identifiers are missing, inconsistent, captured late, or not linked across events. KDE discipline is how you prevent “traceability by reconstruction,” which is slow, error-prone, and difficult to defend in inspections or recalls.

In modern food traceability, KDEs are most commonly discussed in the context of FSMA 204 (the FDA traceability rule). But KDEs are also the practical backbone of broader systems: retailer trace programs, GFSI traceability audits, and internal recall readiness programs. The names vary, but the operational requirement is the same: you must be able to produce a coherent, lot-linked dataset quickly. That’s why KDEs connect naturally to one-up/one-down, to end-to-end lot genealogy, and to “24-hour response” expectations.

Tell it like it is: KDE compliance is not about adding more fields to a spreadsheet. It’s about making sure the few fields that actually matter are captured at event time, validated in context, preserved through transformations, and exportable on demand. If your KDEs are typed from memory after the truck leaves, your traceability dataset is fiction. If your KDEs are scan-driven and gated, your traceability becomes a system property—reliable even when operations are busy.

“If you only capture five things for traceability, capture these: who, what, which lot, how much, and when/where—at the moment the event happens.”

1) What KDEs are and why they matter

KDEs are the standardized fields that make traceability fast and defensible. They matter because traceability is a response capability: when an ingredient lot is implicated, when a customer reports illness, or when FDA asks for a dataset, you must respond with facts—not guesses. KDEs provide those facts by ensuring each event record contains the minimum information needed to connect the chain.

From a systems perspective, KDEs are what transform scattered operational data into a trace dataset. If you have the right KDEs, you can export a clean event chain. If you don’t, you’re forced to reconstruct by reading paperwork and interviewing people. Reconstruction can work sometimes, but it’s slow and brittle, and it fails under time pressure.

2) KDEs vs documents: why “PO + BOL” is not enough

Many organizations assume traceability is “we have POs for inbound and BOLs for outbound.” That’s document traceability, and it usually fails the moment you need lot-level precision. Documents provide commercial context; KDEs provide lot-linked event truth.

Common document-only gaps:

• PO line items don’t include supplier lot identity,
• BOLs list quantities and products but not lot codes,
• ASNs exist but aren’t linked to what actually loaded,
• transformation (input→output) doesn’t exist in documents at all,
• mixed pallets and repacks break any document-only assumption.

KDE programs don’t replace documents; they link documents to event records by lot identity and event time.

3) KDE categories: who/what/which/how much/when/where

The simplest way to operationalize KDEs is to treat them as category groups that must be present at every traceable event:

If you standardize your recordkeeping around these categories, you can adapt to most regulatory and customer programs with minimal rework.

4) Lot identity: the KDE that everything depends on

Lot identity is the primary key that links events. Under FSMA 204, the concept is often expressed as a Traceability Lot Code (TLC). In general traceability, it may be your internal lot/batch number. The naming doesn’t matter; the properties do:

• Unique: does not repeat across shelf-life and investigation windows.
• Captured at event time: recorded during receiving, transformation, and shipping—not later.
• Preserved through transformations: input lots link to output lots (no dead ends).
• Visible in outbound records: appears in shipping KDEs so forward trace is possible.
• Survives mixed operations: mixed pallets, partials, repacks preserve lot identity via case/SSCC linkage.

If lot identity is weak, the rest of the KDEs cannot compensate. You can know who shipped and when, but you can’t know what lots were involved. That’s not traceability.

5) KDEs in FSMA 204: how CTEs drive what you capture

FSMA 204 organizes KDE capture by event type (CTEs). That matters because the KDE set changes slightly depending on the event: receiving emphasizes ship-from and supplier lot capture; shipping emphasizes ship-to and shipment identifiers; transformation emphasizes input-to-output linkage and quantity reconciliation.

The operational takeaway is simple: KDEs must be captured at the point where the event happens. Your “CTE map” is your workflow map. If you don’t know where CTEs occur in your plant, you can’t reliably capture KDEs.

This is why many companies implement KDE programs by building three core templates: receiving, transformation, and shipping, plus a controlled exception path.

6) Receiving KDEs: starting one-step-back correctly

Receiving KDEs are your “one step back” proof. The critical items to capture at receipt are:

• ship-from/supplier identity and location,
• supplier lot identity (and internal lot mapping),
• product identity (item/SKU),
• quantity received and UOM,
• receipt time/location,
• disposition (quarantine/hold/release) and acceptance evidence links (CoA/inspection where required).

Most KDE gaps start here: typed supplier lots, missing CoAs, mixed pallets recorded as one lot, and “put-away before disposition.” If you fix receiving capture discipline, downstream genealogy becomes dramatically cleaner.

7) Transformation KDEs: input→output linkage and mass balance

Transformation KDEs are where traceability becomes internal genealogy. The transformation record must link:

• input lot list (which lots were consumed),
• output lot list (which lots were created),
• quantities consumed and produced (with scrap/rework/losses),
• event time/location and run/batch context.

Transformation is the most common dead-end in trace investigations because many plants record “we made batch X” but not “batch X consumed these specific lots.” If a supplier lot is implicated, the question is: which finished lots contain it? That answer is only possible if transformation KDEs are complete.

Transformation records must also reconcile quantities via mass balance. If you can’t reconcile, auditors interpret it as missing trace data (“product went somewhere”).

8) Shipping KDEs: one-step-forward proof and ship confirm truth

Shipping KDEs are the “one step forward” proof. At ship confirm, you must capture:

• ship-to trading partner identity,
• shipment identifiers (order ID, BOL, ASN where used),
• lot identity shipped (TLC/lot codes),
• quantities shipped by lot/item,
• ship time/location and handover evidence (manifest/seal/signature where applicable).

Shipping is where traceability is most often bypassed because the dock is under pressure. That’s why “ship confirm must be lot-linked” is the highest-leverage control in most KDE programs. If you ship without lot identity, your forward trace is slow and broad.

9) Aggregation and mixed pallets: preserving identity without slowing the dock

Real warehouses build mixed pallets and split cases. Identity preservation requires a strategy:

• Case-level identity: use GS1-128 and scan cases where mixed pallets are common.
• Pallet-level identity: use SSCC and maintain pallet content lists; ship scans SSCC, not every case.
• Rebuild controls: if pallet content changes, rebuild the SSCC content list under control (no “silent changes”).

If mixed pallets are handled informally, shipping KDEs may record the wrong lot scope, creating under- or over-notification risk in recalls.

10) Data quality rules: validation, controlled exceptions, and audit trails

KDE programs fail when data is easy to enter incorrectly. Data quality rules must be built into workflows:

• Validation: lot format checks, expected context checks, UOM normalization.
• Controlled exceptions: scan failures and substitutions must use structured exception tickets with verification.
• Audit trails: edits require reason-for-change; original values preserved (see audit trail).
• Status gating: hold/release must block shipping and consumption of ineligible lots.

The principle is simple: if the system lets users proceed without completing KDEs, users will proceed. You prevent gaps by making completeness a requirement, not a preference.

11) Units, quantities, and catch weight: the “math must reconcile” rule

Quantities are KDEs because “who received it” isn’t enough. In recalls, you must know how much is affected. Quantity capture must be consistent:

• use standardized UOMs and conversions (avoid “cases sometimes, pounds sometimes”),
• capture actual shipped quantities, not ordered quantities,
• record discrepancies and their reasons (short picks, damages, substitutions),
• capture catch weight where applicable, and link variable weights to lot identity,
• reconcile via mass balance across transformations and shipments.

If quantities don’t reconcile, your dataset looks incomplete. Auditors interpret that as missing records, and investigations become broad.

12) EPCIS alignment: turning KDE capture into exchange-ready events

EPCIS is a common standard for representing event-based traceability. KDE capture aligns naturally with EPCIS because EPCIS events are essentially “KDEs in a standardized envelope.” When your KDE capture is disciplined:

• receiving becomes an EPCIS object event (event time, location, identifiers, business transaction references),
• shipping becomes an EPCIS object event (ship-to context via business transactions, SSCC/case IDs),
• transformation becomes an EPCIS transformation event (input identifiers → output identifiers with quantities).

EPCIS does not fix weak capture. It makes strong capture exchangeable and machine-readable.

13) 24-hour response: how KDE design determines retrieval speed

The practical test of KDE readiness is retrieval speed. If a regulator asks for a dataset, you must be able to produce it quickly (often aligned to a 24-hour record response expectation). Retrieval speed depends on:

• lot identity being consistent across events,
• event records being indexed by lot/time/trading partner,
• transformations being explicitly linked (no dead ends),
• shipping records being lot-linked (no SKU-only shipments),
• exports being standardized (CSV/EPCIS) rather than manual stitching.

If you need translation spreadsheets to connect events, you will be slow and error-prone under pressure.

14) Practical templates: minimum viable forms for receive/transform/ship

If you need a “minimum viable” KDE form set, keep it brutally simple:

These templates map directly to the “who/what/which/how much/when/where” categories and are compatible with event-based exports.

15) Controls that prevent gaps: hard gates and escalation paths

Templates don’t prevent gaps. Gates do. The highest-impact KDE controls:

• Receive gate: receipt cannot close without supplier lot identity and disposition.
• Transform gate: batch cannot close without input lot list and output lot assignment.
• Ship gate: shipment cannot confirm without lot/SSCC identity capture.
• Hold gate: ineligible lots cannot ship or be consumed—period.
• Exception discipline: any manual entry requires verification and reason-for-change; trend exceptions as KPIs.

If you want “without gaps,” you need at least these five gates.

16) Testing KDE readiness: mock recalls and dead-end drills

The only honest way to prove KDE readiness is to test it. Run:

• Random-lot mock recall: pick a finished lot and produce the receive/transform/ship dataset quickly.
• Supplier-lot trace: start from a supplier lot and list all finished lots affected (transformation proof).
• Forward trace drill: pick a lot and list all customers/shipments that received it with quantities.
• Mass balance drill: reconcile produced/shipped/on-hand/scrap for the selected scope.

Any dead end means a KDE gap exists. Fix the workflow, then retest. This is how you actually mature.

17) KPIs: measuring KDE completeness and drift

Measure the system so drift is detected early:

When exception rates rise, it’s not a reporting problem. It’s a workflow problem—printers, scanners, staging discipline, supplier labeling, or training.

18) Failure patterns: how KDE programs “exist” but don’t work

• After-the-fact entry. KDEs “filled in later” to pass audits; timelines don’t match reality.
• Document substitution. POs/BOLs provided without lot-linked event data.
• Transformation blind spot. Inputs not linked to outputs; internal genealogy is a guess.
• Shipping by SKU. Lots not captured at ship confirm; forward trace becomes broad.
• Manual entry normalized. Typing becomes routine; error rates climb.
• Mixed pallet shortcuts. Multiple lots shipped but recorded as one lot.
• Holds not enforced. Ineligible lots can move and ship, making records a confession.

The fix is not “more paperwork.” The fix is event-time capture, scan-first workflows, hard gates, and controlled exceptions with audit trails.

19) How this maps to V5 by SG Systems Global

V5 supports KDE discipline by treating KDEs as workflow outputs rather than manual forms:

• scan-driven receiving captures supplier lots, quantities, and disposition gating,
• transformation records link input lots to output lots with reconciling quantities,
• scan-driven shipping captures lot/SSCC identity at load with ship-to linkage and document outputs,
• hold/release gates prevent shipping and consumption of ineligible lots,
• exception workflows capture scan failures and substitutions with approvals and audit trails,
• exports support rapid dataset response and EPCIS-ready event data where needed.

In practical terms, V5 turns KDE capture into the “default path” of doing the work, so you don’t have to ask people to remember to capture it later.

20) Extended FAQ

Q1. Are KDEs only for FSMA 204 foods?
KDEs are a general traceability concept, but FSMA 204 makes them explicit for CTEs and FTL foods. Even outside FSMA 204 scope, KDE discipline improves recall readiness and audit defensibility.

Q2. What’s the single most important KDE?
Lot identity (TLC/lot code). If lot identity is missing or inconsistent, your dataset is broken regardless of how many other fields you have.

Q3. Do we need EPCIS to comply?
Not necessarily. EPCIS is a common exchange format, but compliance depends on capturing and producing the required KDE dataset quickly and consistently. EPCIS is helpful when trading partners require standardized exchange.

Q4. How do we handle scan failures without creating gaps?
Use controlled exceptions: manual entry with second-person verification, reason code, and audit trail. Track scan failures as a KPI and fix root causes (label print quality, scanner hygiene, supplier labels).

Q5. How do we prove KDE readiness?
Run random-lot mock recalls and require a complete receive/transform/ship dataset with reconciled quantities. If you can export it quickly without translation spreadsheets, your KDE program is real.

Related Reading (keep it practical)
KDE discipline becomes operational when you build scan-driven receiving, lot-linked transformations, and scan-driven shipping with hard gates that prevent closing events without lot identity. Then prove it continuously with mock recalls and fast dataset exports aligned to 24-hour response expectations.