FDA's sortable spreadsheet is a response format—not the traceability system
21 CFR 1.1455 allows distributed original or copied records, requires retrieval and context, and calls for a sortable spreadsheet in specified FDA requests; a flat export does not replace the underlying traceability record.
Editorial figure by Food Traceability Ledger. Source context: Electronic Code of Federal Regulations — 21 CFR Part 1 Subpart S.
The regulation allows distributed source records
The direct answer in 21 CFR 1.1455 is that food-traceability records can be original paper records, electronic records, or true copies, and electronic records can include valid working links. The rule also says all required information does not have to live in one record set. That means a compliant response format is not necessarily the system of record and a single application does not have to create every source event.
A traceability architecture should preserve the responsible person and location, food and form, traceability lot code, critical tracking event, key data elements, source record, creator, timestamp, correction, partner or facility, identifier mappings, retention, and access path. Links and integrations need validation and continuity controls so a later request can still resolve the evidence that existed at the relevant time.
Delegated recordkeeping does not delegate responsibility
Section 1.1455 permits another entity to establish and maintain required records, but keeps responsibility for retrieval and onsite provision within 24 hours with the person subject to the rule. A network, distributor, supplier, service provider, data pool, or software vendor can hold part of the record while the regulated organization still needs tested access, readable context, and a recovery path.
The operating record should identify who creates, controls, corrects, stores, transmits, and retrieves each element; applicable service and data agreements; availability and export commitments; identity and authorization; failure handling; test results; and escalation. A dashboard connection or vendor assurance is not proof that records can be assembled accurately under the stated time boundary.
The sortable spreadsheet is a request output
For certain FDA requests used to address an outbreak, recall, or other public-health threat, Section 1.1455 requires information maintained under Sections 1.1325 through 1.1350 in an electronic sortable spreadsheet, together with information needed to understand it. The rule also states limited exceptions. The spreadsheet is therefore a defined response artifact generated from governed records, not a substitute for event capture, validation, lineage, correction, retention, and partner reconciliation.
Buyers should test a representative FDA request by food, date range, and traceability lot code. The export should preserve required fields, identifiers, event relationships, source context, coding systems, glossaries, abbreviations, missing or disputed values, and the mapping between the spreadsheet and the records. Speed without accurate lineage can produce a fast but misleading response.
The traceability plan is the map to the records
Section 1.1315 requires a traceability plan to describe record-maintenance procedures, including record format and location, and Section 1.1455 points back to that plan when multiple record sets are used. The plan should reflect current practice and retain history as the regulation specifies. A generic architecture diagram that omits partner-held records, manual steps, identifier translation, or fallback procedures does not provide the same operating map.
This analysis does not determine whether a person, facility, food, or activity is covered or exempt; whether records are complete; whether an exception applies; or whether an FDA response is adequate. Organizations need the current rule, applicable FDA materials, their food and operating facts, tested records, and qualified food-safety, traceability, regulatory, operations, technical, and legal judgment.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Food Traceability Ledger will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.