Traceability is not proven by the presence of records. It is proven by the speed, accuracy and confidence with which those records can answer a difficult question.
That question might come from a customer complaint. It might come from a supplier warning that one ingredient batch could be affected. It might come from an internal quality failure. It might come from an auditor asking for a traceability exercise. In the worst case, it may come from a food safety incident requiring withdrawal or recall. Whatever the source, the pressure changes the nature of the task.
On a calm Tuesday afternoon, almost any business can say it has traceability. Under pressure, the gaps become more visible. The person who “knows where that sheet is” is not available. The spreadsheet has two versions. The batch code on the customer photograph is smudged. The intake record is filed by supplier rather than date. The rework log sits in a different folder. The dispatch note gives customer order numbers but not the batch split. The technical manager is trying to join the story while the phone keeps ringing.
What the Prove stage tests
The “Prove” stage is where a food production business tests whether traceability works when it matters. This is not about frightening people. It is about replacing assumption with evidence.
Building a realistic scenario
A useful proof test begins with a realistic scenario. For example: a supplier contacts you to say that one batch of sesame seed may have been contaminated. You received two deliveries that week. One supplier lot may have gone into three finished products. Some stock remains in the building. Some has been dispatched to two customers. A small quantity was used as rework the next day. Can you prove what is affected and what is not?
That last phrase is crucial: what is affected and what is not. Poor traceability widens the circle of uncertainty. Good traceability narrows it. A producer that cannot distinguish affected from unaffected product may have to withdraw more stock than necessary, disappoint more customers than necessary and create more waste than necessary. Food safety must always come first, but imprecise records make safe decisions more expensive.
Backwards and forwards
The proof test should work backwards and forwards. Backwards means starting with a finished product batch and tracing its ingredients, supplier lots, production checks and relevant controls. Forwards means starting with a raw material or packaging lot and identifying every finished product, customer and remaining stock location affected. In food production, both directions matter. A business that can trace backwards but not forwards may understand what happened, but not who needs to be told. A business that can trace forwards but not backwards may know where product went, but not why it is affected.
Begin the test with one trigger. Do not make it too easy. Choose a material used in more than one product, a production run that involved a line change, or a batch that was split across customers. Include rework if rework is part of the normal process. Include packaging if packaging carries legal or customer-critical information. Include a product that went partly to stock and partly to dispatch. The scenario should be challenging enough to reveal reality, not so artificial that it becomes a theatre performance.
Measuring what happens
Then measure what happens. How long does it take to identify the supplier lot? How long to find the intake record? How long to identify all production batches using that lot? How long to find dispatch destinations? How long to reconcile quantities? How long to gather the evidence into a coherent pack? Where does the team hesitate? Where do they ask for one particular person? Where do they open a spreadsheet with a name like “final-final-updated”? Where do they find records but not trust them?
The quantity reconciliation is often where confidence weakens. Traceability is not just a chain of names and codes. It is also a mass balance. If ten cases came in, how many were used, rejected, wasted, retained, reworked, left in stock or dispatched? The answer does not always need to be mathematically elegant, but it should be credible and supported by records. When the quantities do not make sense, the traceability story feels thin.
Evidence quality matters too. A handwritten form may be acceptable, but is it legible? Is it signed? Is it dated? Has it been altered? If altered, is the change controlled? Does the form identify the product and batch clearly? Can it be matched to the production record without interpretation? A record that needs a long verbal explanation may still be useful internally, but it is less persuasive under external scrutiny.
Complaints and mock recalls
Complaints provide a slightly different proof test. A customer may report a foreign body, wrong label, short shelf life, off flavour, damaged packaging or suspected allergen issue. The business needs to link the complaint to a batch, then examine production conditions, ingredient lots, line checks, metal detection records, label verification, cleaning records where relevant, retained samples and dispatch information. Strong traceability allows the business to respond in a measured way. Weak traceability leads to hedging, delay and unease.
Mock recalls are particularly valuable because they reveal the behaviour of the system, not just the existence of the documents. A good mock recall should be timed, documented and reviewed. It should identify what went well, what slowed the team down, what was missing, what was duplicated, and what needs to change. The result should not be a vague statement that “the exercise was successful”. It should produce actions with owners and deadlines.
For owner-managers, this can feel like one more demand in an already crowded week. But a proof test is one of the most commercially sensible uses of management time. It shows whether the business can protect its customers, its brand and its cash position in a difficult moment. It also gives confidence before investing in software. If the current process cannot pass a basic proof test, the business knows where digital support is genuinely needed. If it passes but takes too long, the business can target speed. If it fails because records are inconsistent, standardisation comes first.
The proof test also improves conversations with customers. A customer asking about traceability does not merely want to hear that you have a system. They want confidence that the system works. Being able to describe a recent mock recall, explain what was tested and show improvements made is far more persuasive than saying the forms are filed correctly.
Treat it as a rehearsal, not an exam
There is an important cultural point here. In a well-run business, a traceability test should not be treated as an exam designed to embarrass the team. It should be treated as a rehearsal. Fire drills are not signs that a building expects to burn down. They are signs that the people inside take preparation seriously. A mock recall or complaint trace is the same principle applied to food production.
When the test reveals weaknesses, respond proportionately. If a batch code is difficult to read, improve the print or label control. If rework records are slow to find, redesign the rework log. If dispatch cannot identify batch splits, change the dispatch process. If two spreadsheets disagree, retire one. If the team relies on one person, document the knowledge and train others. If quantity reconciliation is weak, examine how units are recorded at intake, production and dispatch.
The goal is not perfection on paper. The goal is reliable evidence in practice.
Where digital systems fit
Digital systems can help enormously at this stage, but only if the business knows what problem it is solving. A barcode scan can reduce typing error. A stock system can show batch locations. A production module can link ingredients to finished product. A document system can hold supplier certificates. A recall report can save hours. But none of these features matter if the underlying batch journey is not mapped and the basic data is not standardised.
The best question before any digital purchase is therefore not, “Does this system do traceability?” Most systems will say yes. The better question is, “Can this system help us prove the answers we need, using the way our factory actually works?”
Records versus control
Traceability should be testable. It should not rely on optimism, memory or heroic effort. If an ingredient batch is questioned, the business should know how to identify affected products, locate remaining stock, identify customers, reconcile quantities and gather evidence.
That is the difference between having records and having control.
Manager’s pain point
“I think we could trace it, but I would not want to test it when everyone is under pressure.”
AI prompt to try
Design a mock recall exercise for a small UK food production business. Include a realistic scenario involving one raw material batch used in several finished products. List the records to collect, the questions to answer, the timings to measure, and a simple scoring system to identify weaknesses in traceability, quantity reconciliation and evidence quality.Why this helps
This prompt turns traceability into a measurable capability. It helps managers test the current system before a real complaint, withdrawal or recall forces the issue.
