Notifications Are Not Alarms, and the Line Has to Be Architectural

The alarm system is one of the most heavily engineered artefacts in a plant.

Rationalised point by point. Prioritised against consequence. Rate-limited by design. Governed by a philosophy document. Connected to an operator whose response to each alarm is defined.

That discipline exists because the industry learned, at Milford Haven and a dozen quieter events, what an unmanaged flood of alerts does to a human being at the worst possible hour.

Into the same plant now arrives the data platform. Cheerful, unregulated, and able to email, text and push-notify anyone about anything a query can express.

Nothing in it has read the alarm philosophy.

The bright line, and why it is architectural

The distinction is not technology. It is obligation.

An alarm is part of the plant’s engineered response to abnormality: annunciated to the operator, with a defined response, inside the control system’s governed scope, under the site’s alarm philosophy.

A notification from the data chain — condition indices, KPI excursions, data-quality events, the chain’s own health — informs roles on information timescales. Minutes to days. Advisory. No defined operator response. No seat in the control room.

The line has to be architectural rather than rhetorical, because a boundary that exists only in a policy document erodes the first time someone is in a hurry. Three properties make it structural:

Notifications travel channels that cannot be confused with annunciation. Email, messaging, work-order creation. Not a tile that looks like an alarm tile on a screen that sits in the control room.

Notifications never write into the alarm system. Not “temporarily”, not “just this one”, not through an integration nobody documented.

Anything analytics discovers that genuinely deserves operator annunciation gets there by one route only — the site’s alarm-management process, with rationalisation and a defined response, owned by the discipline that owns alarms.

The data platform proposes. The alarm process disposes.

Borrowing the discipline that was already paid for

Everything alarm management learned about humans applies verbatim to the new channel, and the data platform arrives with none of it.

Every notification has a recipient-role, a meaning and an intended action. This is the four-gate decision test, miniaturised and applied to a rule instead of a sensor. If no one would do anything differently, it is not a notification. It is spam with a timestamp.

Rate is engineered. Deadbands, hysteresis and hold-off times on triggers — the acquisition filters, reapplied at the top of the stack. Duplicates suppressed. Related events grouped. And flood behaviour designed in advance, because a broker outage must produce one notification rather than four hundred. A hub is also a flood amplifier.

Priority means time-to-act, stated in the message, or it means nothing. “High” is a colour. “Respond within one shift” is an instruction.

Effectiveness is audited. The notification estate gets the same periodic scrub a display estate does: response rates tracked, dead rules retired, recipients confirmed as still existing and still caring.

The metric of health is the one alarm management already uses. A channel people trust is quiet enough that its messages still mean something.

At Meridian, the invented plant the underlying reference runs on, the illustrative rule set stands at forty-one notification rules after the first annual scrub retired nineteen — and the reliability engineer’s channel, at two messages a week, still gets answered.

Two messages a week is not a modest ambition. It is the design target.

The healthiest destination is a work order

Of all the places a notification can land, the best one is a work-management system.

An email is read or not read, and nothing records which. A work order has an owner, a priority, a state and a closure record — which means the finding becomes a tracked action, and, crucially, that somebody can later measure whether the notification changed anything at all.

That measurement is what closes the loop back to the decision that justified the measurement in the first place. A notification estate with no route into work management can never produce evidence about itself; it can only produce volume.

An exercise that costs an afternoon

Pull the last ninety days of everything your data platform sent to a human being. Every rule, every message, every recipient.

Then run four columns against each rule.

• ! Recipient: a named role, or a distribution list nobody owns? A list is not a recipient. Check whether anyone on it has replied, acted or forwarded in ninety days.
• ! Action: what did the recipient do differently? If the honest answer is 'noted it', the rule is not a notification and its retirement costs nothing.
• ! Rate: how many messages did this rule send, and what was the largest number it sent in one hour? The second number tells you whether flood behaviour was designed or discovered.
• ! Time-to-act: does the message state one? If priority is a colour or a word, the recipient is inferring urgency, and different recipients are inferring differently.

Then do the arithmetic that decides the channel’s future. Count the rules that produced a message nobody acted on, and count what fraction of total volume they represent.

In most estates the answer is uncomfortable and liberating at once: a minority of rules generate the majority of traffic, and almost none of that traffic changed a decision. Retiring them is free, requires no approval outside the data team, and immediately raises the signal value of everything left.

The second finding, which arrives more quietly, is the outage test. Look for the day a collector or broker failed. If that day produced hundreds of messages, the flood behaviour was never designed — and the next outage will do the same thing, to an audience with less patience.

Which of your notification rules could survive being asked what the recipient did last time?

The bright line between annunciation and notification, the borrowed alarm-management disciplines, and the audit-and-scrub method are from Industrial IoT and Data Architecture: From Sensor to Historian to Dashboard (Part 6: Dashboards and Analytics, section 6.3).