Camera reads vintage panel

The problem

The machine that decides crumb and volume keeps no memory of what it did.

Replacing the proofing chamber costs several hundred thousand euros and weeks of downtime. But its panel holds exactly the data that most determines the bread's final specific volume and texture — and today that data dies every time the screen rotates, so nobody correlates the proofing curve with a texture defect.

• The controlled proofing chamber of a sliced-bread line is typically 15-20 years old, lives on an isolated network and shows humidity, temperature and proofing time on a proprietary panel that rotates between screens.
• Replacing it costs several hundred thousand euros and weeks of downtime, so it stays in the capital plan year after year while it keeps proofing well enough.
• Yet that panel holds the data that most determines the loaf's final specific volume and crumb texture — and the value disappears every time the screen rotates.
• So when the lab flags a dense crumb or a collapsed top, nobody can say whether the chamber ran dry, ran cold or held the dough too long. The texture defect is recorded; its cause is not.

How it fits the IRIS system

Connect in photo-on-panel mode — the chamber is read from outside, its control untouched.

Connect's photo-on-panel mode. A fixed industrial camera runs OCR with a grounded language model on every frame, structures the time curve per batch, and cross-references it against the ERP to know which batch was proofing at each moment.

The proofing chamber does not need to be replaced to start talking. A camera that reads what the panel already shows is enough to turn every batch into a curve you can lay next to the lab result, and that comparison is what nobody can make today. It opens no ports and installs nothing on the machine.

See the full IRIS architecture →

Before and after

Today's proofing chamber versus the chamber being read

Aspect	Today	With iLEAN Connect
Humidity and temperature curve	Lost when the screen rotates	Digitized frame by frame, per batch
Proofing time per batch	Assumed from the recipe	Measured and stored
Dense crumb or low volume	No proofing data to compare	Laid against that batch's curve
Which batch was in the chamber	Reconstructed by hand	Cross-referenced with the ERP
The chamber's original control	—	Untouched, no ports opened
Chamber replacement	Pending in the capital plan	Deferrable indefinitely

Impact estimate

Impact estimate — to be validated with your bakery's 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 5-10 months.
• Avoided capital expenditure on replacing a proofing chamber that still proofs well but cannot share what it does, plus the weeks of downtime a replacement would cost the line.
• Scrap reduction from correlating the proofing curve with crumb and volume defects, a correlation that is impossible today.
• Root-cause analysis per batch goes from zero to minutes: the curve is already sitting next to the batch number when the lab reports a texture defect, so the proofing side of the question is answered before the next batch goes in.

Estimated payback of 5 to 10 months, avoided capital expenditure on equipment replacement, scrap reduction from curve-defect correlation. Estimate to validate.

And the fair question from the production manager

“Can a camera reading a screen really give quality a number it can trust?” — here the task is anchored: a fixed panel, values in known positions and a physically possible range for humidity and temperature, where the best models drop below 1.5% error [1]. A frame whose value falls outside that range is discarded instead of stored, so a reflection or a half-rotated screen never becomes a data point. The proofing curve that reaches quality is one they can defend in front of a customer.

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