The roast log stops taking eight hours to exist
In a roasting plant, the head roaster starts each batch with a paper log recording the green lot, origin, profile applied and kilos in, and also notes what he observes: bean colour, first crack, shrinkage, last-minute adjustments. That sheet is the most valuable knowledge in the plant, and today it sits in a folder until someone collects it. With iLEAN Connect, two photos — one at the start, one at the close — mean the batch exists in the central system at second zero, with nothing changed in the roaster's routine.
The log mixes two different things, and both stay on paper.
The roast log mixes two different things. On one side, structured data the management system needs: green lot, origin, profile, kilos in and out, shrinkage. On the other, the craft annotation that gives the batch its meaning and that often only its author can interpret: "green very wet, extending by thirty seconds". Both matter, and both stay on paper. Between the batch ending and someone collecting and typing up the log, four to eight hours can pass — sometimes the entire shift. During that time the batch doesn't exist for anyone but the person who roasted it. When a complaint arrives about a specific lot, reconstructing what happened means hunting through a folder, and the outcome depends on the log being complete and legible. In a group with several roasting sites the effect multiplies: each uses its own log format with its own fields. One plant's roasting yield isn't comparable with another's, even when both are roasting the same origin. The information exists in both; it simply isn't written in the same language.
- Structured data the management system needs: green batch, origin, profile, kilos in and out, weight loss.
- Craft notes that give the batch its meaning, and that sometimes only the person who wrote them can read: “very wet green, extending thirty seconds”.
- Between four and eight hours from the end of the batch until somebody collects and keys in the log. Sometimes a whole shift.
- And in a multi-plant group each site uses its own format: one plant's roasting yield is not comparable with another's, even roasting the same origin.
Connect in photo-the-analog mode — the paper keeps being filled in the same way.
Connect in "photo of the analogue" mode. Step by step:
The habit change is zero. That is why the solution is still alive in month three, which is where the ones that make the roaster learn an app die.
- The roaster photographs the log when the batch starts and again when it closes, using a phone or an industrial tablet. There's no app to learn and no fields to fill in.
- A grounded language model extracts the structured fields — lot, origin, profile, kilos in and out, shrinkage — and separately preserves the roaster's free-text note as context attached to the lot.
- The data is normalised to the group's common model: the same definition of lot and shrinkage for every plant, without forcing any of them to change their form.
- The summary appears on the line tablet for early human verification (two taps: confirm or correct) before crossing into the central system.
- The lot becomes available for lookup, for cross-referencing with the roast curve, and for the audit evidence pack.
The key point is that the habit change is zero. The paper is still filled in the same way — which is why the solution survives past month three.
Today's log vs. the captured log
| Aspect | Paper log | With iLEAN Connect |
|---|---|---|
| Latency until the batch exists | 4-8 hours | Second zero |
| The roaster's notes | Stay in the folder | Context tied to the batch |
| Reconstructing a batch | Hunting for paper | Instant lookup |
| Log format | One per plant | Theirs, normalized to the group's |
| Comparing yield across plants | Not possible | One batch model |
| Supervisor's keying time | Daily work | Recovered |
4-8 hours of latency → second zero. Reconstructing a batch: hunting through paper → instant lookup. One log format per plant → a single batch model for all, without imposing a new form on anyone. Production manager's transcription time → recovered.
Impact estimate — to validate against 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.
- Roasting plants with a paper log per batch and several factories brought into the group.
- Indicative payback between 4 and 9 months, depending on batches per day and number of plants.
- Plus the production supervisor's keying time, recovered from the first week.
- And comparability across plants, which no amount of anybody's hours can buy.
estimated payback of 4 to 9 months depending on batches per day and number of plants brought in, plus recovered transcription time. *Estimate to validate* against real volumes.
And the fair question from the production manager
“What if it misreads a weight and a false figure gets in?” — extracting fields from a log with a known structure is an <b>anchored</b> task, where the best models drop below <b>1.5%</b> error <sup><a href="#source-openai">[1]</a></sup>. But that is not the real answer: the summary goes to the tablet and somebody confirms or corrects it before it crosses into the system. The data does not enter on its own.
[1] OpenAI paper "Why Language Models Hallucinate", 2025 — on the reliability of AI in anchored tasks.
What people ask about digitizing the roast log
Does the log format have to change?
No, and that is the point. Unifying forms across acquired plants is an endless project that also gets resisted, because each log has been tuned for years to how that factory works. Vision reads the structure of the document, so each plant keeps its own and the normalization happens on iLEAN's side.
What happens to what the roaster scribbles in the margin?
It is kept separately, tied to the batch, as context. That is deliberate: those notes are the most valuable part of the log and the part most lost today, but they are not a structured field and forcing them to be one would destroy them. They stay searchable next to the batch, which is how they get consulted when a claim arrives.
Does it work if the log is messy or incomplete?
It reads what is there. If a field is missing or unreadable it gets flagged in the validation instead of invented, and the roaster completes it there and then — with the batch still fresh, which is when it is possible. Today that gap surfaces weeks later, when nobody remembers.
Does the roasting area need network coverage?
It only needs the device to be able to send the photo at some point; if coverage is poor, it queues and uploads later. That is one reason to do it by photo rather than with a connected app: the roaster's work does not depend on the network.
Does the roast curve come in through here?
No: the curve lives on the roaster panel and is captured in another case in this same matrix, with a camera on the panel. The two are cross-referenced afterwards by batch, which is when the analysis becomes useful — the curve alone does not explain a weight loss, and neither does the log alone.
Tell us how long a batch takes to exist in your system today.
We work on your plant's real data, not ours. Assessment with no commitment.
Request estimated ROI within 48h ‹ See all cases of coffee, culinary, snacks and foodservice See food