Food Traceability: Lot Tracking and the Mock Recall Test

Monday morning, in the office of a 40-person cheese plant, the phone rings. It is the quality team at a supermarket chain: a customer has reported an off smell in a pack bought two weeks ago. Their question is four words long. Which lot is it?

The production manager walks down to the warehouse. The labels have dates and lot numbers, so far so good. Then the second question arrives, and that is where it falls apart: which raw milk tank went into that lot, what other lots came out of that same tank, and which distributors received them? The answer lives across three spreadsheets, one notebook, and the memory of two people.

Food traceability is entirely about how many minutes that question takes to answer. It determines whether a problem costs you one lot or your whole brand. We looked at making production data useful in our piece on scrap rate; this one looks at the same data from the compliance side.

What does traceability actually ask you to prove?

At its core it is a two-directional question: can you show where every input came from and where every output went? Regulators around the world word this differently, but the mechanism is the same everywhere, and what an auditor tests is not the brand of your software. It is whether your records agree with each other.

In practice the chain has three links. Receiving: who supplied it, when, which lot, with which certificate of analysis. Production: which input lot went into which production lot, and how much came out. Shipping: which lot went to which customer, on what date, in what quantity. If one link is missing, you do not have a chain. You have paperwork.

In smaller operations the link that breaks is almost always the middle one. Receiving gets recorded because an invoice arrives anyway. Shipping gets recorded because someone issues a delivery note. The production step in between is the one waved off with "we know that already." When something goes wrong, knowing is not the requirement. Showing is.

How should you number a lot?

Labeling rules require lot information and generally leave the format to you. What matters is that the number is consistent and never repeats. The most common mistake is treating the production date as the lot number.

Here is why the date alone fails. If you ran two different raw material tanks on the same day and the only distinguishing marker on the label is the date, the entire day becomes a single undivided mass. Even when the problem came from one tank, what you have to pull is everything you made that day. Adding a tank, shift or line code to the number draws that boundary up front, for free.

A pattern that works: date, line or tank code, sequence number. Something like 260817-T2-03 is short enough for an operator to write on a sheet by hand, and specific enough to answer three separate questions on its own.

Once you move to cases and pallets, GS1 standards take over. The GTIN identifies the product at retail, while a logistics label such as GS1-128 can carry the lot number, expiry date and quantity together on the outer case. If you supply supermarket chains, this step stops being optional fairly quickly.

How wide does a recall get?

Wider than most producers expect, and the width is set by your own lot definition rather than by the regulator. This is the part worth internalizing: the scope of a withdrawal is a function of how precisely you can point at the affected product.

If your lot definition is "August 17 production," everything you made that day is in scope. If it is "August 17, tank 2, lot 3," the scope is a single vat. The difference is not a software purchase. It is a numbering decision.

In many markets, food safety authorities publish enforcement information about affected products, and the unit of publication is typically the lot. That means a narrow lot definition limits not only the physical recall but also the reputational surface area. A plant that can name one vat and a plant that can only name one day are treated very differently, both by the authority and by the retailer deciding whether your product goes back on the shelf.

How fast do you have to report a problem?

Requirements vary by market, and the wording is usually closer to "without delay" than to a fixed number of hours. In practice, read that as the same day. But the deciding factor is not the deadline. It is whether you know enough to make a useful report.

Consider the difference. Going to a regulator with "there is a problem but I do not know which lot" versus "this lot, this date, this quantity, at these three distributors" is the difference between a process that runs for a week and one that closes in a day. This is where traceability pays for itself most visibly: response time under pressure.

Is a spreadsheet enough?

At low volume, paired with a consistent lot number, a spreadsheet beats nothing by a wide margin. Worth saying plainly, because "you cannot have traceability without software" circulates a little too freely in this industry. But spreadsheets have three limits, and all three surface at exactly the wrong moment.

• They do not cross-query. "Which forty lots did tank 137 go into, and which eleven customers received those lots" means merging three files by hand.
• They multiply. One copy on a desktop, one in a chat thread, one on a USB stick, and during an audit nobody can say which is authoritative.
• They can be edited retroactively. You cannot demonstrate record integrity, which makes even a well-meaning correction look suspicious.

There is also a floor-level reality: the operator on shift does not open a spreadsheet. They write on paper, and someone transcribes it in the evening. Errors and delays accumulate precisely at that transcription step.

Where does AI genuinely help here?

