BAS alarms flag limits and events. Some costly faults keep every reading within range. A fan trips, a sensor flatlines, a temperature blows past a limit — and you get a page. But the most expensive problems in a building rarely break that loudly. They run quietly, inside the normal band, for years.
So the natural question is: if this kind of waste is common, why doesn't the building automation system already catch it?
The answer is structural. A BAS alarms on thresholds — fixed limits on individual points. That works for hard failures. It can't see faults that live in the relationships between points, where nothing crosses a limit but the building is quietly burning money.
What "normal" hides
Consider three of the most common offenders we find:
- Simultaneous heating and cooling. A unit heats and cools the same air at the same time. The space temperature stays perfectly within range — comfort holds, no alarm — while you pay for both. The cost is invisible at the point level and obvious only when you compare valve and damper commands against each other.
- A stuck economizer. An outdoor-air damper that should swing open on a cool day to provide free cooling instead sits at minimum. Mechanical cooling carries the load, the zone hits its setpoint, and the BAS reports a healthy building. The fault only appears when you compare damper position against outdoor-air temperature over hundreds of hours.
- Schedules that drift from occupancy. Equipment runs at 4am and through weekends for spaces that are empty. Every reading is in range; the building is simply conditioning nobody. You see it only by comparing runtime against how the building is actually used.
None of these typically trips an alarm. Left running, any one of them can cost thousands to tens of thousands of dollars a year in a single building. And the evidence for each is usually sitting in trend data the building already records — it just needs to be read closely enough.
The fault isn't in any one point. It's in the pattern between them — which is exactly what a threshold can't see.
From thresholds to patterns
This is the shift underway in building operations: from threshold alarms to data-driven fault detection and diagnostics. Instead of watching individual points for limit crossings, an FDD engine evaluates the relationships and behaviors across the whole system — valve versus temperature, damper versus weather, runtime versus schedule, this week versus design intent.
The hard part was never finding anomalies. It's making them trustworthy. A fault you can't explain is a fault no engineer will act on, and a feed full of false positives is worse than no feed at all. So the work that matters is in two places: ranking findings by dollar impact, severity, and ease of repair, and showing the evidence behind every one — the trend, the likely root cause, the recommended fix, the estimated dollar value.
That's the principle behind LeanFM. The Prescriptiv engine, developed from Carnegie Mellon research, screens the trend data your BAS already produces; AIR rolls the findings into one explainable score; and every finding opens to its evidence, its likely root cause, and guidance on how to resolve it.
The cheapest money in the building
What makes this waste worth chasing isn't just its size — it's that recovering it often requires no capital project. Many findings are schedule and sequence changes your team or a controls contractor can make in a normal maintenance window, often with no bond, no retrofit, and no new sensors. In one 220,000 sq ft school, issues like these added up to $105,000 a year in identified opportunity.
Much of this waste has been hiding in plain sight. What's changed is that the data can now be read closely enough to find it.