The cutting order enters your system with a photo, not with typing

The problem

The number that explains coil yield is written on paper and typed the next day, if at all.

The cutting order is printed from ERP data, but what actually happens gets written on top of it by hand: that the coil came in with camber and needed extra trimming, that the strip pattern was changed to use the width better, that the last strip came out of tolerance. That is precisely the data that explains real coil yield, and it is the data that gets lost. The paper is typed up the following day, partially, or not at all. When somebody asks why the month's yield dropped two points, the number that would have explained it no longer exists. The result is a plant measuring its most important indicator — how much of every coil it recovers — with a month-end estimate instead of a record.

• The cutting order prints from the ERP with the strip pattern and the theoretical weights. What actually happened — camber, extra edge trim, a pattern changed on the fly to use the width better, the last strip out of tolerance — gets written on top by hand.
• The shift report carries the downtime reasons, the exit weights and the scrap. It is filled in at the end of the shift, from memory, in a folder.
• Between the run closing and somebody typing it, eight to twenty-four hours pass. Over a weekend, more. Part of it never gets typed.
• So when the month's yield drops two points, the run-level number that would explain it does not exist, and the plant measures its most important indicator with an estimate.

How it fits the IRIS system

Connect in photo mode — one photo when the coil goes on, one when the run closes.

Connect in photo-to-analog mode. The operator takes two photos with a phone: one when the coil goes on, one when the run closes. A grounded LLM recognizes the structure of both documents and extracts the fields — coil number, heat, grade, coating, gauge, strip pattern, entry weight, exit weight, trim and downtime reason — storing them structured in central memory, linked to the run and the shift. Before crossing to the master, the summary goes through the line-side tablet for the operator to confirm in two taps. Flow: photo → grounded extraction → human validation → central memory → ERP.

It asks the operator for no new habit: they keep filling in the same order and the same report, and add a photo. That is why it is usually the first case a service center approves, and why the yield baseline appears in the first month instead of after a system rollout.

See the full IRIS architecture →

Before and after

Today's cutting run versus the captured cutting run

Aspect	Today, on paper	With iLEAN Connect
When the run exists in a system	8-24 h later, or never	Second zero
Yield per coil and per run	A month-end estimate	Live data, run by run
Handwritten deviation on the order	Lost unless somebody types it	Extracted and tied to the run
Downtime reason	A line on the shift report	A structured field per run
Explaining a yield drop	An argument in the morning meeting	A query by coil, heat or customer
Operator's habit	—	Unchanged: one photo at start, one at close

from 8-24 h of latency and partial transcription, to second zero with 100% of runs recorded. Yield per coil and per run goes from a monthly estimate to live data.

Impact estimate

Impact estimate — to be validated with your 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-9 months, depending on the number of cutting runs per shift.
• Administrative transcription time recovered by production and planning.
• From 8-24 hours of latency and partial transcription to 100% of runs recorded at second zero.
• And a real yield baseline per coil, per run and per customer, which appears for the first time and is what every improvement plan is measured against.

estimated payback 4-9 months depending on runs per shift, plus the administrative transcription time recovered and a real yield baseline appearing for the first time. *An estimate to be validated*.

And the fair question from the production manager

“What if it misreads a heat number off a handwritten note?” — reading fields from a document with a known structure is an anchored task, where the best models drop below 1.5% error [1]. And there are two nets behind it: the summary goes to the line-side tablet and the operator confirms or corrects before anything crosses, and the coil and heat numbers are cross-checked against what the ERP already has in stock, so a number that does not exist is flagged rather than accepted.

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