Improving anomaly detection and trust in wind-turbine monitoring

Monitoring sits between the data and the decision

A wind fleet is a firehose of telemetry. Hundreds of turbines stream vibration, temperature, and performance data every second, and machine-learning models sit downstream trying to pull real anomalies out of the noise. But the last link in that chain is always a human: an engineer who has to read the model's output, weigh it against context, and commit to an action.

That decision point is where the money is. A missed signal becomes unplanned downtime. A false alarm burns a maintenance crew on a healthy asset. In a safety-critical environment, a wrong call compounds fast.

The system detected. It just never explained.

Three failures stacked on top of each other, and none of them were really about the interface:

• Detection was reactive, not anticipatory. Alerts fired only once a threshold was breached. Until that moment the system was silent, so investigation always started after the cheap window to intervene had already closed.
• The anomalies themselves were gradual. Failures crept in as small, compounding drifts over days or weeks. A binary "anomaly: yes/no" flag couldn't represent something that was 30% of the way to a problem.
• The AI flagged but never reasoned. No confidence, no uncertainty, no "here's why." So engineers did the rational thing in a low-trust setting: they ignored the model and re-verified everything by hand.

The real problem was decision confidence under uncertainty

This is the move the whole project turned on. The data existed and the models worked. Detection wasn't the gap. The gap was whether a skeptical engineer could act on a signal, quickly, with real stakes on the line. Detection without interpretability is an incomplete system. So the brief quietly changed: not "build a better alert," but "build something that earns the trust of people who have very good reasons to be skeptical."

Designing for trust, not just detection