No more toll-client surprises

The problem

Nobody designed the channel the toll business actually runs on.

The toll-processing business depends on third parties, and change notices arrive on personal channels to one person.

• The agreed program arrives as an order. What changes the day arrives as a message: thirty more pigs, ten fewer lambs, the goats cancelled, the cattle moved to the afternoon.
• It lands in natural language, unformatted, on the personal phone of the one person the client has a number for, competing with everything else in the same inbox.
• A volume change read three hours late is a crew already called in for the old plan, plus lairage pens booked for animals that are not coming.
• And in a plant that also runs its own production, a misread toll change does not only cost a shift: it pushes somebody else's order into your own line's window, so the delay lands on a customer who had nothing to do with it. That is the kind of knock-on nobody attributes correctly afterwards, because the message that caused it is buried in a phone.

How it fits the IRIS system

Connect in chaotic-sources mode — the client keeps writing however they like.

Connect chaotic-sources mode. An LLM extracts client, species, volume and new date/time, cross-references the active schedule, and returns the concrete action.

The client is not asked to change anything. They keep sending the same message to the same person, and what changes is that the message stops depending on that person being free to read it in the next ten minutes. The system extracts client, species, volume and slot, compares them against the schedule as it stands right now, and hands the difference to whoever has to act on it.

See the full IRIS architecture →

Before and after

The alert today versus the alert crossed with the schedule

Aspect	Today	With iLEAN Connect
Who reads the change	One person, when they can	The system, at second zero
What is extracted	Read and remembered	Client, species, volume, new slot
Crossing it with the plan	By hand, if there is time	Automatic against the live schedule
What comes back	A message to answer	A concrete action for the role
Crew called in for the old volume	Happens	Caught before the call
If that person is off	The change waits	The alert routes on

hours of human latency → seconds.

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 3-7 months, depending on how often toll incidents actually occur.
• From hours of human latency to seconds between the client's message and a decision somebody can act on.
• Lairage capacity and shift staffing reassigned before the crew is called in, not after they have arrived to find the animals are not coming.
• And your own production stops absorbing the cost of somebody else's last-minute change, which today is the quiet way a toll contract loses its margin.

Estimated payback of 3-7 months depending on toll-processing incident frequency. *Estimate to be validated*.

And the fair question from the production manager

“Are we going to let a model reschedule the kill?” — no, and it is worth being precise: what the system does is extract client, species, volume and slot, cross them with the live schedule and propose. Extracting those four fields from a short message is an anchored task where the best models drop below 1.5% error [1], and the proposal is always confirmed by the person who owns the schedule before anything moves.

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