What the meters are saying, and what they're about to say.
An alert tells you a machine needs attention today. A projection tells you it will need attention in five weeks — long enough to put the work on a visit that was already happening. That difference is the difference between condition monitoring and an alarm panel, and it is the whole reason this module exists.
Bilingual EN / FR · Multi-site · WCAG 2.2 AAA rule people don't turn off
Most condition monitoring dies the same way: a rule fires on noise, somebody mutes it, and within a month nobody reads the list. Every field on a Zenith rule exists to stop that particular death — and each one is the field somebody in a hurry would have deleted.
Rises to, or falls to
Filter pressure rises to a limit. Belt tension falls to one. Refrigerant charge falls; vibration rises. An engine that only knows “above” quietly cannot express half the useful rules in a plant.
Look, then act
A warning level and an action level. The warning is the first thing dropped by whoever is in a hurry, so a rule without one is flagged on its own row: it can only tell you once it is already too late.
A run, not a reading
How many readings in a row must be past the line before it speaks. One is right for a step change like a trip. Two or three is right for anything noisy — and it is the difference between an alert people read and an alert people filter into a folder.
How far back is back
How far past the line the meter must return before the rule speaks again. Zero, on a meter sitting exactly on the line, produces an alert every single reading — which is how condition monitoring dies in most of the plants that have tried it.
What it would cost to be wrong
Emergency, High, Medium or Low. The queue sorts on it first and newest-first within it, so the megger result never queues behind a filter.
Replayed from the readings
A state column on a rule is a second answer to a question the readings already answer — and the two drift the first time somebody edits a limit, which is precisely when somebody is looking.
Five weeks' notice, with the workings shown
A straight line through the readings of the last ninety days, and that is deliberately the right amount of model: a filter's pressure rises roughly linearly between changes, and anything cleverer would be a curve nobody can explain to the person who has to act on it. What makes it usable is not the maths — it is everything printed beside the date.
- Three readings minimum — two points always make a line and say nothing about whether it is the right one. Three is the least that can disagree with itself.
- Counted from today, not from the last reading — otherwise the screen prints “14 days” beside a date nine days away, and the reader decides the whole panel is guessing.
- Flat or moving away gets no date at all — inventing one from a flat line is the fastest way to lose a reader.
- A poor fit is labelled, never silently dropped — “we are not sure” is information; a projection that quietly vanished is not. The row says steady or scattered, with the percentage and the number of readings behind it.
- Rules that have already fired are left out — a machine sitting past its action level does not need a date for when it will get there.
Taken, not dismissed
An alert somebody has taken is off the list and still on the record — which is the difference between a queue that gets worked and one that gets cleared. Who took it and when is the only part of an alert that is not derivable from the readings, and that makes it the only part worth writing down.
- An acknowledgement can't be overwritten — a second attempt is refused rather than quietly replacing whose name was on it.
- Sorted by what it would cost to be wrong about — Emergency, High, Medium, Low, then newest first inside each.
- The rail badge counts what fired since you last looked — not the total open, because a total that only ever grows is the wallpaper this whole feature exists to avoid.
- Fired stays fired until the meter comes properly back — re-arming the instant a reading dips under the line is how one machine produces forty alerts in a fortnight.
Change the limit, and the history changes its mind
Zenith stores no alarm state. Every standing is replayed from the readings each time it is asked for — so lowering a limit re-reads the past immediately, and correcting a mistyped reading corrects the log with it. Held as a column instead, the rule would still read “warning” until the next reading arrived, and the person who moved the line would have no idea they had just raised an alarm.
- The event log holds only what the replay can't — who acknowledged an alert, and when. Everything else is filled in from the readings, keyed on rule, kind and date, so re-running changes nothing that was already true.
- Backdated readings land where they belong — a reading recorded late produces the right history rather than a history of when somebody happened to type.
- One reading per meter per day — duplicates are refused by date, and deleting a mistyped one is a real correction, because leaving it in place skews every projection after it.
- A gauge falling is good news, not a bad reading — a cumulative counter going backwards is a typo; a differential pressure going down is a filter somebody changed, and refusing it would be refusing the good news.
No black box, on purpose
There is no model here that scores your equipment, and there is no training data. What there is: a limit somebody chose, a direction, a debounce, and least squares over ninety days. Every one of those is a number an engineer can argue with — which is the only kind of prediction that ever changes a decision.
- The rule says whether it raises work or only tells somebody — and both are legitimate. A vibration alarm should raise work; a “look at this” rule should not fill the backlog with jobs nobody asked for.
- Readings are taken, not streamed — a megger test is a deliberate measurement on a stopped motor, not a sensor sampling a running one, and the engine is built for the reading somebody writes down on a round.
- No spectra, no waveforms — the engine reads one number per meter per day, in the unit the register already knows. Your analyser stays your analyser; Zenith holds the trend and the decision.
- Nothing hides behind a confidence score — the entire model is a slope and an R², and both are on the screen.
And what already happened
A projection is a claim about the future. The rest of the module is a claim about the past, computed from the same rows the technicians closed — and every figure on those screens names exactly what it was computed from, and says so plainly when it cannot be computed at all.
Every number names its evidence
Nothing here returns a bare number. Each figure carries what was counted and what was left out, by name — because “seven analyzed, three uncoded” and “seven analyzed” are different claims, and only one of them is true.
- A failure is a finished corrective work order that carries failure coding — computed from the records technicians closed, not from a separate register typed in afterwards.
- It happened when the machine went down — not when the paperwork was closed, so the date the analysis uses is the date operations remembers.
- Uncoded work is excluded by name, never dropped — the line under the figure reads “1 finished corrective work without failure coding”.
- A figure that can't be computed prints the reason where the number would be — “cannot be computed — only one failure” is a fact; “—” is a shrug.
Ranked by hours lost, and every row shows its receipts
The machines doing the damage, worst first — ranked on equipment hours lost, because unavailable equipment is the number operations feels. There is no composite score, no weighting and no risk index, and that is deliberate: a bad-actor list nobody can audit is a rumour with a sort order.
- The last column is the audit trail — every work order the row was computed from, each one a link you can open and disagree with.
- Count and hours side by side — the most frequent problem and the most expensive one are routinely different, and the pair is the argument.
- MTBF refuses below two failures — one failure has no “between”, and a machine with one failure is not infinitely reliable; it is one failure old.
- Unpriced labour is declared — hours booked with no rate against them are named beside the cost, never quietly added as zero.
Everything around the reading
Condition on the machine's own page
Standing in front of a chiller is exactly when “five weeks” is worth more than “within limits”. The asset's own tab lists what is watched here, where the lines are, and how close it is.
A badge that counts what's new
The rail shows what has fired since you last looked, not the total still open — because a number that only ever grows is exactly the wallpaper this feature exists to avoid.
Units as symbols
“2.6 degC” is a database column; “2.6 °C” is a reading, and the register already knows the difference.
Rates at the precision they have
A filter gains about four thousandths of a kilopascal a day. Printed to two decimals it reads “0.00 a day” beside a date five weeks out — which tells the reader the number is broken, and they are not wrong.
Rules retire, they don't vanish
Deactivating a rule takes it out of the standings and leaves every event it ever wrote, because “has this been firing all summer?” is the question that decides whether the limit is wrong or the machine is.
Sites side by side
Open work, overdue, failures, hours lost, mean repair time and open alerts per site — with work carrying no site excluded by name, because a comparison that silently drops the unlabelled rows is comparing different denominators.
Repair or replace
The ledger knows what this machine costs to keep; only you know what a new one costs to buy. Enter that and the arithmetic answers — with its rule printed and every job it counted cited.
Cited sentences, or nothing
Every summary sentence renders with the records it was computed from, as links. There is no variant without the citations row — uncited prose has no way onto the screen.
Nothing changes without a confirmation
The assistant runs the same command a form would, so a register's refusal comes back word for word. It has no privilege you don't have, and it is the same door.
Arithmetic you can hand to an engineer
Predictive maintenance only survives contact with a plant if the people acting on it can check it. Everything here is built so the answer can be reconstructed by hand, on a Tuesday, by somebody who did not write it.
Derived, never stored twice
State, standings, crossings and projections are all computed from the readings, so nothing on the screen can disagree with the data underneath it.
No wall clock in the engine
Every question takes the date it is asked about, because a planner working three weeks out has to be able to ask it about a Tuesday in September.
Bilingual by birth
Full en-CA / fr-CA parity on every screen, hint, empty state and refusal — plurals handled properly, not by concatenation.
Accessible to everyone
WCAG 2.2 AA as a build rule: real tab semantics, states announced in words, and focus that moves to the field an error refers to.
Before you book the demo
Is this AI?
Do you connect to sensors, a historian or an IoT gateway?
Do you analyse vibration spectra?
Which measurement types are supported?
Why does an alert wait for two readings in a row?
Why doesn't a fired alert clear as soon as the reading drops?
How far ahead does it project, and how accurate is it?
Does an alert raise a work order automatically?
What happens if we change a limit after the fact?
How is MTBF calculated?
What counts as a failure?
Do you rank bad actors with a risk score?
Bring the number somebody writes in a book.
Every plant has one — the filter pressure, the megger result, the condenser approach, recorded faithfully for years and plotted by nobody. Give us six months of it and we'll show you the date it crosses the line, the fit behind that date, and what it would have been worth to know in April.