Make the signal count.

What the literature actually says (and its limits)

A broad academic review frames data-driven FDD (fault detection and diagnostics) as a multi-step process: data collection, cleansing, baseline establishment, detection, and diagnostics. The review warns that "data quality, resolution, completeness, extensiveness (i.e., whether the data accounts for a variety of operating conditions), and uncertainty (i.e., measurements errors) are particularly important for data-driven FDD methods" .

The same review also defines the task: "fault detection is defined as \"determination that the operation of the building is incorrect or unacceptable in some respect\" and fault diagnostics is defined as \"identification or localization of the cause of faulty operation\"" . Those definitions show FDD outputs are statements about system behavior and root cause, not automatic fixes.

Field studies that move beyond classification toward maintenance actions exist, but they are focused and contextual. One published PdM study describes translating RUL forecasts into schedule-aware maintenance using "RUL labels were derived from time-stamped work orders and failure confirmations" . That phrasing indicates the importance of technician-validated events for making prognostics operationally useful.

What service contractors have demonstrated (operationally)

Research and industry material describe a range of fault-detection methods. Some use rules and thresholds; others use statistical or machine-learning models. The label “AI” does not tell an operator which approach is in use, how it was evaluated or whether the underlying equipment data is good enough. Ask the provider to make those distinctions visible.

A study of one building or equipment portfolio cannot establish your service business’s return. Equipment, operating conditions and the quality of maintenance records all affect the comparison. Use published work to decide what to test, then connect every trial alert to a technician’s finding before treating it as useful evidence.

A bounded pilot you can approve (practical operations)

Goal: reduce technician time spent chasing false alerts and increase the fraction of alerts that convert directly to corrective work orders for commercial AHUs and chillers. Preconditions you should approve: accessible 1–5 minute BMS telemetry for targeted assets, a way for technicians to tag and timestamp confirmed failures in the work-order system, and a single contractor supervisor who signs off on changes to dispatch rules.

Pilot design (6–12 weeks): ingest and cleanse telemetry for 2–4 critical assets; run a simple baseline-and-threshold or lightweight supervised model to generate alerts; require technicians to add a short standardized confirmation in each work order (reason code and timestamp) when an alert led to corrective action; route ambiguous alerts to a secondary queue for technician review. Use only technician-confirmed events as labels—do not assume maintenance logs without explicit confirmation are ground truth.

Decision point for approval: the site manager (or contractor owner) must sign the operator playbook that defines which alerts trigger immediate dispatch versus diagnostic inspection. That human approval is the governance step that distinguishes experimental analytics from operational dispatch.

How to measure success (and a practical outcome)

Concrete business outcome: increase the proportion of alerts that result in a correct corrective work order and reduce technician hours spent triaging false positives. Do not promise specific percentage savings from literature; treat published numbers as hypotheses to test in your portfolio.

Three measurements to track continuously are listed below. Use pre-pilot baselines for each and require weekly reporting during the pilot. If Alert Precision and Work Order Closure Accuracy both rise while Mean Time to Confirm Fault falls, the pilot has operational value and you can phase roll-out.

If pilot metrics do not improve in 6–12 weeks, pause and audit: check sensor sampling rates, missing channels, label quality in work orders, and whether the technician confirmation step is consistently used. The literature shows data quality and label scarcity are the common failure modes for FDD pipelines .