Ranking unusual building operation without failure labels

What meter, weather, and metadata proxies can support, what detector agreement means, and why this is not equipment fault detection.

The ASHRAE Great Energy Predictor data gives me 2.88 million hourly chilled-water meter readings across 497 buildings, plus weather and building metadata. It does not give me equipment-level telemetry, compressor measurements, or failure labels. That boundary changes the question. I can rank unusual building operation in this dataset, but I cannot claim that I detected a failing chiller.

Name the proxies before interpreting them

My HVAC background shaped the questions I wanted to ask, but the source columns do not support direct thermodynamic measurements. The four engineering-flavored fields are explicit proxies:

• a cooling-efficiency proxy built from chilled-water meter demand and a weather-based denominator, not measured COP;
• outdoor air minus a fixed 13 C setpoint, not supply and return water delta-T;
• outdoor air minus dew point, not a refrigerant-circuit delta-T;
• meter demand divided by a floor-area capacity estimate, not measured equipment load ratio.

Rolling means and standard deviations over 24 hours and 7 days describe how those proxies move through time. The names matter because a plausible engineering analogy is not the same thing as a measured equipment state.

An Isolation Forest scores each reading for anomaly structure. The output is converted to a rank-relative 0 to 100 display score. It is an anomaly ranking, not a probability of health or failure.

Decision one: judge each unit against its own baseline

A raw anomaly score answers “is this reading strange for the fleet?” That is the wrong question. Some units always ran hot; some buildings always ran heavy loads. At Rheem you never judged a compressor against the fleet’s vibration baseline, only against its own commissioning signature.

So the score is normalized per building: each building’s raw scores are mapped through that building’s own 5th and 95th percentiles. A low display score means unusual relative to that building’s recorded pattern. It does not mean the equipment is unhealthy, and without labels I cannot quantify a false-alarm reduction.

Decision two: keep a second detector as witness

With no labels, there is no accuracy number, and anyone who quotes one should be asked where it came from. What you can do is triangulate. A Local Outlier Factor model, which defines anomaly by local density rather than isolation depth, scores the same readings independently. The two detectors agree on 91.3% of a 100,000-reading sample.

Agreement is not correctness. What it establishes is that the anomaly structure mostly does not depend on which definition of “strange” you pick, and the 8.7% where they disagree is exactly the set where the call is genuinely ambiguous. The contamination setting got the same treatment: run at 0.02, 0.05, and 0.10, and check that everything flagged at the strict setting stays flagged at the middle one. It does, which means the flagged population is not an artifact of one knob.

The finding I didn’t expect

The strongest SHAP contributor across the sample is the 24-hour rolling standard deviation of the cooling-efficiency proxy. That says the model relies heavily on short-horizon variability in a derived meter-and-weather feature. It does not establish short cycling, valve hunting, sensor failure, or any other equipment fault. Those are hypotheses that would require telemetry, maintenance records, and labeled validation.

What this can and cannot say

It cannot say “this unit will fail in N days,” diagnose a compressor, or tell a maintenance planner where to dispatch a technician. It can surface building-period readings that are unusual relative to each building’s own recorded operation and show whether a second unsupervised method agrees. That is useful for data-quality review, energy-analysis triage, and deciding where richer instrumentation may be warranted.

The live board at hvac.alvinalias.com shows rank-relative scores and the detector cross-check. The repo, with the proxy definitions, sensitivity checks, and normalization code, is at github.com/aalias01/hvac-equipment-health.