ML vs Rules-Based Anomaly Detection: Two Approaches for the Same Problem, Different Trade-Offs

Key takeaways

• Rules-based anomaly detection = thresholds and pattern rules written by engineers.
• ML anomaly detection = models learning normal patterns and flagging deviations.
• Rules catch known failure modes; ML catches what was not specified.
• Rules are auditable and easy to explain; ML can outperform on complex multivariate signals.
• Most plants benefit from both: rules for known patterns, ML for the rest.

Short answer: Rules-based anomaly detection uses thresholds and engineered patterns to flag known failure modes. ML anomaly detection learns normal patterns from data and flags deviations the engineers did not specify. Rules are auditable and easy to explain; ML often outperforms on complex multivariate signals. Most plants benefit from both — rules for the known, ML for the unknown. See also Machine Utilization vs Loading.

What rules-based does well

• Auditable. Every alert traceable to a specific rule.
• Explainable. Operators understand what triggered.
• Low data requirement. Works from day one.
• Tunable. Engineers adjust thresholds.

What rules-based misses

• Failure modes nobody anticipated.
• Multivariate patterns spanning many sensors.
• Subtle drifts within individual thresholds.
• Correlated changes across multiple signals.

What ML does well

• Catches unanticipated patterns.
• Multivariate analysis.
• Adapts to operating regimes.
• Improves with more data.

What ML struggles with

• Explainability. "Why did it alert?" is harder to answer.
• Data requirements. Needs months to years of history.
• Drift. Model retraining required.
• False positive rate. Tuning critical.

When rules win

• Well-understood failure modes.
• Regulated environments requiring auditability.
• New deployments without data history.
• Threshold-based standards (ISO 10816 vibration).

When ML wins

• Complex multivariate processes.
• Plants with rich historical data.
• Failure modes that engineers cannot fully specify.
• Operations where missed catches are very expensive.

The hybrid pattern

Most mature plants run both:

• Rules cover known failure modes with high confidence.
• ML catches the unknown.
• Disagreements between the two trigger investigation.
• ML alerts confirmed via rule investigation often become new rules.

The combination outperforms either alone.

Common mistakes

1. ML without history. Models trained on insufficient data fail.

2. Rules without coverage. Engineers do not specify all failure modes.

3. Replacing rules with ML. Loses auditability.

4. No tuning. False positive rate kills both approaches if not managed.

The auditability problem

ML in regulated environments requires explainability. Approaches:

• Use interpretable models (decision trees, generalized linear).
• Use deep learning with attention or feature importance visualization.
• Use ML to flag candidates, rules-based verification before action.
• Document training data and model validation.

Regulatory acceptance of ML is increasing but not universal.

The drift problem

Process changes, equipment ages, recipes evolve. Models trained on old normal behave differently against new normal.

Mitigation:

• Periodic retraining.
• Drift detection.
• Sliding window or online learning.

Common mistakes

1. ML alerts that nobody investigates. Like any detection system, alerts must be acted on.

2. No baseline for what model accuracy means. Without comparison, model performance is opaque.

3. Treating ML as plug-and-play. Models require data engineering, validation, monitoring.

Integration with CMMS

Both rules and ML alerts should generate CMMS WOs automatically. Confidence levels can drive priority (high-confidence to immediate WO; lower-confidence to investigation queue).

How OEE relates

Both approaches feed condition monitoring that affects OEE. Caught issues become planned maintenance; missed issues become unplanned downtime.

Plants comparing OEE Availability before and after a mature anomaly detection program typically see Availability move up.

How a modern OEE platform supports both

A modern OEE platform supports rules-based thresholds for known patterns and ML-based anomaly detection for unanticipated patterns, with both feeding CMMS workflow.

Fabrico's OEE module supports both rules-based and ML-based anomaly detection, with both feeding CMMS workflow for investigation and action.

See how Fabrico captures this automatically — explore OEE for manufacturing or book a demo.

Related reading

• Machine Utilization vs Loading
• Machine Builders vs Systems Integrators

Frequently asked questions

Should I always use ML?

No. Rules work well for known patterns; ML adds value for unanticipated.

How much data does ML need?

Highly variable. Common rule: enough to cover normal operating variation (seasonal, mix, etc.).

Is rules-based too simple?

No. Rules handle most known failure modes well. ML is for the residual.

How do I avoid false positives?

Tune confidence thresholds; require multiple signals; learn from operator feedback.

Can ML predict specific failure modes?

If trained on labeled failure data, yes. Without labels, only detects anomaly without specifying type.