Published on :
June 26, 2026
by
Anisha Bhattacharjee
Imagine Rajan has managed the same portfolio for eleven years. He does not just know the assets. He knows how this portfolio behaves: which patterns are worth acting on, which signals have consistently turned out to be non-critical on this portfolio, and which decisions look straightforward on paper but are not. That kind of knowledge is not in any system. It lives in him.
He is retiring in eight months.
Every portfolio is unique. Its assets, its failure history, its operational quirks, the reasoning behind years of decisions that shaped how it runs today. The engineer who has been on that portfolio the longest often understands parts of it that no one else does.
According to IFMA, more than 45 percent of facility management professionals globally are expected to retire within the next decade, taking that understanding with them.
When that person leaves, the organisation keeps the data. It loses the knowledge built on top of it.
The instinct is to document more. Better SOPs, more thorough handover notes, structured knowledge-transfer sessions before someone exits. These are reasonable responses and they are worth doing. But they have a ceiling.
Facilities teams already have significant data. Asset records, maintenance histories, work orders, inspection reports, alarm logs, sensor readings. Most organisations are not short on operational information. What they cannot seem to hold onto is the reasoning behind decisions.
Why was this recurring alarm treated differently from another that looked identical? Why was a maintenance activity deferred three times in a row? Why was an asset replacement brought forward despite the lifecycle plan, or pushed back despite recommendations to proceed?
Those answers do not live in a system. They live with the people who made those calls. And when those people leave, the answers go with them.
Experienced engineers do not just hold information. They hold the knowledge and decision logic that turns information into action. That knowledge is built through years of exposure to a specific portfolio, its specific assets, its specific failure patterns. It is the layer between raw data and the right call. When it walks out the door, the data stays behind but its usefulness drops immediately.
Data is retained. The knowledge and decision logic that made it useful are not.
Operational knowledge reveals itself through decisions. Every decision on a portfolio is a choice between alternatives: act now or wait, escalate or monitor, replace or extend. The decision itself is only the outcome. The real value lies in why that option was chosen over the others, and that context is precisely what most FM systems were never built to capture.
FM systems record events. They capture inspections, alarms, work orders, asset histories. They are an important operational record. But they capture what happened, rarely why. And so when an experienced engineer leaves, organisations lose more than expertise. They lose a portion of the decision-making framework that has quietly governed how that portfolio has been run.
This is what makes the challenge deeper than knowledge retention. It is a decision continuity problem.
The consequences do not announce themselves. Buildings keep running. Work orders keep flowing. Nothing fails on day one. The erosion is gradual and easy to miss until it has already compounded.
Decisions slow down. A new engineer inherits the assets, the procedures, the system access, but not the context. Problems that once took minutes to resolve now take hours of investigation and escalation, not because the new engineer is incapable, but because they are starting from scratch on a portfolio with years of history they cannot access. The same lessons get learned repeatedly. Workarounds that took months to develop are forgotten and slowly reinvented. Consistency breaks down because the decision logic that once made responses consistent is no longer available.
It is also worth noting that this gap does not disappear with better technology. Predictive maintenance tools can tell you that an asset is likely to fail. What they cannot tell you is what that means for this specific portfolio, in this specific context, given the history of decisions that have been made around it. The detection becomes available. The judgment to act on it correctly still has to come from somewhere.
Over time, that somewhere becomes a shrinking group of people who still carry the institutional memory. Every retirement, every resignation, every internal move makes that dependency more fragile.
What organisations need is not just better records of what happened. They need a way to preserve how decisions were made: the context, the reasoning, the trade-offs, the judgment that shaped the outcome. Knowledge retained in a form that can actually inform future decisions, not just future audits.
This is the idea behind a System of Decisions: an operational layer that sits above existing FM systems and creates continuity between past and future decision-making. Rather than recording only activities and outcomes, it captures the reasoning and operational logic behind them.
Over time, preserving decision logic does more than retain knowledge. It creates a governance layer that helps ensure future decisions are made consistently against the operational standards and reasoning that have already been established. The portfolio develops a memory that is not dependent on any single person holding it.
This is where Xempla operates. Omi is Xempla's reliability agent, purpose-built for operational maintenance intelligence. When an issue is detected, Omi evaluates the situation using available signals: asset history, current operating conditions, and patterns from previous decisions made on that portfolio. It surfaces a recommendation, a confidence score, and critically, the reasoning behind it.
But the recommendation is not always the final word. In most cases, the engineer reviews it, applies their judgment, and makes the call. They can accept the recommendation, modify it, or override it entirely. Where the organisation has configured certain decision types to be handled differently, that too is a choice made by the people running the portfolio. Either way, the decision and the reasoning behind it become part of the operational record.
This is where the learning loop begins. The next time a similar situation arises, Omi does not just reference what happened before. It references the decision logic that was applied, the context that shaped it, and any corrections an engineer made along the way. Every decision captured makes the next recommendation more informed. Every override adds a layer of portfolio-specific knowledge that did not exist before. And critically, this does not require the same fault to reappear. Omi draws on prior decision logic even when the triggering condition is entirely different, because what it carries is not just a record of events but an understanding of how that asset has been read and reasoned about over time.
Consider what this meant for one AHU on a live portfolio.
In January 2026, the AHU flagged a supply air temperature anomaly. The space operates between an active setpoint of around 20 to 21°C and a setback setpoint of 14°C. During the setback, space temperature had been holding at 18 to 20°C, well above where it should have been. Investigation found the cause: a frost coil bypass. The frost coil had risen to 18 to 18.5°C instead of the expected 13.5°C, affecting downstream conditions while both coils remained off. After 20 January the system corrected itself, no action was required, and the engineer closed the case. The reasoning behind that conclusion became part of the asset's decision record.
Five months later, the same AHU triggered again. A regional heatwave had driven temperatures sharply upward. Supply air temperature climbed to 25.81°C. On the surface, it looked serious.
The justification it surfaced: anomalies were fully explained by prior validated operational context. The cooling valve was running at 99.81%, working hard, but correctly. A 10°C delta between ambient and supply air temperature confirmed effective cooling was happening. No internal component failure was present.
These were not the same fault. January was a frost coil bypass in cold weather. June was an environmental temperature spike, a different condition, different cause, different signal. What Omi recognised was not a repeated pattern but an operational relationship: this asset has a validated history of temperature anomalies with non-fault explanations, and the decision logic from January was available when June's signal came in. This is decision continuity made visible. The knowledge that resolved January's investigation did not sit in a document or depend on the same engineer being available. It shaped the next decision on that asset months later, under completely different conditions.
Over time, this creates a compounding effect:
Decision History → Decision Continuity → Organisational Memory → Decision Governance
The knowledge that once lived only in the engineer who ran that January investigation is now embedded in how the portfolio is operated. It is structured, accessible, and available to whoever comes next.
Engineers joining a portfolio start with context, not a blank slate. They have access to the reasoning behind previous decisions, the logic behind exceptions, the operational knowledge that shaped how the portfolio runs. Ramp-up is faster and understanding goes further than any handover document could achieve.
Operational standards survive transitions because consistency is embedded in how decisions are made, not in who happens to still be around. Knowledge compounds because it accumulates inside the organisation itself, not just inside the people who built it.
Throughout all of this, engineers remain central, and deliberately so. Omi surfaces recommendations and reasoning, but the people running the portfolio bring what no system can replicate: site knowledge, professional judgment, accountability, and the ability to read a situation in ways that data alone cannot. The goal is not to work around that. It is to make sure it is not lost when those people move on.
Rajan will retire. Every organisation eventually loses its most experienced people. The question is whether the knowledge they built over years on that portfolio has to leave with them.
With decision continuity in place, it does not have to.
Documentation captures what happened. What leaves with an engineer is why decisions were made the way they were: why a recurring alarm was treated differently from one that looked identical, why an asset replacement was brought forward or deferred. That reasoning does not live in any system. Better handover notes are worth doing, but they have a ceiling. The gap is not information. It is the decision logic that made information useful.
Partially. Predictive tools can tell you that an asset is likely to fail. What they cannot tell you is what that means for a specific portfolio, given the history of decisions made around it. Without preserved decision logic, the judgment needed to act on signals correctly remains concentrated in a shrinking group of people, and every departure makes that dependency more fragile.
Logging records outcomes. Xempla captures the reasoning behind them. When an engineer reviews, modifies, or overrides a recommendation, that reasoning becomes part of the asset's decision record. The next time a similar situation arises, Omi draws on that prior decision logic, not just the event history. Portfolio-specific knowledge compounds inside the organisation rather than only inside the people who built it.
The opposite. Engineers remain central and deliberately so. Omi surfaces recommendations and reasoning, but the engineer brings what no system can replicate: site knowledge, professional judgment, and the ability to read a situation in ways data alone cannot. What changes is that when they make a call, they have the full decision history of the portfolio behind them. And when they move on, that judgment does not leave with them.
Paragraph
Block quote
Ordered list
Unordered list
Bold text
Emphasis
Superscript
Subscript
© Xempla. All rights reserved.
Terms & Conditions