Anomaly Detection in Production: What an Explainable Alarm Must Deliver

The Red Light Is the Problem, Not the Solution

Any monitoring system can raise an alarm. The question that decides practical value is: what does the maintenance technician know after the alarm has fired?

With most systems: only that something is wrong. "Anomaly detected, confidence 0.87." That is not information — it is a search assignment. The technician walks to the machine and starts from zero. After the third false alarm of this kind, what happens in every plant happens: the alarms get clicked away. The most expensive monitoring system is the one nobody believes anymore.

The Four Elements of an Explainable Alarm

An alarm that saves work instead of creating it answers four questions — at the moment it is raised:

1. Which sensor? The named measuring point, not "the machine." The technician needs to know where to go.
2. What is the actual reading? The measurement that triggered the alarm.
3. What would the expected value be? The expected value for exactly this operating situation — not a static limit from the datasheet.
4. In which direction is it wrong? Too high or too low, rising or falling. For diagnosis, that is the difference between "bearing" and "cooling."

With our system, every alarm arrives with the five sensor values that contributed most to the decision — each with its reading, its expected value, and the direction of deviation. An alarm becomes a work instruction.

Why the Explanation Must Be Computed at Detection Time

A technical detail with major practical consequences: there are two kinds of "explainable AI." One computes the explanation at the moment of the decision — it is the actual reason for the alarm. The other reconstructs a plausible-looking justification after the fact for a black box's decision.

The difference sounds academic. It is not: an after-the-fact rationalization can be wrong — it then explains something that has nothing to do with the real trigger, and sends your technician to the wrong place. Ask every vendor when their explanations are computed. With us: at the moment of detection, as part of the same classification.

Why This Decides Your Project

Explainability is not a comfort feature. It decides three things:

• Crew trust. Maintenance people follow a system that argues traceably — and ignore one that plays oracle.
• False alarm cost. An explained false alarm is checked and dismissed in minutes. An unexplained one costs a walkdown.
• Acceptance and audit. In regulated environments, "the system just flagged it" is not a documentable justification.

The Vendor Meeting Checklist

Five questions that separate wheat from chaff:

1. Does every alarm name the specific sensor with actual and expected values?
2. Is the explanation computed at detection time — or reconstructed afterwards?
3. Does detection also work for slow drift that never crosses a fixed limit?
4. Does the explanation run fully on-premise — or does it need a cloud?
5. What happens under uncertainty: does the system flag "uncertain, please review" — or does it guess?

On the last question, our position: where confidence is insufficient, the system asks — instead of guessing. An open question to a human beats a wrong autonomous action.

The fastest way to feel what this is like on your own equipment: the Process Monitoring module (fixed price after scoping, 5 weeks) — or a 30-minute conversation about your signals.