Every predictive maintenance pitch sounds the same right now. Feed a model your equipment data, let it learn, watch it forecast failures before they happen. It’s a good pitch. It’s also not the only way to do this, and for a lot of buildings, it’s not even the best way to start.
There’s a quieter category of predictive maintenance that doesn’t involve a model at all. It’s standards-driven instead of model-driven, and it deserves more attention than it gets, because the standards it’s built on already contain most of the diagnostic knowledge a facility team actually needs.
What “Predictive” Actually Means
Strip away the marketing and predictive maintenance means one thing: trigger the maintenance action based on the equipment’s actual condition, not on a fixed date on a calendar. That’s the whole idea. Machine learning is one way to determine condition. It’s not the only way.
The other way is older, and it’s been sitting in plain sight in the specifications the industry already relies on.
The Standards Already Contain the Diagnostic Logic
Facility teams have spent decades codifying exactly what to check on a piece of equipment, why it matters, and what tolerance separates healthy from failing. That knowledge already exists in published standards:
SFG20, maintained by BESA in the UK, is the industry standard maintenance specification for building engineering services, a library of more than 700 schedules covering over 70 asset types, translating legislation and codes of practice into specific, actionable maintenance tasks.
DA19, published by AIRAH in Australia, is the equivalent reference for HVAC&R maintenance, now in its fourth edition, and the definitive source for the region for over twenty years.
ANSI/ASHRAE/ACCA Standard 180, the North American parallel, establishes minimum HVAC inspection and maintenance requirements to preserve thermal comfort, energy efficiency, and indoor air quality in commercial buildings.
Worth being precise here: none of these three are predictive maintenance standards. All three are fundamentally preventive and scheduled by design, they tell you what to check and how often. What they also contain, buried in the task detail, is the actual engineering logic: the specific condition, tolerance, or symptom that made someone decide this check mattered in the first place.
From Calendar to Condition
That’s the part worth extracting. A scheduled task under SFG20 or Standard 180 might say “inspect belt tension quarterly.” The standard’s underlying logic isn’t really about the calendar, it’s about belt tension drifting out of acceptable range. The quarterly interval is a proxy, a best guess at how often that drift is likely to matter, applied uniformly because nobody had a better way to know in advance.
Once you have continuous data from the equipment itself, you don’t need the proxy anymore. You can evaluate the standard’s actual condition, belt tension, drift, whatever the real trigger is, directly and continuously, and only generate the work order when the condition the standard cares about is actually present. Same diagnostic logic the industry already agreed on. Different trigger. Calendar becomes condition.
No model has to learn anything to do this. No historical failure log is required. The rule already exists, published, peer-reviewed in the sense that an entire industry vetted it, and it just needs to be evaluated against real numbers instead of a date.
Where This Approach Has a Real Edge
This isn’t a lesser version of AI-driven predictive maintenance. In a few specific ways, it’s a stronger starting point.
It’s explainable. When a standards-driven rule fires, you can point to the exact clause and the exact measured value that triggered it. Try getting that same clarity out of a black-box model, and you’re often stuck with a confidence score and no real answer for a skeptical technician asking why.
It doesn’t need a training period. A model needs history to learn from, and as we’ve written about elsewhere, most buildings don’t have clean enough historical data to train one well. A standard doesn’t have that problem. It was already validated against decades of industry experience before your building’s data ever entered the picture.
It’s inherently tied to compliance. If you’re already maintaining to SFG20, DA19, or Standard 180 for legal or insurance reasons, a rules engine built on that same standard gives you a maintenance program that’s condition-based and audit-ready at the same time. That’s a harder combination to get from a general-purpose ML model that wasn’t built with any particular standard in mind.
Where AI Still Earns Its Place
None of this is an argument against machine learning in facilities. It’s an argument for sequencing. A standards-driven layer catches the failure modes the industry already understands and has written down. AI earns its value on top of that foundation, finding the failure patterns nobody’s published a standard for yet, correlating symptoms across systems that no single spec was ever written to cover, catching the genuinely novel problem instead of the well-documented one.
Skip the standards-driven layer and go straight to a model, and you’re asking AI to relearn things the industry already knows, using data your building probably doesn’t have enough of yet. Build the standards-driven layer first, and the model gets to focus on the harder, more interesting problem it’s actually suited for.
The Practical Version
If you’re evaluating a maintenance strategy and want to see what a standards-driven ruleset actually looks like against your own building’s data, we’re happy to walk through it. It’s a more concrete conversation than most vendors offer, because the logic isn’t a black box. It’s a standard you can read.