Whether your system could meet a real incident, examined at the level of coding, record linkage and mass balance capability.
A traceability system assessment examines whether a traceability system is capable of doing what a real incident would demand of it. It covers lot coding granularity, how records link between steps, whether mass balance can be reconciled at all, and where the chain depends on knowledge held by individuals. Where a mock recall tests whether the system works today, this establishes whether it could work under pressure.
The decision that governs everything is coding granularity, and it is normally made for operational convenience long before anyone considers an incident. It sets the scope of every future recall in advance. A day level code means a recall covers a day of production, however narrow the actual problem turns out to be.
A design level review of coding, linkage, quantities and handovers, ending in a redesign recommendation with the recall scope each option would deliver. Delivered remotely, quoted on scope.
This single design choice sets the scope of every recall you will ever run, and it is usually made before anyone thinks about incidents.
| Granularity | What it is | Recall scope | Operating cost |
|---|---|---|---|
| Batch level | A code identifying a discrete production batch. | A recall is confined to the batch affected. | Requires disciplined lot changes and more coding effort. |
| Shift level | A code identifying a production shift. | Simpler to operate, fewer code changes. | Any recall widens to a whole shift of production. |
| Day level | A date code covering a day's production. | Simplest to run, minimal changes on the line. | A recall covers everything made that day, whatever the cause. |
| No effective lot identity | Product identified only by product code or delivery date. | None. | A recall cannot be scoped, so it extends to all stock and all customers. |
Eight components, each examined for whether it would hold under the pressure of a real incident.
How lots are defined, when a new code starts, and whether the granularity supports the recall scope you would want.
Whether every incoming material carries a recorded lot identity that survives into production.
Whether each step's record links to the step before and after it, or whether links depend on inference.
Whether reintroduced material carries lot identity into the batch that receives it.
Whether the system captures the quantities needed to reconcile input against output at all.
Points where product moves between systems, shifts, sites or third parties, and whether the chain survives them.
Whether the finished lot is linked to the customers and quantities it went to.
Whether records are held for the required period and can be found when a trace is running.
Eight faults built into systems, and not caused by operating them badly. None of them can be fixed by practising the exercise.
A day code adopted because it is easy to run on the line. It works perfectly until an incident, at which point every recall covers a full day of production regardless of the actual cause.
A chain held together by assuming which material was used, because the record does not say. It reconstructs under calm conditions and collapses under time pressure.
A system recording what was used without recording how much. Mass balance is impossible by design, and no amount of exercise practice will produce it.
Reintroduced material recorded on a separate sheet, or not at all. The link between originating batch and receiving batch is missing at the point it matters most.
Two record sets either side of a boundary, using different identifiers. Both are complete, and nothing joins them.
A chain that works because a long serving employee knows how things run. It is a real capability and it is not a system, and it leaves when they do.
Some steps in a system and some on paper, with no bridge between them. Frequently worse than either approach applied consistently.
Records disposed of while product they cover is still on the market. The trace cannot be run because the evidence is gone.
Options are presented with what each delivers, so the decision on recall scope against operating cost stays with you.
| Element | What it covers |
|---|---|
| System map | Every step from intake to dispatch, with the record supporting each and the links between them. |
| Granularity assessment | What your current coding delivers, and what recall scope it would produce. |
| Link analysis | Where the chain is documented and where it depends on inference or on individuals. |
| Mass balance capability | Whether the quantities needed for reconciliation are captured, and where they are missing. |
| Handover review | Every boundary crossing, with the identifier carrying across it or the gap identified. |
| Requirement gap | The position against your standard and against the food law of your markets. |
| Redesign recommendation | What to change, in what order, with the recall scope each change would deliver. |
| Implementation sequence | Practical ordering, since coding changes ripple through labelling, systems and training. |
Manufacturers, processors, packers, and storage and distribution operations. It suits businesses whose exercises keep revealing the same problem, and any operation about to change system, coding or site structure.
A mock recall failed and the system itself looks like the cause.
Mass balance cannot be reconciled no matter how the exercise is run.
Your lot coding would make any recall far wider than the problem.
Product moves between sites or through a third party provider.
Rework is used and nobody can trace where it ended up.
You are moving from paper to a digital system and need the design settled first.
Traceability depends on one person knowing how things work.
A customer or a new market has imposed tighter traceability requirements.
Every step from intake to dispatch is documented, with the record supporting each and the link to the next.
How lots are defined is established, along with the recall scope your current coding would produce.
Each link is checked for whether it is documented or inferred, and where it depends on individual knowledge.
Whether the data needed for mass balance is captured is established, since reconciliation is impossible without it.
Every boundary between systems, shifts, sites and third parties is examined for a carrying identifier.
Options are set out with the recall scope each delivers, and an implementation sequence is provided.
Implementing the system, selecting software or configuring it. The assessment settles the design, and implementation is carried out by you or your provider.
Software vendor recommendations. No commission or referral arrangement exists with any supplier, so the assessment stays on the design question.
Running the exercise itself, which is a mock recall and is quoted separately.
Every assessment is quoted against its own scope. A single site with a short chain and a multi site operation with third party storage are very different pieces of work. These factors set the price.
These are the primary sources this work is built on. Where a market you sell into has its own requirement, that takes precedence and we assess against it.
It examines whether a traceability system is capable of meeting what a real incident would demand. It covers lot coding granularity, how records link between steps, whether mass balance can be reconciled at all, and where the chain depends on individuals. It assesses design, as distinct from testing performance on a given day.
A mock recall tests whether the system works, using a live lot under timed conditions. This assessment establishes whether it could work, by examining the design underneath it. Businesses usually run the exercise first, and commission the assessment when the exercise reveals the system itself is the problem.
Granularity is how finely lots are defined. It matters because it sets the scope of any recall before anything goes wrong. A day level code means every recall covers a day of production, whatever the actual cause. Batch level coding confines a recall to the product genuinely affected.
It depends on the cost of a wide recall against the cost of running finer coding. A high value product with wide distribution justifies batch level. A low value product in a short chain may not. The assessment sets out what each option would deliver so the decision is informed.
Usually because the quantities were never captured. A system can record which materials were used without recording how much, which makes reconciliation impossible by design. No amount of practice produces mass balance from records that do not contain the numbers.
At handovers and at rework. Handovers between systems, shifts, sites or third parties frequently have complete records on both sides with nothing joining them. Rework breaks the chain when reintroduced material carries no lot identity into the batch receiving it.
Not necessarily. Well designed paper systems trace reliably, and badly implemented software traces poorly. What matters is whether lot identity is captured at every step, whether records link, and whether quantities exist. Software makes retrieval and trending far easier once those hold.
Long enough to cover product still on the market, which means at least the shelf life plus a margin, and longer where legislation or a standard specifies. Records disposed of while covered product is still out there make a trace impossible.
A critical tracking event is a point in the chain where data has to be captured for traceability to hold, such as receiving, transformation or shipping. Key data elements are the specific pieces of information recorded at those points. Both concepts are increasingly used in traceability regulation.
Yes, and multi site chains are where the assessment earns most. Boundaries between sites, and between you and third party storage or distribution, are exactly where identifiers stop carrying across.
The recommendation sets out options with what each delivers, so the decision on recall scope against operating cost is yours. Where a change is genuinely necessary for legal compliance, that is separated from changes that are improvements.
A system map from intake to dispatch, a granularity assessment showing what recall scope your coding would produce, link analysis, mass balance capability, a handover review, the gap against your standard and your markets' food law, a redesign recommendation and an implementation sequence.
Confi Food assigns work by subject. HACCP, labelling, certification standards, regulatory compliance, supplier assurance and monitoring are separate disciplines, and each piece goes to someone who works in that area. Every deliverable is reviewed internally by a second specialist before it reaches you.
Our technical positions are built from primary sources, meaning the legislation, the competent authority, Codex Alimentarius, the certification scheme owner or the relevant standards body. We set out how that works in our technical review and editorial policy, and what happens at each stage of an engagement in how Confi Food works.
A timed traceability exercise in both directions, testing whether you can account for product inside the window your standard demands.
Read about Traceability and Mock Recall Assessment →A review of the records you keep against the records your standard and your regulator expect to see, including retention and legibility.
Read about Recordkeeping System Review →Certificated course covering tracking events, key data elements and traceability plans.
View Certified FSMA Food Traceability Rule Specialist →Expert FSMA consulting worldwide. Preventive Controls for Human Food, HARPC food safety plans, PCQI support, FSMA 204 traceability and FDA compliance for food businesses.
See FDA FSMA Consulting →Expert ISO 22005 consulting worldwide. Traceability system design and implementation for the feed and food chain, recall readiness, and alignment with FSMA 204, SFCR...
See ISO 22005 Consulting →Expert MSC and ASC Chain of Custody consulting worldwide. Certification readiness, traceability system design, and ongoing compliance for seafood supply chains.
See MSC & ASC Chain of Custody Consulting →Tell us the sites, the chain and how records are kept, and receive a written quote covering the scope, the deliverable and the price.