Twenty-Four Hours and a Glossary
The American food traceability rule is usually summarised as lot codes and twenty-four hours. The sentence nobody quotes asks for something else in those twenty-four hours: your coding systems, your abbreviations, your glossary, and a written account of how your records map onto the ones the rule names. That is a document about your software, and no software ships it.
Most write-ups of this rule stop at two facts: you assign a traceability lot code, and you can be asked for your records within twenty-four hours. Both are true and neither is the part that decides whether a system is any use.
The deciding sentence is in the availability section, and it asks for the records "along with any information needed to understand these records, such as internal or external coding systems, glossaries, abbreviations, and a description of how the records you provide correspond to the information required."
Read that as a software requirement and it is unusual. It is not asking for data. It is asking you to explain your own data model, in writing, to somebody who has never seen it, inside a day.
Eight facts about one delivery
Before the glossary, the substance. For each traceability lot you receive, eight things must be recorded and linked to that lot. We have set them against what a batch in our inventory actually holds, because that is a checkable claim rather than a general one.
| What must be linked to the lot | Where it is here |
|---|---|
| 1. The traceability lot code | A lot number on the batch, with lot tracking switched on per item |
| 2. The quantity and unit of measure | A quantity. The unit is the part we are missing |
| 3. The product description | The item name and description |
| 4. The location of the immediate previous source | The supplier on the batch |
| 5. The location where it was received | The warehouse and location on the event |
| 6. The date received | A received date on the batch, and a timestamp on the event |
| 7. The location of the traceability lot code source | Free text, at best — see below |
| 8. The reference document type and number | A source document type and a reference on every event |
Item seven is the structural one
The traceability lot code source is not your supplier. It is whoever assigned the code — the operation that first packed the commodity or transformed it — and that can sit one or several steps upstream of the business you actually bought from.
A supplier record in our system is a counterparty and points at no other supplier. So the packer whose code you are carrying can be written into a batch's free-form detail and cannot be a party you report across. That is the same shape as the procurement finding published the same day, arriving from a completely different direction — which is usually a sign that the missing thing is a relationship rather than a field.
A lot code travels further up the chain than your purchase order does. Something has to hold the difference, and a text box is not it.
One prohibition we satisfy without trying
Worth flagging, because it is the requirement most systems break. A lot code is assigned at three moments — initially packing a raw commodity, first land-based receiving of a catch, or transforming a food — and the rule then says you must not establish a new lot code when you do anything else, shipping included.
Ours cannot mint a code on a shipment, by construction: a batch is identified by its number against an item, so moving stock between sites attaches events to the existing batch rather than creating another. The trap in a lot of inventory software is a transfer that creates a receiving batch at the destination, which silently breaks the chain in the direction that matters.
The other half of the same clause is one we cannot do at all: transform a food is an event that mints a new code, and this product has no production, recipe or assembly object to hang one on. If your operation only receives, holds and ships, that is irrelevant. If it processes anything, it is the first question to ask.
What we do have, and it is more than a batch number
The part of this that is genuinely built is the event ledger. Every movement of a tracked batch is recorded as an event with a direction, an event type, a quantity, a warehouse and location, the person who did it, the moment it happened, and the document it came from — held as a document type plus a reference, which is exactly the shape item eight asks for.
On top of that there is a recall trace: give it a batch and it returns every event against that batch in order, the locations still holding stock, and the quantity in, out and remaining. A batch also carries a recall status of its own, and the traceability screen counts the batches that are not clear.
And you cannot export any of it
The traceability views — by item, by batch, by serial — are readable on screen and through the developer API, and not one of them has an export. No spreadsheet, no CSV, no PDF, on either surface. Which matters here specifically, because in an outbreak or recall the rule asks for the receiving-through-shipping information in an electronic sortable spreadsheet, within twenty-four hours, for the foods and date ranges or lot codes named in the request. Our reports elsewhere in the product export to CSV and PDF as a matter of course. These screens were built to be read, and the one thing this obligation needs from them is a file.
The plan is a document, and it has a version history
Separately from the records, there is a traceability plan, and its required contents are worth knowing because three of them are about your systems rather than your food: a description of the procedures you use to keep the records including their format and location; a description of how you identify which of your products are in scope; a description of how you assign lot codes; a named point of contact for questions about the plan and the records; and, if you grow or raise anything covered, a farm map naming each field or growing area with geographic coordinates — or, for aquaculture, each pond, pool, tank or cage.
And when you update it, you keep the previous version for two years. So it is a versioned document with a retention rule of its own, describing where your data lives and who to ring about it. That is a governance artefact, not a report, and it is the reader's to write — although a vendor who cannot tell you the format and location of the records is making it harder than it needs to be.
Two sentences that are unusually kind to cloud software
Both worth quoting, because they resolve a question buyers ask us in almost every industry and rarely get a straight answer to.
First: another entity may establish and maintain the records on your behalf — but you are responsible for ensuring they can be retrieved and provided within twenty-four hours. So using a system like ours is expressly contemplated, and the duty does not transfer with the data. Second: offsite storage is permitted where records can be retrieved within the same window, and electronic records count as onsite if they are accessible from an onsite location. A hosted system is not offsite storage in the sense the rule is worried about.
Those two sentences are the answer to "can we use cloud software for this", and the honest follow-up is the one nobody enjoys: the retrieval promise is yours to make, so the question to ask a vendor is not whether they are compliant but how fast you can get the file out, and whether anybody can read it when it arrives.
Which brings it back to the glossary
An investigator receiving your records has to be able to line them up against eight named elements per event. Our event ledger calls things by our names — a direction, an event type, a source document type, a reference. None of those words appears in the rule, and none of the rule's words appears in ours. Both descriptions are correct and somebody has to write the mapping between them.
That mapping is a real deliverable, it is about a specific system, it changes when the system changes, and it is currently produced by nobody. It is the most useful thing a vendor could hand a customer in this area and it is not a feature anyone advertises, which is roughly the definition of a gap worth naming.
What AWRA OpsHub does today
- Lot and batch numbers on stock, with lot, serial and expiry tracking switched on per item, and a rotation policy that can prefer the earliest expiry.
- A supplier, a purchase order and a received date held on the batch itself, so where a lot came from and when is a field rather than a reconstruction.
- An event for every movement of a tracked batch, carrying the direction, the event type, the quantity, the warehouse and location, the person, the moment, and the source document as a type plus a reference.
- A recall trace on any batch, returning its events in order, the locations still holding stock, and the quantities in, out and remaining.
- A recall status on the batch, with the traceability screen counting the ones that are no longer clear.
- The same traceability views on the developer API, by item, by batch and by serial, so a system of yours can read them without a person in the loop.
- Documents attached to records through a vault with a classification and every read logged, which is where a plan or a certificate can live.
More we can add to your workspace
- An export from the traceability views — a sortable spreadsheet of events for a set of lots and a date range, produced on demand, which is the form this rule asks for in an outbreak.
- A unit of measure alongside the quantity, so a lot reads as cases, containers or pounds rather than as a bare number.
- The traceability lot code source as a party, recordable where the operation that assigned the code sits upstream of the supplier you bought from.
- A transformation event that mints a new lot code and links it to the lots consumed, which is what a processing step needs and what a production object would carry.
- A traceability plan as a versioned document in the product, holding the procedures, the point of contact and the previous version, with the two-year retention its own rule requires.
- A field-level correspondence map — our names for things set against the elements a regulator names, exportable with the data, so a file arrives explained rather than merely delivered.
- Geographic coordinates on a growing area, named per field or per container, for the map this plan requires of anyone who grows or raises.
Where we point you to a specialist
- We will not tell you whether this subpart reaches your business. Coverage turns on the Food Traceability List and on a set of exemptions we read no part of, and both are matters your food safety adviser and your counsel own. We will also not print a compliance date on this page: the edition we read carries the date as originally made, that date has since moved, and we would rather send you to the agency for it than have a stale figure on a page somebody plans around.
- We will not describe a batch number as traceability. A lot code with events against it tells you where stock went; it does not tell you whether the code means the same thing at both ends of a supply chain, and the rule is explicit that somebody has to explain the coding system as well as supply it. Where our records need a translation to be understood, we would rather build the translation than let the presence of the data imply it.
The first item is the one to do first and it is small: the events, the fields and the filters all exist, and the remaining step is to write them to a file. The second is a column with reach, because a unit belongs to an item and then appears everywhere the quantity does. The third and the sixth are the interesting pair — a party upstream of your supplier, and a written map from our field names to a regulator's element names — and they are worth scoping together, because the map is only useful once the thing it points at exists. The fourth wants a production object underneath it and is a larger conversation than the rest of the list.
What we can build for the United States on top of the standard product
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point for the United States, not a limit on what AWRA OpsHub can do there. Kenya's eTIMS integration and its maintained payroll engine are in the product because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a jurisdiction on the record, and settings that are actually read, a bank or mobile money feed, a statutory return format, a rule specific to how your operation runs, or a link to a system you already have is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Three builds, and we would decline the fourth
A jurisdiction field on the customer and on the sale — a real field, not a state parsed out of a free-text address line, which is the cheap version and produces confidently wrong returns. Then per-customer tax settings that are read rather than only stored: the exemption flag, the registration number and the override rate all exist on the customer record today and no tax calculation looks at any of them, which is a defect fix rather than a feature. Then the interface a specialist tax service plugs into, so the rate comes from something that does nothing but rates. What we would decline is the fourth build — a US rate table we maintain ourselves. Thousands of jurisdictions with rules that move is not a thing to own as a side line, and we would rather say so in a specification than discover it in year two.
Banks and payments
ACH origination and bank statement feeds wired into the Payments Register, so money in and out reconciles against the documents that authorised it rather than against a spreadsheet.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
A US payroll engine with federal and state withholding, FICA, quarterly and annual returns, state unemployment insurance and multi-state allocation for employees who cross state lines. None of it exists today.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedFour questions, and the fourth is the one nobody asks
When I transfer a tracked lot between sites, does the destination get a new lot number?
What you will probably hear
Usually a pause, then a check.
How to read it
This is the fastest way to find out whether a system understands lot identity or just labels. A new code at the destination breaks the chain in the direction an investigator walks it. Ask them to do the transfer in front of you.
Give me a sortable file of every event for these three lots, for last month.
What you will probably hear
A screen, and an offer to take a screenshot or use the API.
How to read it
A screen is not a file and an API is not a spreadsheet — both are fine answers to a different question. This obligation names the form, so ask for the form. Ours has the events and no export, and we say so.
Can I record who assigned the lot code, if it was not my supplier?
What you will probably hear
A description of a notes field.
How to read it
A notes field means the fact exists and cannot be reported on. Ask whether it is a party in the system. Most inventory systems stop at the counterparty they invoice, which is a commercial boundary rather than a supply-chain one.
What would you send with the data to explain your field names?
What you will probably hear
Documentation, or a data dictionary for the API.
How to read it
The best question here and it usually surprises people. Generic documentation is not a description of how the records you provide correspond to the elements the rule names. If a vendor has never been asked, you are going to be writing it — so find out now rather than during a recall.
The short version
Lot codes and a twenty-four-hour clock are the easy half, and this product does more of that half than we expected: lot numbers per item, a supplier and a received date on the batch, an event for every movement with the source document as a type plus a reference, and a working recall trace behind an API. The hard half is form and explanation. There is no export from those views, which is precisely the form the rule asks for when it matters most, and there is no written map from our names for things to the eight elements the rule names. The first is a small build. The second is the one worth asking every vendor in this space about, because the rule asks for a glossary and nobody sells one.
See inventory traceability
Lot and serial tracking per item, supplier and received date on the batch, an event ledger with the source document behind every movement, and a recall trace on the web and the API.
Explore traceabilityFrequently asked questions
Can your system meet the twenty-four-hour request?
Partly, and the gap is the form rather than the data. The events exist — every movement of a tracked batch carries a direction, a quantity, a warehouse and location, a timestamp, the person and the source document — and a recall trace returns them in order for any batch, on the web and through the API. What the rule asks for in an outbreak is an electronic sortable spreadsheet for the lots and date ranges named in the request, and the traceability views have no export at all. That is the first item in our buildable list and it is a small piece of work.
Does using hosted software satisfy the record-keeping requirement?
The rule is unusually explicit about this in both directions. Another entity may establish and maintain the records on your behalf, and electronic records count as onsite if they are accessible from an onsite location — so hosted software is contemplated rather than merely tolerated. But the responsibility for retrieving and providing the records within twenty-four hours stays with you. So the question to ask a vendor is not whether they are compliant; it is how quickly you can get the file, and whether it arrives explained.
What is the traceability lot code source, and why does it matter?
It is the operation that assigned the lot code — whoever first packed the commodity or transformed it — and it can sit upstream of the business you bought from. The rule asks for its location description, or a reference to it, on every receiving record. In our system a batch holds a supplier, and a supplier record points at no other supplier, so the packer can be written into a batch's free-form detail and cannot be reported across. It is the one item on the list of eight that needs a relationship rather than a column.
Will a transfer between our warehouses create a new lot number?
No, and that is the behaviour the rule requires: a new lot code is assigned only when a commodity is first packed, when a catch is first received on land, or when a food is transformed, and expressly not when you ship. A batch here is identified by its number against an item, so a movement attaches events to the existing batch. The half we cannot do is transformation — there is no production, recipe or assembly object in this product, so a processing step has nothing to mint a new code from.
Which version of the regulation did you read, and when does it apply?
We read the 2024 annual edition of 21 CFR part 1 subpart S from the Government Publishing Office, because the continuously updated eCFR blocks automated requests. We have deliberately not printed a compliance date anywhere on this page: the edition we read carries the date as originally made, that date has since been moved, and a stale date on a page people plan around is worse than no date. Get it from the FDA, and take coverage and the Food Traceability List to your food safety adviser.
