‍
The DIIV Cycle is Xempla's four-phase AI governance framework for facilities and asset management, covering Discover, Investigate, Implement, and Verify, designed to move FM operations from activity recording to verified outcomes.
‍

The DIIV Cycle for FM decision-making and operational governance is Xempla's System of Decisions for PPM, CMMS, CAFM, IWMS, and BMS environments. Xempla is an AI-native governance platform for facilities and asset management that sits above existing operational systems to turn disconnected maintenance activity into governed, accountable outcomes. It does not replace the systems FM teams already run. It becomes the decision layer above them: determining what action is taken, under what rules, with what evidence, and with what verified result.
‍

The mechanism through which that governance operates is the DIIV Cycle, Xempla's proprietary four-phase operational framework: Discover, Investigate, Implement, Verify. It takes an FM operation from the first signal of an asset deviation all the way through to confirmed outcome, with every decision in between governed, documented, and auditable.
‍

Here is how it works, phase by phase.
‍

How the DIIV Cycle Differs from Traditional CMMS, CAFM, and IWMS Operations

Before going into each phase, it helps to understand what the DIIV Cycle is structurally changing about FM operations.
‍

Traditional CMMS, CAFM, and IWMS platforms are systems of record. They log what happened: work orders raised, PPM schedules completed, SLAs met or missed. The DIIV Cycle sits above them as a system of decisions, continuously determining what should happen next based on live asset intelligence, structured triage, and client-defined governance rules, and then verifying whether the action taken actually produced the intended result.
‍

The difference is not incremental. It is structural.
‍

‍Phase 1 — Discover: CMMS, BMS, and IWMS Real-Time Asset Monitoring

The Discover phase runs permanently in the background. Xempla's AI agents monitor asset performance continuously, pulling from BMS integrations, IoT sensors, CMMS work order history, and IWMS records, watching for deviations from established operational baselines.
‍

The agents are not waiting for a fault to be reported by a technician or flagged by a user. They are identifying the moment an asset begins behaving differently from how it should: a variance in HVAC throughput, a shift in energy draw, an MTBF deterioration, an escalating pattern of reactive maintenance frequency. The moment a meaningful deviation is detected, it enters the cycle.
‍

This matters because traditional PPM programmes operate on fixed schedules regardless of actual asset condition, and reactive maintenance begins only after failure. Neither model consistently catches the in-between: the asset that is technically operational but drifting toward a fault. The Discover phase is built precisely for that territory.
‍

At this stage, the agents do not raise a work order. They raise a signal. What happens to that signal is the Investigate phase.
‍

‍Phase 2 — Investigate: Structured Triage and Diagnostic Logic Before Any Work Order Is Raised

This is the phase most implementations skip, and it is arguably the most consequential.
‍

Not every deviation is a problem. Assets produce noise. Sensors misread. Seasonal conditions create temporary fluctuations that resemble fault patterns without indicating a genuine issue. If every detected deviation triggered a work order, the system would generate more reactive noise than operational value. The Investigate phase exists to prevent exactly that.
‍

When a deviation enters Investigate, the AI agents work through three structured questions in sequence. First, is this a false alarm? The agents cross-reference the signal against historical asset behaviour, environmental conditions, known variance thresholds, and previous maintenance history. If the deviation falls within acceptable operational parameters, it is logged and dismissed: no work order raised, no escalation triggered, no unnecessary cost introduced.
‍

If the signal represents a genuine fault, the second question is urgency. Does this require immediate response, planned attention, or can it be deferred? This classification is based on asset criticality, SLA exposure, failure severity, and site context. The urgency output determines what kind of response is initiated and how quickly.
‍

For confirmed faults with a clear urgency level, the third question is what needs to be done. The agents build a diagnostic case drawing on maintenance history, warranty status, contractor performance, PPM records, and fault recurrence patterns. The output is not a work order. It is a decision package: a diagnosis, an urgency classification, an evidence chain, and a recommended action.
‍

‍Phase 3 — Implement: Governed Execution Within Client-Defined SLA and PPM Rules

The Implement phase is where the decision becomes action, and where Xempla's governance model is most visible.
‍

The Implement phase does not work identically for every client. Before deployment, each organisation defines its own governance rules: which asset categories allow autonomous dispatch, which require manager approval, which contractors can be assigned, and which asset classes require mandatory human escalation regardless of agent confidence. The AI agents operate entirely within those rules.
‍

For clients who have authorised autonomous execution in certain categories, the agents dispatch work orders directly within the existing CMMS or CAFM workflow, without manual intervention. This is how 42% of work orders across Xempla's Autonomous Maintenance Programme are governed end-to-end without a human in the loop [1].
‍

For clients who have not authorised autonomous dispatch, or for asset categories that fall outside the auto-approval threshold, the agents present their decision package as a structured recommendation. The FM manager sees the diagnosis, the urgency classification, the evidence chain, the risk profile, and the recommended intervention. The decision is human. The intelligence supporting it is not.
‍

