Batch and expiry stop being typed twice

The problem

The same batch and expiry typed twice, and the changes are constant.

In a plant exporting to more than twenty countries, printed expiry is not one figure but several. Declared shelf life changes with the product, with the format and sometimes with the destination market, because each market has its own labeling rules. The operator picks the right template on the coder's panel. The overwhelming majority of the time they get it right, because they have been doing it for years. The day they do not, the error is printed on tens of thousands of packs and is found on the pallet, in the container or — expensively — on the shelf in the destination country, with the brand name on it. It is an error that more training and more attention do not fix. It is fixed by eliminating the point where it can occur.

• The coder printing batch and expiry on the carton is about ten years old and has an open API. The ERP knows which batch is being packed and what shelf life applies. And still, at every production change, someone types the same data into both.
• In a plant exporting to more than twenty countries, printed expiry is not one figure but several: it changes with the product, the format and sometimes the destination market, because each market has its own labeling rules.
• The operator picks the right template on the panel. The overwhelming majority of the time they get it right. The day they do not, the error is printed on tens of thousands of packs and found on the pallet, in the container or on the shelf in the destination country.
• It is an error that more training and more attention do not fix. It is fixed by eliminating the point where it can occur.

How it fits the IRIS system

Connect stitches the ERP and the coder over API, replacing neither.

Connect stitching two modern systems together over API, replacing neither. The flow:

What was printed comes back confirmed to the ERP: not what was asked to be printed, but what the marking head says it printed, batch by batch. That distinction is what turns the coding of a carton into evidence instead of an assumption — and what makes an entire class of recall structurally impossible rather than merely unlikely.

• When the production order is launched, the ERP pushes product, batch, production date, applicable shelf life and destination market.
• Connect translates that data into the template the marking head expects and loads it automatically.
• The head prints and confirms what it actually printed.
• Connect writes that confirmation back to the ERP as evidence tied to the batch.
• If someone forces a manual change on the panel it is not blocked: it is logged as a deviation, with its reason and its owner.

Neither the ERP nor the coder changes. They simply stop standing a meter apart without speaking.

See the full IRIS architecture →

Before and after

The isolated coder versus the stitched coder

Aspect	Today	With iLEAN Connect
Keying per production change	Twice: ERP and coder panel	Once, in the ERP
Expiry for the destination market	Template picked by hand	Pushed from the ERP with the order
What was actually printed	Believed	Confirmed by the head, tied to the batch
A manual change on the panel	Invisible	Logged as a deviation with its owner
Misprinted expiry on 30,000 packs	Possible at every changeover	Structurally impossible
The ERP and the coder	—	Neither is replaced

from two keying operations per production change, to zero. From "we believe the right thing was printed", to the machine's own confirmation, batch by batch. From a labeling error possible at every changeover, to one that is structurally impossible.

Impact estimate

Estimated impact — to validate with your own numbers.

The block below is an estimate to be validated against your plant's actual data. We put it forward so the committee has an order of magnitude; we refine it during the assessment.

• Estimated payback 4-8 months on format changeover time alone.
• The bulk of the value lies in eliminating an entire class of error whose unit cost is a recall with the brand name on it, in the destination country.
• Two keying operations per production change become zero, and the changeover stops depending on picking the right template under pressure.
• To confirm before sizing: that the installed model exposes an API or RPC. Heads more than a decade old sometimes do not and need an intermediate adapter, which raises initial CAPEX without breaking the approach.

estimated payback 4 to 8 months on format changeover time alone. The bulk of the value lies in eliminating an entire class of error whose unit cost is a recall. *Estimate to validate.* To confirm before sizing: that the installed model exposes an API or RPC. Heads more than a decade old sometimes do not, and would need an intermediate adapter, which raises initial CAPEX without breaking the approach.

And the fair question from the production manager

«Isn't a classic ERP integration cleaner?» — it is, on the day the project reaches the top of the list, and that is exactly the problem: this is the classic case of a modern coder still isolated because there was never time. This stitching replaces neither system, asks for no shutdown window and does not compete in that queue. The only place a model is involved is in reading the head's confirmation back against the order, an anchored task where the best models drop below 1.5% error [1]; the rest is a deterministic API exchange. And if someone forces a manual change on the panel it is not blocked: it is logged as a deviation, with its reason and its owner.

^[1] OpenAI paper "Why Language Models Hallucinate", 2025 — on the reliability of AI in anchored tasks.