How failure-forecasting models for energy equipment actually get built: why label scarcity reshapes the whole problem, what lead time does to evaluation, and the leakage trap that makes first models look brilliant and ship useless. Public excerpt; the full teardown lives in the Builder library.
Our predictive maintenance deployments target up to a 40% reduction in unplanned downtime — and almost none of that number comes from model sophistication. It comes from framing the problem correctly before any model exists. Four decisions do the framing.
Decision 1 — You don't have a classification problem. Textbook framing says: label failures, train a classifier. Then you count your labels: a well-run site might log a handful of true failures per asset class per year. That's not a training set. The viable framings work from the data you do have in abundance — normal operation. Learn each asset's normal from historian telemetry (temperatures, pressures, vibration, run hours), and treat sustained drift from normal, in the direction of past failure signatures, as the signal. Anomaly-shaped framings survive label scarcity; classifier-shaped ones quietly overfit to five examples.
Decision 2 — Lead time is the spec, not accuracy. A perfect prediction two hours before failure is an alarm; the same prediction three weeks out is a scheduled repair during a planned window. Evaluation has to be written in operational terms: of the failures in the holdout period, how many were flagged with enough lead time to schedule? A model can win on every ML metric and lose on the only one that moves downtime.
Decision 3 — Features respect the maintenance log. Work-order history joins the telemetry — because a bearing that was just replaced resets its clock, and a model blind to maintenance events learns nonsense about aging. The maintenance log is half the feature set. It's also, at most operators, the messier half. Budget accordingly.
Decision 4 — Alerts become work orders, not emails. A flagged asset lands in the maintenance workflow with the trend, the suspected mode, and the lead-time estimate attached. Alert-to-inbox architectures die of fatigue within a quarter. Alert-to-work-order architectures change the downtime number.
The model saw the future and we didn't notice. First training pass: spectacular validation scores. Too spectacular. Post-failure telemetry — sensors going haywire during the failure — had leaked into training windows labeled as pre-failure. The model had learned to detect failures in progress, which operators can do by listening. Strict temporal cutoffs — features may only see data older than the prediction's lead-time horizon — cut the scores to honest levels and made the model actually useful.
One asset's "normal" was another's emergency. Identical compressor models, different sites, different baselines — altitude, duty cycle, and installation quirks meant a shared normal produced false alarms at one site and blindness at another. Per-asset baselining, with the fleet model as prior rather than the rule, fixed both directions at once.
The full teardown — the temporal-cutoff validation harness, the per-asset baselining approach, the maintenance-log cleaning playbook, and the lead-time evaluation template — lives in the Builder library.
Implementation detail, checklists, and the parts we'd rather not have public — for members.
Unlock with Builder