This is the governance layer in practice. It is not automation running independently of organisational judgment. It is automation running within it. Different clients set different rules, and the same agents operate differently at a hospital trust than at a logistics portfolio because the rules reflect different operational realities. Where agent confidence falls below a defined threshold, due to a novel fault pattern, missing historical data, or complex multi-asset interactions, the system escalates automatically rather than proceeding. Governed escalation is not a failure of the system. It is the system working correctly.
‍

Phase 4 — Verify: Measuring Outcomes Against KPI and PPM Baselines

A work order being closed is not the same as a problem being solved.

In standard CMMS and CAFM workflows, job closure is the end of the process. The asset re-enters the maintenance schedule, the SLA clock resets, and the question of whether the intervention actually worked is rarely examined systematically. The Verify phase examines it systematically, every time.
‍

After a work order closes, the AI agents return to the asset and compare post-intervention performance against the baseline established during the Discover phase. They are asking: has the deviation been resolved? Is the asset performing as expected? Did the recommended action produce the intended outcome?
‍

If the intervention succeeded, the cycle closes cleanly. The outcome is recorded and feeds back into the agents' diagnostic model, improving detection accuracy for future cycles on this asset and similar ones across the portfolio. This is continuous operational learning, not static reporting.
‍

If the issue recurs within a defined window, or asset performance fails to return to baseline, the system flags the original diagnosis for review. The same intervention is not repeated automatically. The cycle reinvestigates. This feedback loop is what shifts FM operations away from repetitive reactive maintenance and toward measurable reliability improvement. Across Xempla environments, a meaningful shift in PPM-to-reactive ratio becomes visible within 90 days of operational baseline [2].
‍

What the DIIV Cycle Changes About FM Operations

Most FM platforms measure whether maintenance activity was completed. The DIIV Cycle measures whether maintenance decisions improved the operational condition of the asset. That shift, from activity completion to outcome verification, is what separates a system of records from a system of decisions.
‍

For FM teams, that means every work order is backed by a diagnostic case, not just a reported fault. For asset owners, it means every maintenance spend is traceable to an operational result. For FM service providers, it means every SLA claim is supported by evidence, not just a closed ticket.
‍

The DIIV Cycle is not a new workflow sitting on top of existing systems. It is the governance layer that makes those systems, and the decisions they support, provably accountable.
‍

See the DIIV Cycle in Practice

The phases above describe how the framework operates. How it performs across real FM environments, with real asset portfolios and real operational constraints, is a different kind of evidence.

Xempla's case studies cover deployments across healthcare, commercial real estate, and FM service providers. See how the DIIV Cycle has performed across live estates.
‍

FAQs

What does the DIIV Cycle do differently from a standard CMMS or CAFM platform?

The DIIV Cycle governs maintenance decisions rather than simply recording maintenance activity. A CMMS tracks what happened: work orders raised, jobs completed, PPM schedules ticked off. The DIIV Cycle determines what should happen next, executes within client-defined governance rules, and verifies whether the intervention actually resolved the operational issue. CMMS is a system of records. The DIIV Cycle is the system of decisions sitting above it.
‍

How does the DIIV Cycle filter false alarms from BMS and IoT sensor data?

False alarm filtering happens in the Investigate phase. The AI agents cross-reference every detected deviation against historical asset behaviour, environmental conditions, known variance thresholds, and previous maintenance records before any work order or escalation is triggered. Signals that fall within acceptable operational parameters are logged and dismissed without generating unnecessary maintenance activity.
‍

Does the DIIV Cycle replace existing FM teams or CMMS systems?

No. The DIIV Cycle integrates with existing CMMS, CAFM, IWMS, BMS, and ERP platforms and does not replace them. FM teams continue operating within familiar workflows while Xempla's agents provide governance, triage, and verification intelligence above those systems.
‍

How does urgency classification work in the Investigate phase?

The AI agents classify each confirmed fault as immediate, planned, or deferred, based on asset criticality, SLA exposure, deviation severity, and operational context. The same fault classification logic produces different urgency outputs depending on the governance rules configured for each site and client.
‍

How configurable is autonomous execution in the Implement phase?

Fully configurable per client and per asset category. Some organisations authorise the agents to dispatch work orders autonomously for defined asset types within defined SLA windows. Others require manager approval before any dispatch. The agents operate within whatever governance rules the organisation sets and do not override them.
‍

What does the Verify phase actually measure after a work order closes?

The Verify phase measures whether the intervention resolved the original deviation and restored asset performance to the pre-fault baseline. It does not treat job closure as process completion. If the issue recurs within a defined window or performance fails to return to baseline, the system flags the original diagnosis for reinvestigation rather than repeating the same maintenance action automatically.