AI food traceability system

AI traceability in the supply chain: where records break

A gap in batch data rarely looks like an error — usually it is a correct document standing behind a different reality. At receiving, raw materials are entered as a single line: item name, weight, supplier.

Inside the machine, however, there are three batches with different expiration dates, and the link between the invoice line and a specific pallet rests on the receiver's memory — even though traceability requirements were established as far back as HACCP.

The next break point is repacking and blending. The batch is split, part goes to another production area, part is mixed with leftovers from the previous batch, and the new accounting unit no longer inherits its parent.

If the identifier is not carried over during repacking, batch traceability breaks here, not at the finished goods warehouse.

The third bottleneck is write-offs and returns. Defects, sanitary cleaning of the line, and returns from the retail chain are documented in separate reports that live outside the main product movement accounting system. Balances in the system and on the shelf diverge, and no one records the moment of divergence.

The cost of the gap shows up in two situations.

During a recall, supply chain control comes down to a choice between targeted sampling that cannot be justified and withdrawal of the entire product line; during an inspection, batch history is assembled manually from paper logs — this takes days.

Below, we look at how AI traceability connects receiving, processing, and shipping events and finds the point where records stopped reconciling.

What changes after implementation: measurable effect in production

The main shift is in batch records: receiving raw materials, movement between workshops, write-off into production, and shipment are tied to a single batch identifier.

Previously, these records lived in different logs, and some batches remained "hanging" — raw materials were written off, but where they went could not be reconstructed.

Now the system does not allow a shift to be closed with an unfilled link, and the share of unclosed batches drops to isolated cases.

Recall speed changes qualitatively. Instead of hours of manual invoice review, a report by identifier is generated in minutes and immediately shows the volume and locations where the product went.

Recall boundaries become precise: only the affected volume is withdrawn, not the entire product line for the period.

Raw material accounting accuracy increases due to write-off by actual usage rather than by norm — scales and scanners in the areas record actual consumption, and discrepancies surface within the shift, not at the end of the month.

Warehouse transparency means visible balances for each batch with its shelf life: the storekeeper sees what to ship first, and expired goods do not accumulate in far corners.

This rests on data discipline. We mark up line operations so that the batch is confirmed with one action, and an unfilled field blocks the next step.

We build identifiers and exchange rules according to the GS1 standard — data is accepted by both suppliers and retail chains, without manual remapping of reference data.

Methods for recording batch movement: comparison of approaches

Before choosing a recording method, it is worth determining what granularity of the chain needs to be reconstructed: a batch in the warehouse, a batch in the mix, or a specific package on the shelf.

This determines where to place control points and how many manual operations will remain in the loop.

In practice, approaches are combined: scanning holds the main loop, weight-based accounting serves as an independent check, and the manual log remains for non-standard operations.

An analytical layer over the events stitches heterogeneous records into a single chain and shows areas where data is missing — instead of demanding perfect discipline across all processing stages at once.

Implementation stages: from process assessment to system handover

Traceability implementation begins not with a model but with the shop floor: until the real batch route is described, AI traceability remains a demonstration on synthetic data.

We carry out the work in stages, and each ends with an artifact that can be verified before moving to the next.

Process assessment and flow diagram

1. Process assessment. We walk through the areas — receiving, warehouse, processing, packaging, shipping — and record where the batch loses its identifier: manual entries in the log, transferring in bulk, topping up from a second batch.

2. Product flow diagram. We build a movement graph: nodes are operations that change the state or batch number, edges are the actual sequence. We agree the diagram with process engineers — it becomes the framework for matching rules.

3. Reference data setup. Item master, suppliers, units of measurement, shelf lives, permitted substitutions. Without a unified reference source, records from weighing, the laboratory, and the warehouse cannot be brought into a single chain.

Pilot, acceptance, and handover

• Model setup and training. We train on historical batches and separately test rare cases: returns, relabeling, batch splitting, and mixing raw materials from different suppliers.

• Line pilot. We launch it in a limited area in parallel with current accounting and see where the system and the operator diverge. We fix discrepancies before handover, not after.

• System acceptance and handover. Test scenarios, batch recall in minutes instead of hours, shift training, a procedure for handling discrepancies, and documentation.

After handover, links between batches are assembled automatically, and the manual log remains for reference.

Documents, diagrams, and procedures that remain with the customer

Documentation is not a project report but a working loop: the shift uses it to operate without us, and the process engineer can retrieve any episode retroactively.

We hand over the set in editable source files, with versions and an update date, so that edits after a process change do not turn into rewriting from scratch.

• Batch movement diagram — the route from raw material receiving to shipping, tied to control points, responsible roles, and areas where a batch is split or merged.
• Control point map — what is read automatically, what the operator enters manually, and at which step identifier loss is possible.
• Discrepancy procedure — batch not found, weight mismatch, duplicate label: who stops the line, within what time the episode is investigated, and how it is closed in the system.
• Shift instructions — one page per role: work order, typical operator errors, and actions when a scanner fails or communication is lost.
• Data access matrix — roles of the operator, process engineer, quality service, and audit; visibility scope; and rights to export history.
• Control point log — record format, retention period, and the rule for reconciling the paper log with system data.
• Backup procedure — frequency, retention depth, and verification that batch history can be restored in full, not in fragments.

