Another alarm?
Make it worth a look.
MANTIS checks operating context and groups repeated sensor alerts into a shorter, explained queue. Evaluated against a year of Tata Steel Shotton NO6 data, with the engineer making the final call.
Explore the replay ↓
Grouped incidents per year
known events found
with the MAJOR profile
2025 historical evaluation. Not live monitoring.
The maintenance problem
Everything’s unusual.
Until you know the context.
Starting, stopping and changing speed can all trigger alerts. A strange reading isn’t automatically a fault. Maintenance teams can spend more time sorting the queue than examining the changes that matter.
MANTIS asks whether the line was running normally, whether a change was local and whether it lasted. Repeated alerts are grouped before they reach an engineer.
An explained reason to investigate, not an automated diagnosis.
Explore the guided replay
Follow an alert.
See why it made the queue.
Choose a sensitivity profile and a sanitised scenario. This guided illustration explains the checks; it isn’t a live plant feed. Signal shapes are invented, not raw plant data.
MANTIS / GUIDED REPLAY
NO6 · 2025 historical research replay · not live
Sanitized guided replay of the historical workflow; no raw Tata Steel plant data is published.
MAJOR profile, Clear sustained change: Sent for engineer review. It overlaps a known event window.
MANTIS · MAJORHow many of the five known major event windows had at least one MANTIS incident overlap.
4/5
known events found
Grouped / yearAlerts close together in time are combined so an engineer sees one incident instead of repeated notifications.
33
24-hour grouping
Avg. intervalThe average number of days between incidents in the one-year historical replay.
11.1 days
between incidents
Queue differenceThe reduction in grouped historical incidents compared with the fixed AVEVA record of 263 grouped incidents per year.
≈87%
vs fixed AVEVA
AVEVA · fixed
3/5 · 263/year
1.4 days
Profile metrics use the 2025 historical replay, five validated event windows and a 24-hour incident merge. Burden reduction is not a false-positive claim.
Illustrative timeline
A clear change that lasted
Invented relative evidence across a representative window. The shape and values are illustrative, not raw plant data.
This example shows a local change that lasted while the line was running normally. Both historical profiles sent it for review.
Gate-by-gate reasoning
1. Unusual signal: passed
Evidence
The component moved away from its usual pattern.
2. Normal running: passed
Regime
The line was running steadily, so start and stop noise is excluded.
3. Local change: passed
Isolation
The change looks local rather than plant-wide.
4. Lasted long enough: passed
Persistence
The change lasted long enough for the MAJOR settings.
5. One incident: passed
Grouping
Nearby alerts are combined within 24 hours.
6. Engineer review: passed
Human decision
An engineer checks the context and decides what to do next.
Sent for engineer review. It overlaps a known event window
This creates an item for an engineer to review. It is not a diagnosis or maintenance instruction.
The evidence / 2025 historical NO6 record
A quieter queue has
a trade-off. Here it is.
Five known major events. One year of historical data. MAJOR kept the queue smaller; WARNING found all five known events with more incidents to review.
| Profile | Known events found | Grouped incidents / year | Average interval |
|---|---|---|---|
| AVEVA | 3/5 | 263 | 1.4 days |
| MAJOR | 4/5 | 33 | 11.1 days |
| WARNING | 5/5 | 90 | 4.1 days |
Alerts within 24 hours count as one grouped incident. AVEVA is a fixed historical reference, not a parallel trial. MAJOR had approximately 87% lower grouped burden; WARNING approximately 66% lower. Grouped burden is not a false-positive count. These results are historical evidence, not a guarantee on another plant.
How it works
Context first.
Human review last.
A five-node map links the motor, gearbox, drive-side bearing, open-side bearing and process context for each roll. A forecasting model learns typical behaviour and produces anomaly evidence when the observations differ.
The review path checks operating regime, isolation and persistence, then groups alerts within 24 hours. Each stage stays visible so an engineer can see how an incident reached the queue.
Evidence → operating context → local change → sustained change → grouping → engineer review.
Try it on your data
One asset class.
A clear first test.
Start with a slice of historical data and agree what success looks like before data transfer. A pilot ends with an evidence pack and a recommendation: go, adapt or stop.
Bring
Time-aligned signals, operating context, baseline alarms, event and maintenance history, named reviewers and agreed data governance.
Test
Data quality, topology, historical replay and calibration. Review known events and compare detection with grouped burden.
Decide
An explainable replay, agreed metrics, scope and data gaps, and an evidence-based next step.
Your next useful conversation
Tell us what’s
getting in the way.↗
A few lines about the process, the tools and the part that’s frustrating. That’s plenty to start with.
Chamber of CommerceBacked by a University of Chester
Venture award