Its biggest contribution is in the least glamorous place: data entry. Traceability systems fail because nobody enters the records, not because the technology is inadequate. Document processing can pull the date, lot, quantity and supplier fields out of a photographed delivery note, certificate of analysis or supplier document and write them into the system. The gain there is unambiguous.

The second real benefit is query speed. Answering "where did this input lot go" in minutes is, honestly, a database job rather than an AI one. What a language model adds is the ability to ask in plain words. We make that distinction deliberately, because a large share of what gets sold as "AI-powered traceability" is a well-built database, and you should not pay a premium for the label.

Third is consistency checking: input quantity that cannot be reconciled with output, the same lot number appearing on two products, a missing record in a sequence. Rule-based checks catch most of this.

Two more areas work but require hardware. A camera at the end of the line can verify that the expiry date was printed, is legible, and that the right label went onto the right product. Temperature sensors in storage and vehicles keep a continuous cold chain log. In both cases the value comes from producing continuous, untampered records.

Now the overclaimed part. "AI predicts shelf life" has neither technical nor regulatory standing without microbiological validation; a model can produce a supporting signal at best. "AI makes you audit-ready" is the same kind of claim, since what an audit examines is records and consistency. We applied the same standard to production tracking in our piece on the factory floor.

A mock recall in a 40-person dairy

Back to the cheese plant, with two scenarios side by side. The plant processes about six tons of milk a day, has two tanks, and supplies eleven distributors across three regions.

As things stand: the lot number is just the production date and records sit in three spreadsheets. Because nobody can tell which tank the problem came from, the entire day's output is suspect. Distributors are notified, collection begins, shelf space empties. Response time is two to three days, and the quantity pulled is a full day of production.

With the system in place: the lot number carries a tank code, and receiving and shipping records live in one place. The suspect tank is identified, the lots from that tank are listed, and the four distributors who received them are found. Response time is twenty minutes, the quantity pulled is a quarter of a day's output, and seven distributors keep their shelves intact.

The investment that creates that gap is not an AI project. It is a numbering decision, a single place to keep records, and making entry easy for the operator. AI makes the third one cheaper. It does not make the first two for you.

What does an auditor actually look at?

There is no magic checklist. The work is cross-referencing. An auditor takes a shipping record, asks for the matching production record, and follows it back to receiving. If quantities and dates line up across those three points, the system works. If they do not, your software vendor's logo will not save it.

Which is why keeping records consistent is cheaper than running a separate "audit preparation" exercise. Three inconsistencies come up repeatedly: input volume that cannot be reconciled with output through any plausible loss figure, the same lot number reused across products, and a set of records that were all evidently filled in afterwards in one sitting. The last one raises the integrity question even when the intent was simply to tidy up.

Industry guidance commonly suggests running a mock recall quarterly and treating anything beyond a few hours as a system that needs work. Whatever threshold you pick, the useful part is doing it on a schedule rather than discovering your response time during an actual incident.

What not to do

• Using the production date as the lot number. If more than one tank, line or shift runs in a day, that number will not protect you.
• Tying record discipline to one person. When they take leave, the system takes leave.
• Comparing software quotes without asking for a module breakdown. Traceability and food safety records are frequently a separate line item.
• Applying recall cost figures you found online to your own budget. The million-dollar averages that circulate come from old surveys of large multinational brands and have nothing to do with a thirty-person plant.

Questions to ask a software vendor

We could not find reliable published pricing for traceability software, because nearly everyone in this space quotes on request. So instead of numbers, here are the questions that make quotes comparable:

• Are traceability and food safety records in the standard package, or a separate module? This item shows up late in most quotes.
• Is licensing per user or per site? If three operators enter records per shift, the difference is large.
• Is migrating your existing spreadsheet history included?
• What is the annual maintenance and upgrade fee as a percentage of the license?
• Where is the data held, and in what format can you export the raw records when the contract ends?

So what should you do?

• Review your lot number format this week. If it is only a date, add a tank, line or shift code. Zero cost, largest single effect.
• Run a mock recall. Pick a random shipping record and trace it back to the input lot. Time it. That number is your actual position.
• Bring the three links into one place: receiving, production, shipping. Decide where records live before you choose software.
• Make document entry easy. A flow that reads delivery notes and certificates from a photo holds up better than one relying on human diligence.
• If you supply retail chains, do not defer GS1 numbering and case labels. Case-level lot data is what narrows a recall.

If you forget everything else here, run the drill. Stopwatch in hand, start at a shipping record and work back to the raw material lot. The number you get will tell you more honestly where you stand than any vendor demo.