Nuisance alarms: why operators stop listening, and how excuses in the rules help

In one minute

• When most alarms turn out to be nothing, operators stop trusting them. A real alarm then arrives in a crowd of false ones.
• The fix is not a quieter alarm. It is a rule that knows the ordinary, harmless reasons a reading looks alarming.
• In quorum, a benign explanation is an excuse. A live excuse undercuts the step from a reading to a fault, so no alarm fires.
• Evidence that rules out the excuse rebuts it, and the alarm comes back. A benign explanation must never be able to cancel a real alarm carelessly.
• Severity decides which conclusion wins when two conflict, so a weak excuse cannot override a serious fault.

Who this is for

This guide is for anyone who lives with an alarm system: the operator who answers the alarms, and the engineer who sets them up. If you have ever watched an alarm panel light up for the hundredth time over something that turned out to be normal, this is about that.

Two words first. A reading is one thing an instrument reports, such as vibration being above a threshold. A conclusion is something the rules infer from readings, such as "the pump is cavitating." A nuisance alarm is a conclusion that fires when nothing is actually wrong.

Why operators stop listening

The failure this addresses is well documented, and it is not that alarm systems are inaccurate. It is that they cry wolf. The quorum README, in its "Why this rather than a model" section, puts it this way: predictive-maintenance and alarm systems generate so many unactionable alerts that operators stop reading them. It cites ISA-18.2 work putting nuisance rates above 80% in surveyed plants, and false-positive rates of 40 to 90 percent reported for predictive maintenance in power generation.

Read those figures as the README presents them: surveyed plants and reported rates, not a measurement quorum made. The point is the human one. If four alarms in five are nothing, the fifth, the real one, arrives with no credibility. The README's conclusion is blunt: a system that is right more often but still cannot say why does not fix that.

The quiet temptation is to raise the threshold so fewer alarms fire. That trades one danger for another. A higher threshold is a slower alarm, and the fault you were watching for now has to get worse before anyone hears about it.

The real problem: harmless reasons that look alarming

Most nuisance alarms are not instrument noise. They are real readings with an ordinary explanation. The pump rulebook in the quorum repository carries a note from its source document saying exactly this: the dominant nuisance-alarm cause is a benign duty-point change, not sensor noise.

Here is what that means on a pump. When the plant changes how hard the pump is working, the duty point moves. Vibration rises, the operating point shifts off the pump curve, and the readings start to look like a developing fault. Nothing is wrong. The pump is doing what it was asked to do. An alarm system that only watches the vibration reading will fire anyway, because it does not know the duty point changed.

An experienced operator knows. "We just changed the load, that is why it is buzzing." The knowledge is in the operator's head, not in the rules. So the rules keep crying wolf, and the operator keeps overriding them, until one day the buzzing is not the duty point and the override is a mistake.

Putting the explanation in the rules

quorum's answer is to write the benign explanation into the rulebook, where the machine can use it. In quorum a benign explanation is called an excuse. An excuse is supported by its own readings, and when it is live it undercuts the step from a reading to a fault. Undercutting attacks the inference, not the reading: the vibration is still there, but the reason to treat it as a fault has been removed.

The pump rulebook has three excuses. These lines are from casebook/pump/pump.cb:

excuse duty_change "pump changed duty point"    needs duty_changed
excuse offdesign   "running off design point"   needs throttled
excuse resonance   "structural resonance"       needs near_critical

And this is where each excuse applies:

duty_change undercuts cavitation impeller_defect misalignment
offdesign   undercuts cavitation
resonance   undercuts misalignment bearing_wear

Read the first line in plain words. If the duty point changed, do not treat the vibration as cavitation, impeller wear, or misalignment. The reading is real; the alarm is suppressed, because there is a known, harmless reason for it. The operator's "we just changed the load" is now the machine's reasoning too, and it is written down, reviewed, and signed for, not held in one person's memory.

An excuse must not be able to cancel a real alarm

An excuse that silences alarms is a dangerous thing if it silences them carelessly. A duty change is a benign explanation for a buzz. It is not a benign explanation for everything. If a duty change could cancel any alarm, you would have built a very convincing way to ignore a failing pump.

So the excuse has to be defeated by evidence that it does not explain. In quorum, a reading that rules out the excuse rebuts it. Rebutting attacks the conclusion: the excuse is knocked out, and the fault it was suppressing comes back. These lines are from the same file:

suction_low       rebuts duty_change offdesign
head_low          rebuts duty_change

In plain words: a duty change explains a buzz, but it does not explain low suction pressure or a drop in developed head. If suction is low, the "we just changed the load" story no longer holds, the excuse is defeated, and the cavitation alarm is reinstated. The excuse can quiet the nuisance, but it cannot survive the discriminating evidence that says the fault is real. That is the whole discipline: a benign explanation earns its silence only until something it cannot explain shows up.

Severity: which conclusion wins

There is a second guard. When two conclusions conflict and neither clearly defeats the other, something has to decide which one the machine acts on. quorum uses severity, a number a reliability engineer writes on a claim to say how serious it is. The README describes severity as an ordering that breaks ties between conflicting conclusions, the way a reliability engineer already ranks them.

Severity is deliberately cautious. The quorum safety case records a measured probe (claim SEV-1): a weak attack, severity 2, against a serious claim, severity 9, is cancelled, and the safe action holds. At equal severity the attack stands. In plain words, a minor benign explanation is not allowed to knock out a major safety conclusion just because it happens to apply. The serious thing wins unless something equally serious argues against it. Dropping the weaker attack makes the safety function act more often, not less. That is the right direction for a safety function to lean.

The safety case also states the limit, and it is an honest one: the severity numbers themselves are an author's judgement that no tool can check. quorum enforces how severities interact. It cannot tell you that a hot bearing deserves a 7. That is engineering, and it belongs to the person who signs the document.

What quorum does not do

quorum does not decide, on its own, which explanations are benign. A person writes each excuse, names the readings that support it, and names the evidence that must defeat it. If you forget to let a fault be argued against, quorum notices: it reports when nothing in the rulebook can challenge a conclusion, because a rulebook of hard rules with no excuses and no doubts is just an alarm list wearing a reasoner's coat.

It also does not measure whether your thresholds are right, or whether the duty-change reading truly comes from the right signal. The full check proves the rules behave as written. Confirming that the readings mean what you think they mean is the commissioning step on the real machine, and the README notes no plant has done that yet.

Finally, the figures quoted above about alarm rates are from the sources the README cites, reported for surveyed plants and for power-generation predictive maintenance. They describe the problem quorum is built for. They are not claims about quorum's own performance on a plant, because quorum has not run one. For how the full check guarantees an alarm fires in every situation it should, see checking every situation.