The False Positive Problem: Why Maintenance Teams Stop Trusting Predictive Alerts

Three false alarms in a row and your maintenance supervisor starts ignoring the system. We have seen this happen twice in our pilots, and it follows the same pattern each time. The alerts fire, technicians dispatch, equipment is healthy, trust erodes. By the time a real failure approaches, the alerts are filtered out by the people they are supposed to reach. The root cause is never the algorithm. It is the baseline calibration — and it is fixable before trust is lost, but only if you act in the first two weeks.

What Actually Causes False Positives in Condition Monitoring

The most common cause of false positives in vibration-based condition monitoring is not a bad model — it is a baseline that doesn't represent the asset's full operating envelope. If the 14-day calibration window captures the asset running at 60–80% load during normal production hours but does not capture the surge conditions that occur at shift changeovers or during startup, the anomaly model will flag the surge vibration signature as abnormal. It is abnormal relative to the baseline, but it is operationally normal for the asset.

The second most common cause is physical changes to the monitored equipment that occurred after baseline calibration. A lubrication event — greasing a bearing between calibration and live monitoring — changes the vibration signature. A belt replacement changes the frequency content. A filter cleaning event changes the acoustic emission level. The model was calibrated on the pre-event signature and will report the post-event signature as anomalous even when the equipment is healthier after the maintenance event.

The Precision-Recall Trade-Off in an Industrial Context

Every anomaly detection threshold is a trade-off between sensitivity (catching real failures early) and specificity (not alarming on normal variations). Setting the threshold low increases sensitivity and increases false positive rate. Setting it high reduces false positives and increases the risk of missing early-stage failures. There is no threshold that simultaneously achieves zero false positives and zero missed detections — anyone claiming otherwise is either using a small test dataset or is optimizing for a metric that doesn't reflect field conditions.

The correct question is not "what threshold gives zero false positives?" but "what false positive rate can the maintenance team tolerate before losing confidence?" For most maintenance teams we work with, the tolerance is approximately one false positive per 30 true positives — a positive predictive value (PPV, also called precision) of about 97%. Below that, the false alarm rate disrupts maintenance planning enough to degrade confidence in the system. Above it, the detection sensitivity is sufficient to catch early-stage failures reliably.

Calibration Re-runs: When and How

Any maintenance event that changes the equipment's vibration signature is a trigger for baseline recalibration. EdgeRun tracks maintenance events logged in the connected CMMS and automatically initiates a recalibration window when a work order is closed for a monitored asset. The recalibration window is 7 days by default (shorter than the initial 14-day window because the asset's approximate normal signature is already known — only the delta from the maintenance event needs to be captured).

During recalibration, EdgeRun operates in "observation mode" — collecting data but not generating alerts. This is the correct behavior because the alert threshold is undefined until the new baseline is established. Maintaining the pre-maintenance-event baseline during the recalibration window would guarantee false positives if the maintenance improved the bearing condition. Observation mode during recalibration is a feature, not a limitation. As we describe in detail in our article on baseline calibration, this transition period is often misunderstood by site teams.

Multi-Condition Baseline Modeling

For assets with distinct operating modes — a pump that operates at two different speed setpoints, or a conveyor that runs at different loads depending on which upstream process is active — a single aggregate baseline is a poor representation of normal behavior. The anomaly model trained on the aggregate baseline will have a wider normal distribution, which means lower sensitivity to early-stage degradation at any specific operating condition.

EdgeRun's multi-condition baseline clustering automatically segments the baseline data into operating regime clusters using k-means on the concurrent load and speed data. The anomaly model is trained separately for each cluster, and inference selects the appropriate cluster model based on the current operating point. This typically improves detection sensitivity by 15–20% compared to a single aggregate baseline on assets with two or more distinct operating regimes.

Alert Confirmation Windows: Reducing Nuisance Trips

A single anomaly score exceedance does not necessarily indicate a developing failure. Transient events — a brief overload, a passing mechanical impact from an adjacent process, a momentary instrument noise spike — can produce single-sample exceedances that are genuine anomalies from the model's perspective but not actionable maintenance events. Generating an alert from a single exceedance produces nuisance trips that erode trust.

EdgeRun's default alert confirmation window requires sustained anomaly score exceedance for a configurable duration before generating an alert. The default is 15 minutes of sustained exceedance at the Watch threshold, 5 minutes for Caution, and immediate (single detection) for Warning and Critical. This duration-based confirmation eliminates transient false alarms while maintaining fast detection for rapidly progressing failures. The confirmation window durations are configurable per asset class — rotating equipment that fails gradually uses longer windows; equipment that can fail abruptly (high-cycle fatigue, corrosion-through) uses shorter ones.

Feedback Loop: Closing the Loop on Alert Outcomes

The most important tool for reducing false positives over time is a structured feedback loop that records the outcome of each alert. When a technician dispatches on a predictive alert and finds healthy equipment, that observation needs to return to the anomaly model as a labeled false positive. When they find a genuine failure precursor, that is a true positive. Without this feedback, the model cannot improve — it continues firing on the same conditions that produced false positives before.

In EdgeRun's workflow, alert disposition is captured when a CMMS work order is closed. The technician selects one of four outcomes: No Defect Found, Defect Found and Addressed, Defect Found and Deferred, and Cannot Determine. These outcomes flow back to the EdgeRun alert history and are used to compute running PPV metrics for each asset. If a specific asset's PPV drops below the 90% threshold over a rolling 30-day window, the system flags the asset for threshold review and, optionally, triggers an automatic baseline recalibration. This automated self-adjustment is the mechanism that keeps false positive rates stable over the system's lifetime rather than degrading as operating conditions drift.

The Human Factors Component

The algorithm is only part of the false positive problem. The other part is how alerts are presented and responded to. An alert that arrives as an email to a shared maintenance inbox is more likely to be missed or attributed to the wrong person than an alert that generates a CMMS work order assigned to a specific planner. An alert with no context — just "Anomaly detected on P-107" — is more likely to be dismissed than one that says "P-107: Bearing outer race signature elevated. Health index: 71. Estimated 18–36 hours to Warning threshold. Similar pattern preceded failure in 2 of 2 historical events on this asset class."

Reducing false positives is partly a technical problem and partly a communication design problem. We have found that the same alert volume is perceived as manageable or overwhelming depending on whether the alerts carry enough context for the maintenance planner to act confidently. Alerts that require additional investigation to interpret feel like work; alerts that arrive with diagnosis context feel like help. The investment in alert content quality returns directly in user adoption and system confidence.