If you cannot write one sentence naming what the existing threshold rule fails to catch and why, a model on that signal is buying duplicate coverage at higher maintenance cost. That sentence is the whole rubric. Everything below is a way of making it easier to write honestly, per anomaly class, before anyone chooses an algorithm.
Most industrial and energy metric sets are already covered — imperfectly, but genuinely — by threshold and rate-of-change rules that engineers trust and can explain during an incident review. That last property matters more than teams expect. A rule of the form “trip if bearing temperature exceeds 95 °C” survives post-incident scrutiny because its logic is legible to everyone in the room. The temptation is to treat AI anomaly detection as a superset of that layer: point a model at every tag in the historian, keep the rules running, and assume more coverage is strictly better. What you actually get is two alert sources for the same excursion, one of which nobody can explain.
What does “threshold-rule territory” mean in practice?
Threshold-rule territory is any anomaly class where a static or rate-based bound on a single signal captures the failure condition, and where the bound is derivable from physics, design limits, or regulatory constraint rather than from data. Pressure above a vessel’s rated maximum. Frequency deviation outside a grid code band. A tag flatlining at exactly its last value for ten minutes, which is a sensor fault, not a process event. In our experience these classes are where rules are not merely adequate — they are superior, because they are deterministic, cheap to maintain, and defensible.
A model earns its keep in the complementary space: anomalies with no stable static bound. Multivariate patterns where each individual signal stays inside its limits while the relationship between them breaks. Slow degradation masked by seasonality, where a solar inverter’s declining performance hides inside the expected summer-to-winter yield curve. Correlated-signal signatures where the anomaly is the shape of a joint excursion rather than any one magnitude.
The dividing line is not sophistication. It is whether a bound exists that a human can write down.
The per-class rubric
Run this per anomaly class — not per tag, and not per asset. Classes are usually a few dozen at most; tags run to thousands.
| Anomaly class | Signal characteristics | Verdict | Why |
|---|---|---|---|
| Single-signal excursion past a physical or regulatory limit | One tag, known bound, bound derived from design not data | Rule | Deterministic, explainable in incident review, no retraining |
| Rate-of-change spike (ramp, step, dropout) | One tag, bound on first derivative | Rule | Same; also catches sensor faults a model would learn as normal |
| Stuck / flatlined / out-of-range sensor | One tag, structural validity check | Rule | Data-quality logic, not a detection problem |
| Multivariate drift with all signals in-band | 3+ correlated tags, no individual violation | Model | No static bound expresses the joint condition |
| Seasonality-masked slow degradation | Strong periodicity, months-long trend | Model | Any fixed bound is either seasonally wrong or too loose to fire |
| Contextual anomaly (normal value, abnormal regime) | Value legal in one operating mode, not another | Model, or rule per mode if modes are few and labelled | Depends on whether the regime is a known enumerated state |
| Novel / never-seen failure signature | Rare class, no historical labels | Neither yet — evidence first | Neither rules nor a supervised model can be scoped against an event you cannot characterise |
The last row is the one teams skip. If a class has never occurred in your historian, a model trained on that historian has no basis for detecting it, and claiming otherwise is the fastest route to a muted alert channel.
Evidencing what the rules actually missed
The rubric’s honesty depends on evidence, not intuition. “Our rules miss things” is a feeling; “on 14 March the rules fired 41 minutes after the operator noticed the pattern, and here is the tag combination that had already diverged” is a scoping input.
A workable inventory pass looks like this:
- Enumerate the existing rules. Tag, condition, threshold, who set it, when, and whether it has fired in the last twelve months. Rules that never fire are either dead coverage or perfectly tuned, and you need to know which.
- Replay known incidents against the rule set. For each historical incident, record whether a rule fired, how long after the true onset, and whether an operator or a downstream consequence found it first.
- Classify each miss. Late detection, no detection, or detection buried under concurrent alerts. Only the first two are modelling opportunities; the third is an alert-budget problem.
- Name the unrepresented classes. Failure modes the team fears that have no historical instance. These get instrumentation and monitoring, not a detector.
The structured way to run this inventory — including how to evidence a miss rather than assume it — is the reliability-audit approach we bring to R&D engagements scoped to your problem. It is deliberately a pre-build activity: doing it after a proof of concept has been trained means the PoC’s scope, not the evidence, sets the boundary.
Running rules and a model side by side
The classification only pays off if the two layers land in one place. Two dashboards and two alert channels means the on-call engineer trusts the one they already know and mutes the other — which is exactly the outcome the rubric exists to avoid.
Practical shape: the rule layer stays where it is, inside SCADA or the observability stack, unchanged. Modelled detections enter as additional signal sources through the same path — the historian tag model, the OPC UA or MQTT boundary, a Prometheus-style metrics layer — carrying the same acknowledgement, suppression and escalation semantics as everything else. One rota, one inbox, one suppression rule. Our colleagues cover the integration mechanics in depth in integrating AI anomaly detection with existing SCADA and observability stacks; the point here is only that the per-class split is a precondition for that integration, because it tells you which detections are allowed to page at all.
Where a class is genuinely dual-covered — rule as a hard backstop, model as an earlier indicator — the rule wins the page and the model’s earlier signal becomes a lower-severity advisory. That ordering keeps the explainable layer authoritative during an incident review.
Does the split change for grid and solar telemetry?
Yes, and predictably. Discrete industrial processes tend to have well-defined operating modes and hard design limits, which pushes more classes into rule territory. Energy-grid and solar telemetry carry strong weather-driven and diurnal seasonality with far fewer enumerable modes, so a larger share of their degradation classes have no static bound worth writing — which shifts the balance toward modelled detection for slow-drift and performance-ratio classes specifically, while frequency, voltage and curtailment limits stay firmly on rules under grid code.
The rubric does not change. The distribution of classes across its rows does.
What this buys you
Two things worth measuring. First, the proportion of the metric set left on rules versus modelled — a smaller modelled surface means less labelling, less retraining, and fewer integration points to keep alive. Second, incremental detections attributable to the model on the rare classes the rules provably missed, judged by time-to-detect on those named classes rather than aggregate accuracy across all tags. Aggregate benchmark accuracy is dominated by the easy classes the rules already handle, which is precisely why it makes duplicate coverage look like a win.
The parent discussion of how that value gets measured, and why precision-recall on a historical incident set is the wrong instrument for rare events, sits in measuring the value of rare-event anomaly detection in industrial operations.
The open question we have not solved cleanly: how often should the classification be re-run? Operating envelopes shift, new assets arrive, and a class that was rule-territory at commissioning can drift into model territory as the plant ages. Annually feels arbitrary; after every major process change feels closer, but nobody has a clean trigger.
Frequently Asked Questions
What does “which operational anomalies are AI-detectable vs threshold-rule territory” mean in practice for an industrial or energy metric set?
Threshold rules catch violations of known bounds; AI models detect multivariate patterns and subtle correlations that no single threshold can capture. Operational Anomalies AI Detectable is best answered directly. Operational Anomalies AI Detectable answers cleanly when you separate two things. Operational Anomalies AI Detectable works like this. It means classifying anomaly classes — not individual tags — by whether a human-writable bound captures the failure condition. Classes with a physics-, design- or regulation-derived limit on one signal stay as rules; classes defined by joint behaviour across signals, or by trends hidden inside seasonality, are candidates for a model.
Which anomaly classes should stay as threshold or rate-of-change rules, and why is replacing them with a model usually a downgrade?
Single-signal excursions past a known limit, derivative spikes and dropouts, and sensor-validity checks. Replacing them is a downgrade because you trade a deterministic, retraining-free condition that is explainable in an incident review for a scored output that is neither, without gaining any coverage.
What signal characteristics indicate a class where a model genuinely adds detection coverage?
Absence of a stable static bound is the primary tell. Supporting indicators: three or more correlated tags where the anomaly is the broken relationship rather than any magnitude; strong periodicity that makes any fixed threshold seasonally wrong; and slow multi-month drift that no rate-of-change rule is tuned tightly enough to see.
How do we evidence that an existing rule set actually missed an incident class, rather than assuming it did?
Replay historical incidents against the current rule set and record, per incident, whether a rule fired, how late it fired relative to true onset, and whether a human or a downstream consequence found it first. A late or absent firing is evidence; a firing lost among concurrent alerts is an alert-budget problem, not a modelling one.
How do we run rules and a model side by side without creating two competing alert sources?
Leave the rule layer where it lives and insert modelled detections as additional signal sources on the same path, with the same acknowledgement, suppression and escalation semantics. On dual-covered classes, the rule owns the page and the model’s earlier signal becomes a lower-severity advisory.
Does this classification change for energy-grid or solar telemetry compared with a discrete industrial process?
The rubric is the same; the distribution shifts. Grid and solar telemetry carry heavier seasonality and fewer enumerable operating modes, so more degradation and performance-ratio classes fall to modelled detection — while frequency, voltage and curtailment limits remain rule territory under grid code.
What does the rubric look like as a repeatable per-tag decision an operations team can apply themselves?
Ask three questions in order: is there a bound a human can write down and defend? Does an existing rule already express it? If not, can you name in one sentence what the rule fails to catch and why? A tag that fails the third question goes back on rules, regardless of how interesting a model on it would be.
Four anomaly classes and their detection economics
Threshold rules catch sudden excursions cheaply, but multivariate drift and seasonality violations require learned baselines. Operational Anomalies AI Detectable rewards teams that measure first and argue later — start with the smallest instrumented slice and let the numbers settle the design.
