Produce traceability: turning a recall from days into minutes

One-up, one-back is the minimum

Traceability regimes and most retail buyers expect you to know one step back, the grower and block a lot came from, and one step forward, the customers it went to. That is the baseline, not the finish line: every lot needs an unbroken chain from receival, through packing, onto a pallet, and out on a dispatch, with each step recorded as it happens rather than reconstructed afterward.

That requires four kinds of linked records: a receival record tying a grower, block, harvest date, and quantity to an internal lot code; a pack run record tying input lots to the output lot codes that came off the line, including any blending; a pallet or case-build record tying pack output to a shipping unit; and a dispatch record tying that unit to a customer, order, and ship date. Miss any one and the chain has a hole in it, which for recall purposes is the same as having no chain at all.

The real test is whether someone who did not write the records can reconstruct the chain from a single lot code inside the time a real trace request gives you, typically hours.

Lot definition sets the cost of being wrong

A lot is the unit you will have to recall as a whole if anything inside it is implicated, so the size of a lot is really a decision about how much of your business one bad bin or one contaminated wash tank can take down. Define a lot too broadly, by combining a week of receivals from multiple growers into one pack run without keeping the inputs distinguishable, and a single positive test result forces you to treat the entire week as suspect.

Define it too narrowly and you generate more paperwork than the risk justifies, tracking every bin separately when a single grower's single day of harvest through a single pack run is a defensible unit. The right boundary usually follows a natural break in your process: a day's receival from one grower and block, one pack run, one wash-water change, whichever is tightest without becoming unworkable on the floor.

The cost asymmetry is worth putting numbers on. A packhouse shipping 40,000 cartons a week that defines lots by pack run, each covering roughly 8,000 cartons a day, faces an 8,000-carton recall from a contamination signal: painful, but a fifth of the week's volume. Let three days of receivals merge into one undifferentiated lot instead, and the same signal implicates 24,000 cartons, three times the exposure and the notifications, and a harder story for the retail buyer. The pack-run discipline costs nothing extra day to day. The wide lot costs real money exactly once, at the worst moment.

The records a fast trace actually depends on

Answering a trace request within hours rather than days comes down to a short list of records being lot-linked rather than free text: the grower and block for every receival, the harvest and receival dates, the internal lot code assigned at intake, the input-to-output lot mapping for every pack run, the pallet or case build tying pack output to a shippable unit, and the dispatch record linking that unit to a customer, order number, and ship date. Each needs to reference the lot code of the step before it, not describe it in a comment field a person would have to interpret.

The failure mode worth naming is the transformation step. Chains hold up fine through receival and dispatch, single events with an obvious paper trail, and break at packing, where produce from several input lots goes into one run and comes out as cartons carrying a single new code. If the pack run does not record which inputs fed which outputs, the chain has a gap exactly where a trace needs it most, and closing that gap after the fact means interviewing whoever ran the line that day and hoping they remember.

Speed also depends on records being queryable by lot code, not by date range or grower name alone. A trace request names a lot, not a week, so if your system can only answer "what did we ship to customer X in June" and not "which growers and customers touch lot 4471," you are doing the query manually against paper, which is exactly where multi-day trace times come from.

A withdrawal is not a recall

The two terms get used interchangeably on the floor, but they describe different events with different obligations. A withdrawal is action taken on product that has not been distributed to consumers, or that is still fully within your own control: pulling stock from a warehouse, stopping a shipment before it leaves the dock, or holding product that failed an internal check. It is largely an internal, operational matter, though a buyer may still expect notice.

A recall is action on product that has already left your control and reached a customer, distributor, or retail shelf, where it could reach or has reached a consumer. That distinction matters because a recall triggers a wider set of obligations: regulatory notification in most jurisdictions, customer and distributor notification down every branch of the chain the lot touched, and in the more serious classes a public notice. Knowing which one you are dealing with, within the first hour rather than the first day, changes who needs to be on the call and how fast.

The lot chain built through one-up, one-back records is what lets you make that call correctly: you cannot know whether product has already reached a customer without the dispatch records that say where every unit of the affected lot actually went.

Who gets notified, and in what order

Once a lot is confirmed affected, notification follows a rough order rather than a single blast to everyone at once. Internally, the person who can authorize a hold or a recall decision needs to know first, before any external party, because everything downstream depends on that authorization being clear and on the record. Next comes the supplying grower whose block is implicated, both because they need to investigate on their end and because they may hold information you need to bound the affected lot correctly.

External notification then moves outward in the order product actually travelled: distributors and wholesalers who received the lot, followed by the retail or foodservice customers they supplied, each getting enough detail to identify and pull the specific lot rather than a general alert that forces them to guess. Regulatory notification runs in parallel with, not after, the trade notification in most jurisdictions, and the specific triggers and timeframes vary by market, so confirm this against the rules of the destination market rather than assume they match your home market.

The common failure is not skipping a party, it is sequencing badly under pressure: notifying a retail customer before the distributor who holds the inventory has been told, or notifying broadly before the affected lot has been bounded, which forces a second, more embarrassing correction once the real scope is known. A written notification order, agreed before it is needed, removes that decision from the moment nobody wants to be making it under time pressure.

The mock recall is the only real test

A traceability system never tested against a deadline is a theory, not a capability. A mock recall picks a real lot from recent production, gives someone who did not build the records a fixed window, commonly two to four hours depending on your buyer's requirements, and asks them to produce the full chain: every grower block the lot drew from, every pack run it passed through, every pallet it went onto, and every customer it reached, backed by the actual records rather than institutional memory.

The pass criteria are specific, not a general sense that it went fine. The trace has to be complete, with no step filled in by asking someone to recall what happened. It has to be accurate, meaning quantities reconcile: what came in from the grower should account for what went out, with any variance explained rather than shrugged off. And it has to land inside the time limit, because a technically correct trace that takes three days is a fail in every meaningful sense.

Running this quarterly, or at minimum before each major buying season, surfaces the same handful of gaps every time: a pack run that recorded output but not input lots, a pallet build not logged the day it happened, a dispatch record missing a lot reference. Finding those in a drill costs an afternoon. Finding them during an actual recall costs the days you no longer have.

Packaging and labelling carry the lot forward

None of the record-keeping above is worth anything if the physical product cannot be matched back to the lot it belongs to, and that match happens on the label, not in the database. Every carton or case leaving the pack line needs a lot code printed or applied at the point of packing, not added later from memory, and that code needs to match the code used in your internal records rather than a separate customer-facing number that someone has to cross-reference.

This matters most at the two ends of the chain a recall touches. At the receiving end, the code on the carton lets a customer or auditor identify which shipment a suspect unit belongs to just by reading the box. At the other end, it lets a retailer pull the exact affected stock rather than pulling every case of that item as a precaution, more disruptive to them and a worse outcome for you than a narrow, accurate pull. A blended case needs particular care: if a carton holds produce from more than one input lot, the label has to carry all contributing lot codes or the pack-run records have to make the blend fully reconstructable from the single code on the box, because a label that oversimplifies a blend recreates the same gap a missing pack-run record would.