Published on :
June 5, 2026
by
Anisha Bhattacharjee
Most CMMS and BMS platforms were built to record and control, not to reason. Work orders live in the CMMS. Alarms fire in the BMS. Asset records sit in the CAFM. Financial approvals route through the ERP. Every system does its job. None of them does the one job that determines whether the whole operation runs well: deciding what should happen next, who owns that decision, and whether it was the right call.
That gap is not a data problem. FM operations generate more data than most teams can act on. It is a governance problem. And at portfolio scale, an ungoverned FM operation is one where the same decision gets made differently on every site, by whoever happens to be on shift, with whatever context they have to hand.
The governance gap has always existed. Three changes have made it increasingly costly to ignore.
First, portfolio scale. Inconsistent decision-making across dozens of sites does not stay inconsistent in small ways. It compounds into material SLA exposure, unplanned maintenance spend, and operational risk that is difficult to trace back to a single point of failure because there is no single point: the failure is in the absence of a consistent decision framework.
Second, reporting obligations. Regulators, and institutional asset owners increasingly require organisations to demonstrate how operational decisions were made, not simply whether outcomes were acceptable. A work order log is not sufficient. A decision audit trail is.
Third, AI adoption. As AI tools enter FM operations, the question is not whether AI can recommend a maintenance action. It can. The question is whether your organisation has a framework that determines which recommendations get acted on, by whom, and with what sign-off. Without that framework, AI accelerates decision-making without governing it.
Without governance, AI creates faster decisions. With governance, AI creates accountable decisions.
A governance layer is the operational architecture that sits above your existing CMMS, BMS, CAFM, IWMS, and ERP systems and governs how decisions are made using the data those systems produce. It does not replace any of them.
Your CMMS remains the system of record for maintenance activity. Your BMS remains the control layer for building plant. The governance layer becomes the System of Decisions for CMMS and PPM operations: the framework that determines what action should be taken, who owns it, and how success will be measured.
The System of Decisions is Xempla's term for the governance architecture that sits between operational data and operational action. It ensures maintenance, compliance, asset, and SLA decisions are made consistently, measured against policy, and recorded with clear accountability.
The distinction between a system of record and a System of Decisions is the most important one in FM architecture:
A CMMS records what happened. A System of Decisions for PPM and SLA governance determines what should happen next. Both are necessary.
Building a governance layer is not a rip-and-replace project. You do not migrate your CMMS. You do not reconfigure your BMS. You do not retrain your FM team on a new system of record.
What you do is add a decision architecture above the systems you already have.
In practice this means four things. You connect your existing data sources — CMMS, BMS, CAFM, ERP so the governance layer can read across all of them without disrupting how those systems currently operate. You define the policies, thresholds, and SLA commitments that decisions will be measured against. You configure the escalation logic that determines which decisions can be processed without individual review and which require a named sign-off. And you set up a way to track what actually happened after each decision, so the layer gets more informed over time.
That is the creation sequence. The five components below map to it in order.
The governance layer connects to your existing CMMS, BMS, CAFM, IWMS, and ERP systems and brings their data into a single operational picture. No system is replaced or restructured. The one requirement that makes this work is consistency in how assets are identified: the cooling unit in your CMMS and the same unit sending alarms through your BMS need to be recognised as one asset, not two separate data points. Without that, the governance layer cannot reason across systems.
Every action processed through the governance layer — a deferred PPM, a BMS alarm override, a reactive work order raised outside schedule — is recorded with full context: who triggered it, what information was available at the time, what rule applied, and what was decided. This is what converts a record of activity into a record of governance. For organisations operating in regulated sectors, this distinction matters enormously: it is the difference between showing that a decision was made correctly and simply asserting that it was.
The governance layer checks every decision against the policies your organisation has defined: SLA commitments, regulatory requirements, asset criticality classifications. When a decision would cross a line — for example, a planned maintenance visit on a critical cooling system being skipped with no recorded rationale — the layer flags it to the responsible manager before it is quietly filed away. The decision does not disappear into a log. It requires a named person to own it.
Not every FM decision carries the same risk, and a well-designed governance layer does not treat them the same way. Routine, low-risk actions can be processed without requiring a human to review each one individually. Decisions involving critical assets, policy boundaries, or significant cost implications are routed to the appropriate FM professional or operational leader for review and sign-off before anything happens. AI can surface the recommendation and flag the context. The governance layer determines who is responsible for the final call and ensures that responsibility is recorded.
After a decision is acted on, the governance layer records what actually happened. Did the maintenance hold? Did the issue recur? Did the response resolve the underlying problem? Over time this creates an operational memory: the layer is not making decisions in a vacuum but drawing on a growing record of what has worked and what has not across your portfolio.
A CMMS manages the execution of maintenance: work orders, PPM schedules, asset records. A governance layer sits above it and governs how decisions about that maintenance are made, who is accountable for them, and whether they were the right calls. The CMMS remains the system of record. The governance layer becomes the System of Decisions operating above it.
No. The governance layer connects to your existing systems as a reader of data, not a replacement for them. Your CMMS, BMS, CAFM, and ERP continue operating exactly as they do today. Nothing is migrated and nothing is switched off.
Most building management systems can share data through a standard communication protocol without requiring vendor involvement or changes to existing hardware. The governance layer reads that data — live building telemetry, alarm feeds, equipment status — and incorporates it into the decision framework alongside CMMS and other operational inputs.
The governance layer determines ownership based on the nature of the decision. Routine low-risk actions are handled without individual sign-off. Anything involving a critical asset, a policy boundary, or a significant cost implication is routed to a named FM professional or operational leader before it proceeds. Every decision, and who owned it, is recorded.
To see how the governance layer performs in live FM environments, read our case studies from healthcare, commercial, and institutional asset portfolios.
Paragraph
Block quote
Ordered list
Unordered list
Bold text
Emphasis
Superscript
Subscript
© Xempla. All rights reserved.
Terms & Conditions