Operator report, every hour
What moved in the last hour, which tags are off nominal and what to check first, written while the shift can still act on it.
HOURLY · DEVIATIONS · ACTIONSFor plant operations and process engineering teams
Every deviation.
Explained the same hour.
Luma reads your process data every hour and compares it against the plant's own process description, alarm limits, past incidents and lessons learnt. It writes the report each audience needs. Every conclusion opens into the readings behind it.
Inside Luma
The area you run,
as it stood this hour.
Production rate, quality, energy and yield against target, each with its trend over the period and the area status that follows from them. Behind every card sits the tag data and the report that reads it.
Demo data. The production interface evolves and may differ in detail.
What Luma writes
One hour of plant data.
Four reports and the working.
Shift handover
The state of the area at the end of a shift: what happened, what is still open and what the next crew inherits.
PER SHIFT · OPEN ITEMS · HANDOVERPlant manager and executive reporting
The same hours rolled up daily and weekly against targets, with the equipment issues and quality results behind the numbers.
DAILY · WEEKLY · VERSUS TARGETCause with supporting evidence
A most likely cause with a stated confidence, the readings that support it and the alternatives Luma considered and ranked lower.
CAUSE · CONFIDENCE · ALTERNATIVESTime to limit and cost of waiting
How long a drifting parameter has before it reaches its alarm limit and what an hour of the current deviation costs in yield, energy and rework.
HOURS REMAINING · COST PER HOURThe plant knowledge behind it
Your process description, past incidents and lessons learnt sit under every report, so a finding can point back to the time this happened before.
PROCESS · INCIDENTS · LESSONSHow Luma works
From tag readings to
a report someone can act on.
Luma runs the same six steps every hour: read the data, weigh it against what the plant knows, explain what changed and show the chain that produced the explanation.
01Connect the plant data
Historian tags, lab results, alarm and event logs come in on the plant hierarchy your teams already use: plant, product line, process area.
02Load what the plant knows
Process description, alarm limits and nominal values, past incidents and lessons learnt. This is the knowledge a report has to be checked against.
03Find what moved
Every tag in the area is compared against its nominal value, its target and its alarm limits over the period, with the trend and the size of the deviation recorded.
04Explain and quantify
Luma proposes the most likely cause with the readings behind it, ranks the alternatives, projects hours to limit and puts a cost per hour on the deviation.
05Write for the audience
The same hour becomes an operator report, a shift handover, a daily plant report and a weekly executive summary. Each one says what that reader has to decide.
06Show the reasoning
Every conclusion opens into the tag readings, the process description section and the past incident that produced it. Your engineers judge the chain.
The cost of finding out late
The data was there at 07:00.
The meeting is at 09:00.
A tag drifts for six hours before anyone reads the trend. The night crew hands over what they remember. The plant manager gets a spreadsheet the next morning and asks why. Luma writes that hour up while the shift is still running, in the form each reader needs.
Trust and operating authority
Automation that stops at
the operating decision.
Luma reads, compares, explains and recommends. Operating the plant stays with your shift team.
Read-only by design
Luma consumes process data. It writes no setpoint, closes no alarm and sends nothing to the control system.
Reasoning you can open
Every conclusion lists the tag readings, the process description section and the past incident behind it, each one a link you can follow.
Grounded in your plant
Findings are weighed against your process description, alarm limits, incident history and lessons learnt. Your plant record is the reference.
Data isolation
Each client's plant data is isolated at the database layer with Row Level Security.
EU data residency
European data centers are the default for hosting and processing. We select third-party services for EU hosting and GDPR compliance.
Provider disclosure
Before a deployment processes plant information, we document which tools, models and infrastructure it uses, where data flows and what controls apply.
Questions operations teams ask
Clear boundaries build
software a plant can trust.
Honest constraints up front. Easier than discovering them three months in.
Does Luma control the plant?
No. Luma reads process data and writes reports. It sends nothing to the control system, changes no setpoint and closes no alarm. Every action it recommends is carried out by a person.
Does Luma replace our historian or DCS?
No. Your historian stays the record of what the plant did. Luma reads from it and adds the hourly reading, the cause analysis and the report your team writes by hand today.
Which data does Luma need?
Historian tags with their nominal values and alarm limits, plus lab results and alarm and event logs where you have them. On the knowledge side: a process description of the area, past incidents and lessons learnt.
What happens when a tag is missing or bad?
A finding that has no reading behind it is not written. Where a sensor is dead or a value is out of physical range, the report says the parameter could not be judged instead of filling the gap.
How do we check a conclusion?
Open the reasoning behind it. Each conclusion lists the tag readings it used, the section of the process description it relied on and any past incident or lesson it matched, each one a link you can follow.
Does Luma decide what the plant does next?
No. Luma reports what changed, what it most likely means and what it would check first. The operating decision stays with the shift team and the process engineers who own the area.
Can operators correct Luma?
Yes. When a crew resolves an event, what they found goes into lessons learnt for the area. Later reports are written against that record.
Is our process data used to train models?
No. Luma does not train models on your plant data. The data-processing terms of the providers enabled for a deployment are documented before plant information is processed.
How is plant information isolated?
Plant data is private and isolated per client. Database access is enforced with membership checks and Row Level Security.
Who builds Luma
Luma is built by two process engineers, close to 30 years of plant and project work between us. We have written the shift report at the end of a long night and read the trend that had been drifting since morning. We build the software we wanted on those shifts.
Getting started
A pilot on one area,
then you decide.
Luma starts as a bounded pilot on one of your process areas, read by your own operators. Four steps from first call to a rollout decision.
- Step 1
Intro call
A short call on your plant and which reporting your team writes by hand today. We agree the pilot scope: one process area, one set of tags, the reports that matter.
- Step 2
Pilot run
We load that area into an isolated workspace with your process description and history. Luma then writes the reports for a live period.
- Step 3
Review with your operations team
Your operators and process engineers read the output against what happened. They open the reasoning behind each finding and judge whether it holds.
- Step 4
Rollout decision
You decide whether to extend to more areas or stop there. The pilot findings are yours either way.
It starts with a short call.