Published on :
September 17, 2026
by
Anisha Bhattacharjee
Views...
Picture a fairly ordinary scenario. An AC unit in a server room is drawing more power than it used to, and the BMS trend shows the room's temperature creeping up slightly during peak hours. The CMMS shows a filter cleaning was completed last week, ticket closed. The technician who checked the unit says it's cooling fine, no complaints.
The CMMS and technician say the unit is fine; the BMS trend is the outlier. The contract, meanwhile, creates little incentive to look further. It's tempting to treat the outlier as wrong, especially when the technician, the closed ticket, and the contract's incentives all point in the same direction.
But the problem isn't necessarily that one of these signals is wrong. The problem is what happens when they tell different parts of the story, and no one is responsible for putting those pieces together. If the unit deteriorates next month, that BMS trend may have been the earliest warning, and investigating further is exactly the effort the AMC doesn't reward.
Disagreement doesn't always look this obvious. Sometimes it's a single trend standing out against everything else, easy to spot and easy to overrule. Other times, every signal agrees, and the disagreement only surfaces once you ask whether the conclusion they all point to actually holds up. Either way, the real question isn't which system wins. It's whether the evidence is strong enough to say the problem is actually resolved.
The quieter kind showed up on a solar installation Xempla monitors.
Two inverters were producing meaningfully less than they should have, with DC current at roughly half of historical levels, around 7.1A against a historical 14.5A. Across the two inverters, that represented an estimated 10 kW of lost generation.
A work order was raised in the CMMS and the site team went out to investigate. They found one blown fuse on each inverter, replaced them, and closed the work order. At first, the evidence seemed to support the closure. After the visit, generation increased by roughly 2–3 kW per inverter. The engineer had found a physical fault and fixed it. The BMS was showing an improvement. The CMMS recorded the work as completed.
But those signals were only telling part of the story. The improvement happened during a different part of the season, when generation was naturally higher. Compared with the days immediately before the visit, the increase looked like recovery. Compared with what those inverters had historically produced during the same season and under comparable weather conditions, they were still underperforming.
So there was a disagreement, but not a simple BMS-versus-CMMS contradiction. The disagreement was between the conclusion the available signals seemed to support and what the broader evidence showed. The BMS was showing a real improvement. The CMMS was accurately recording completed work. The engineer had genuinely fixed a fault. But the historical performance evidence was saying the asset hadn't yet returned to where it should be. The first repair had worked. It just hadn't worked enough.
Under a contract structure focused primarily on completed work, this might easily have stayed closed. The BMS showed an improvement, which made the closure look reasonable. Nothing about that combination rewards asking whether "improved" also means "resolved."
Xempla connected the operational reading, the maintenance record, and the historical context. It compared post-repair performance against the site's own historical output for that season and comparable weather, rather than treating the increase in generation as proof that the problem was resolved. That comparison showed the work order needed another look. The team went back to the site and found two additional faulty fuses on each inverter that hadn't been identified during the first visit. Generation only returned to its expected range after those were addressed, and the final verification showed the inverters' DC current and power generation were consistent with their historical performance for the same season and comparable weather.
Without that additional verification, there was a perfectly reasonable path for the issue to end with the first visit. The engineer had completed the work, the CMMS had a closed ticket, and the BMS showed an improvement. No individual signal was necessarily wrong. There simply wasn't enough context around them to establish whether the outcome was good enough.
That's the more difficult problem in maintenance: a completed action is not the same thing as a verified outcome. And when nobody is explicitly responsible for making that distinction, the decision can effectively be made by the workflow itself, the ticket closes, the work is recorded, and everyone moves on.
The question, then, isn't just what the BMS says, what the CMMS says, or what the engineer says. It's who is responsible for deciding when the evidence is sufficient to call the problem resolved, and what that decision is based on. And that reasoning needs to remain visible after the person who made the call is gone. Otherwise, the next person who encounters the same asset inherits the records but not the context behind them.
The case points to a broader distinction between a system of record and a system of decisions. The CMMS records the work that was performed. The BMS records the asset's operating condition. Both are doing what they were built to do.
The gap appears when someone needs to answer a different question: did the work actually produce the outcome expected? Answering that requires more than another status field or another closed-loop workflow. It requires connecting the signals, establishing the right baseline, making the reasoning visible, and retaining the evidence behind the decision. That's what turns a collection of operational records into something an organisation can actually learn from.
Sometimes systems don't disagree because their data conflicts. They disagree because the conclusion drawn from that data doesn't hold once the right context is added. The goal, then, isn't to make every system agree. It's to make those moments visible enough to investigate, and important enough to retain.
A BMS (Building Management System) monitors and manages building systems and operating conditions, while a CMMS (Computerized Maintenance Management System) manages maintenance activities such as work orders, inspections, repairs, and maintenance history. A BMS shows what is happening to an asset; a CMMS records what maintenance was performed on it. When the two appear to disagree, it usually isn't because one is malfunctioning, but because each was built to capture a different part of the picture.
Neither system should automatically be treated as the source of truth. When BMS and CMMS information appears to disagree, the decision should consider the asset's current condition, maintenance history, operating context, and historical performance, alongside the outcome expected from the maintenance performed. The key question is whether the available evidence is sufficient to determine that the problem has actually been resolved.
No. Closing a work order confirms that the assigned maintenance activity was completed, but it doesn't necessarily prove the asset returned to its expected condition. Verification should compare post-maintenance performance against an appropriate baseline, such as historical or seasonal performance, and confirm the expected outcome was actually achieved.
Maintenance teams can verify a repair by comparing the asset's post-repair performance against an appropriate historical or expected baseline. The comparison may need to account for factors such as season, weather, and operating conditions. This helps distinguish genuine recovery from an improvement that partly reflects changing conditions rather than a full fix.
Connecting BMS and CMMS data provides the context needed to evaluate whether maintenance work produced the expected outcome. The BMS shows changes in asset performance; the CMMS provides the record of work performed. Combined with historical and operating context, this can reveal when an apparent improvement doesn't yet demonstrate full recovery.
Responsibility for this decision is not always explicitly defined. Depending on the workflow, the call may be made informally by whoever is closest to the issue. Without a defined process for weighing evidence before closing a work order, the decision can default to the most immediately available evidence, such as confirmation that the assigned work was completed.
A system of record, such as a CMMS, records what happened: work performed, assets maintained, and maintenance history. A BMS records operating conditions and equipment data. A system of decisions goes further by connecting those records, applying the right baseline for comparison, and preserving the reasoning behind a judgment call, so the next person facing a similar situation inherits the context, not just the data.
© Xempla. All rights reserved.