Each document is tied to the role that opens it and to the situation in which it is needed. When a process changes, we update the affected sections — the set remains a working tool for the shift, not an archive folder.

Production project: state of accounting before and after

Production: three lines, nine product types, and a batch is formed per shift.

Information about raw materials, mixing, and shipping lived in logs and disparate spreadsheets and was linked manually — the full batch composition from raw material receiving to shipping could be assembled for 43% of batches; the rest were reconstructed from invoices and by interviewing the shift.

What was changed

Receiving, mixing, and packaging received scanning: supplier codes are linked to the internal batch identifier according to GS1 standards, then the traceability system itself aggregates records into a single chain.

The shift only confirms operations, and recalculations and data transfers between spreadsheets have left the process. The rollout started with one line, then the same rule was transferred to the others — without stopping production or rewriting logs retroactively.

What the result was

• Share of batches with complete data — from 43% to 99%.
• Batch search for a retail request or inspection — from 4–6 hours to 20–30 seconds.
• Manual operations per batch — from 11 to 2.

A whole class of errors has disappeared: loss of the link between a batch and the raw material supply, duplicates on re-receipt, and discrepancies in converting raw materials to finished products.

The batch composition report is assembled from the same chain, so it is not prepared separately before an inspection.

How does AI traceability differ from batch accounting?

Batch accounting operates with a discrete unit: a batch receives a number at receiving and is then tied to the warehouse, shift, and shipment.

Within a batch, products are considered homogeneous — mixed grades and blending of leftovers are not visible in the records, and a discrepancy surfaces during inventory or a customer complaint.

AI traceability does not cancel batch numbering but adds control points on the line.

Computer vision models read the marking on the package and compare the code with the batch in the accounting system, weighing equipment records net weight and flow deviations, and a discrepancy is tied to the area, shift, and time.

Comparison by key parameters:

The class of errors shifts: instead of a "lost batch," there are point discrepancies localized to a control point. Source search is reduced from hours to minutes, and recall becomes targeted — by specific packages, not the entire batch.

The boundaries of applicability differ. For long homogeneous batches without repacking, batch accounting is sufficient. Recognition pays off where batches are split and relabeled, and a recall needs to be limited to the shift's boundaries.

What hinders implementation: technical doubts and limitations

Doubts about AI traceability usually concern not the model itself but the junctions of three loops: recognition on the line, data transfer from the warehouse, and the enterprise accounting system.

Below are the things most often checked before launch and how these points are addressed in the project.

We check each item on a pilot batch: the output gives us the share of operations completed without manual correction and the number of discrepancies the system caught on its own.

What happens with a weak communication channel?

The terminal on the line continues to record operations in a local buffer and sends them when communication is restored: the order of events is preserved, and resending does not create duplicates.

At sites with unstable coverage, we install a local node that accumulates data and synchronizes with the central loop. A communication outage does not turn into a missed batch.

How does the system connect to the accounting system?

Batches, item master, counterparties, and warehouse balances come from the accounting loop; receiving, movement, and write-off events go back. The exchange follows a procedure — event-driven or scheduled, with a log of every message and resending on failure.

Manual entry between systems is not needed, and discrepancies are reconciled in a reconciliation report.

How long will staff training take?

We design the interface around the shift's actions: scanning, weighing, photo, write-off. We train at the workstations in small groups — the basic role is learned in one shift, and extended permissions for supervisors and process engineers are covered separately. After launch, short one-action instructions and on-call support remain for the first weeks.

Let's discuss the task: where we start and what we need from you

To make the assessment based on facts rather than generalities, we start the conversation with a description of the line and the data already available on it.

There is no need to prepare anything specially — what is used in work today is enough: exports, diagrams, procedures, and the process engineer's observations. After that, we bring it together into a picture of the flows ourselves and come back with an assessment and work plan.

What we need from the customer:

• item master and batch coding rules: how the identifier is currently formed and where it is printed;
• line diagram — areas, marking and aggregation points, places where the label is physically read;
• exports from accounting systems: which ones exist, in what format, and with what update delay;
• shop floor constraints — sanitary windows, conveyor speed, temperature zones, access to equipment;
• who will work with the system: operator, process engineer, quality service — and what permissions each needs;
• two or three problem scenarios: where the link between a batch and raw materials or supplier is currently lost;
• contacts on the production and IT side for coordinating data access.

We determine the timeline for the line check after the assessment: first we assemble the event flow on historical data, then we bring a trial loop online in one area and see how it behaves during a shift without hindering output.

The result is a flow map, scope of work, implementation order, and the points where your process engineer is needed.

Describe the task — the item master, the line, and the current batch accounting method. We will come back with an assessment, a work plan, and the timeline for the first line check.