Ask the plant a question.

Toleron Flow lets people ask the plant a question — in the assistant panel beside every page of the dashboard, or on a machine's own page. It answers three kinds of question today:

• About the machine — what it is doing, what happened in the last hour, day or week, which alarms cost the most time, where the downtime went, how well it was utilised.
• About the manual — what the approved documents say, citing the page, the upload date and whether the document has been checked.
• Explaining a period — a machine page offers “What happened in the last 24 hours?”, “this week” and “the last 30 days”. It only offers questions your installation can actually answer, so no button leads to a refusal.

Conversations are general by default; type @ and a machine name to talk about that machine. Every conversation is kept, can be reopened and continued, and every answer can be traced in the log.

Flow does not read your database directly. It uses the same evaluations as the dashboards and reports, with the asking person's own access rights. The numbers come from the same calculation as the reports; the language model only puts them into words.

1. You see what is happening. While the data is fetched you see reading machine status or querying alarms — something visibly happens within a second, even when the full answer takes six.
2. Tables show the actual figures. A result appears as a table, not retyped as prose. A value that could not be calculated is a dash, never a zero. A shortened list says top of 57.
3. Toleron ranks, the assistant explains. Which alarm cost the most is decided by Toleron's own analysis; the assistant explains the ranking. Given real facts, an assistant restates them well but sets priorities poorly — so it is not asked to set them.
4. Sources show their age. A manual page is cited with its upload date and revision; an unchecked or outdated document says so rather than staying silent.
5. Three possible outcomes. A full answer, a partial answer that names the missing data, or a clear “cannot answer”. “OEE cannot be calculated because no ideal cycle time is set” is an answer; an invented 0 % is not.

Flow has deliberately narrow reach. Each of these limits is secured by automated tests, not by a guideline:

• Flow cannot see more than the person asking — it has no access of its own to the operating data and always works with that person's rights.
• Flow cannot change anything — not in data collection and not on a controller. That access does not exist and will not be added. The system advises; people act.
• Every question to the model is logged.
• Flow works with summaries, alarms and documents — never with raw sensor recordings.

Flow runs entirely on local hardware. Which model is used is decided per installation: openly available models on local hardware in our lab today, a different model tomorrow — without changing the software. Documents and operating data never leave the site.

What Flow passes to the model is deliberately kept short: results are trimmed and only what the question needs is passed on. That keeps answers fast on modest hardware — and the same on a larger model.

Flow is in early access on our lab installation since August 2026: the assistant panel, @ mentions, conversation history, the knowledge page and the per-machine explanations are live, and they are checked against a growing set of test questions that Flow must answer or decline correctly.

Designed and next in line: a daily and shift attention panel that first ranks what deserves a look and then explains it; a fault workbench that leads step by step from symptom to documented cause; guided actions — “register this sensor”, “add this machine” — that first fill in the existing forms and only execute after a person confirms; and connections to the other factory systems.