Alarm fatigue is an information architecture problem

Operators in high-alarm environments develop unconscious filtering. They learn, from experience, which alarms to act on and which to ignore. This is not a failure of discipline or attention. It is the rational adaptation of skilled professionals to a system that produces more noise than signal.

The consequence is that the filtering which protects operators from noise also filters out genuine early signals. And because the filtering is unconscious, neither the operator nor the organisation knows exactly where the line is being drawn.

How alarm fatigue develops

Alarm fatigue follows a predictable pattern. A system is configured with thresholds that make sense at commissioning. As the operation evolves — process changes, asset aging, seasonal variation — many of those thresholds become miscalibrated. They fire too often, too early, for things that turn out not to matter. Operators learn which alarm types are usually false positives and begin deprioritising them.

Meanwhile, the thresholds that are correctly calibrated continue to fire. The operator pool now has a filtering heuristic that mixes the genuinely important alarms with the ones they have learnt to ignore, and the heuristic is invisible to anyone outside the operator's head.

New operators join. They have no heuristic. They either act on everything — which is exhausting and builds its own kind of fatigue — or they adopt the heuristic from senior colleagues, including the parts that are no longer appropriate.

The structural problem

Alarm fatigue is not caused by lazy operators or poor procedures. It is caused by an information architecture that produces alarms at the level of individual signals, without context, without correlation, without any model of what is normal for this specific asset at this specific operating state.

A well-functioning alarm system would produce alerts that are always significant, always contextualised, and always actionable. In practice, most industrial alarm systems produce alerts that are sometimes significant, rarely contextualised, and often require investigation to determine whether action is needed. Operators adapt to this. The adaptation is called alarm fatigue.

What correlated alerts change

The pump P04 case: four alarms logged as four events. The historical data shows a single correlated sequence — four signals all deviating from their learned baselines in a statistically related pattern, all pointing to one developing fault in one component.

A single correlated alert with context — what is deviating, what else is correlated, what the likely cause is, what action is recommended — is a fundamentally different information unit than four individual threshold crossings. It is actionable on first reading. It requires no investigation to determine whether it is significant. It does not require an experienced operator's heuristic to interpret.

That is the architectural change. Not more alarms. Not better thresholds. A different model of what an alert is: a decision-ready briefing derived from the operational fingerprint, not a binary signal from a static threshold.

The quiet signal problem

There is a second consequence of alarm fatigue that receives less attention: the signals that never fire at all.

The deviation pattern that appears two hours before operational impact in the salmon producer case — the water chemistry anomaly that no threshold ever caught — is invisible to the alarm system because the threshold is calibrated for failure, not for the pattern that precedes failure. The operator never sees it, not because they would have ignored it, but because the system never told them.

Solving alarm fatigue requires not just reducing the noise of false positives, but increasing the signal of true early warnings. The two problems share an architectural root and the same architectural answer: an intelligence layer that reads the operational fingerprint, maps correlations across signals, and generates alerts that are few, significant, and contextualised.