Platform
An alarm list nobody reads is the same as no alarms.
Alarm flooding is the most common reason crews stop trusting a SCADA system. The platform treats which alarms fire, and how often nobody acknowledges them, as something you can measure and fix.
- active
High-high level
JR14.TK03.LEVEL
07:41 · unacknowledged
- acked
Pressure above limit
JR14.SEP.TUBINGP
06:12 · J. Reyes
- shelved
Rate below expected
JR14.MTR.GASRATE
until 08-09 · with reason
Conditions on anything you measure
Alarm conditions can be set on any measured or derived tag, not just on a fixed list of device points.
- Thresholds, rates of change and derived conditions.
- Severity tiers, so an urgent condition is separable from an informational one.
- Conditions carry the same units discipline as the rest of the platform.
State that reflects reality
An alarm moves through active, acknowledged, cleared and shelved, and the current state is always explicit.
- Acknowledgment is attributed — who acknowledged it, and when.
- Shelving is deliberate and time-bounded, with a reason recorded, rather than a permanent mute.
- Severity is never communicated by colour alone.
Escalation and on-call
Call-out routes to the person actually on shift, following the rotation rather than a static list that went stale a year ago.
- On-call rotation support, so routing follows the schedule.
- Escalation when an alarm goes unacknowledged.
- Acknowledgment from a phone, which is where the person on call actually is.
Rationalization
The tooling that tells you which alarms are worth keeping.
- Which alarms fire most, ranked.
- Which are chronically unacknowledged — a strong signal that a condition is noise.
- Which fire in bursts, so a flood has a cause you can trace and remove.
Why rationalization is a feature and not a report
Every alarm system starts reasonable and degrades. A condition gets added for a real reason, the reason goes away, the condition stays. Multiply that by a few years and a few hundred wells and the list becomes something people scroll past.
The failure is not that the alarms are wrong individually. It is that nobody has the information to decide which ones to remove, because that decision needs history: how often did this fire, did anyone ever act on it, and did it ever coincide with something that mattered.
The platform keeps that history and presents it, so pruning the alarm list is an ordinary maintenance task with evidence behind it rather than an argument.
Reserved colour
Red and amber mean alarm state in this product and nothing else. They are not used for decoration, emphasis or branding anywhere in the interface, so when something on screen is red, it is telling you something.
Common questions
Can we acknowledge alarms from the field?
Yes. Alarm acknowledgment is one of the things the mobile experience is designed around, alongside gauge entry and well status. Acknowledgment carries attribution wherever it happens.
How do you stop alarm flooding?
By making it measurable. The rationalization surface ranks alarms by how often they fire and how often they go unacknowledged, which is usually enough to identify the handful of conditions generating most of the noise.
Is severity shown only by colour?
No. Every severity state carries a word and a shape as well as a colour, so it survives colour-blindness, a greyscale print and a phone screen in direct sunlight.
See it against your own wells.
A demo runs against synthetic data first, then against a read-only connection to your system of record if you want to see real numbers.