What a digital twin actually is — and what it isn't
A digital twin is a live, synchronised model of a physical system — updated in real time from sensor data and BMS telemetry, queryable by operations teams, and capable of running simulations to predict future states. It is not a BIM model with a dashboard bolted on. A BIM model is a static geometry file representing the building as designed. A digital twin is a dynamic data model representing the building as it operates — and the gap between those two things is where most digital twin projects get into difficulty.
The five maturity levels
Digital twin maturity is typically described in five levels. Level 1: data aggregation — getting all building data into one place, accessible via a single API. Level 2: visualisation — presenting live data against a building model or floor plan. Level 3: analysis — detecting anomalies, generating alerts, comparing actual vs expected performance. Level 4: simulation — running thermal models, occupancy prediction, or maintenance scheduling against live data. Level 5: autonomous operation — the system controls the building based on model predictions rather than fixed schedules. Most UK commercial projects in 2026 are targeting Level 2–3 and discovering that Level 1 is harder than expected.
Sensor topology and data point mapping
A digital twin is only as good as its data. The sensor network design determines what the model can and cannot reason about. Standard commercial building instrumentation: zone temperature sensors (1 per zone minimum), CO₂ and TVOC for IAQ in occupied spaces, occupancy sensors for presence-based control, energy sub-metering at AHU, chiller, lighting, and plug load circuits, and differential pressure across filters and heat exchangers for predictive maintenance. The topology design documents: sensor type, placement rationale, protocol (wired or wireless), reporting interval, and the data point in the BMS or IoT platform that receives it.
BIM-to-digital-twin pipeline
Where a BIM model exists, the pipeline from geometry to live data model involves: IFC export from the authoring tool (Revit, ArchiCAD), conversion to a semantic graph using COBie or a direct IFC parser, enrichment with Haystack or Brick Schema tags to associate geometry objects with live data points, and loading into the digital twin platform. The critical step — and the one most often skipped — is the tagging exercise, which requires someone who understands both the BIM model and the BMS point list. Spektris designs this pipeline and specifies the tagging schema before platform selection, not after.
Haystack and Brick Schema tagging
Haystack is a controlled vocabulary for tagging building data points — site, equip, point, temp, sensor, discharge, air. Brick Schema adds a richer relationship model, allowing the twin to understand that AHU-3 serves Zone-7 and Zone-8, and that Zone-7's thermostat setpoint drives AHU-3's discharge temperature. Both are open standards. Choosing between them, or using them together, is an architectural decision that affects which analytics platforms can consume the data without a custom integration layer.
The most common mistake in digital twin projects: selecting the platform first and fitting the data model around its limitations. Spektris designs the data model and tagging schema first, which makes platform selection an informed, reversible decision rather than an expensive constraint.
Fault detection and diagnostics
FDD (Fault Detection and Diagnostics) is the application layer that makes a digital twin operationally valuable for FM teams. Standard FDD rules for commercial HVAC: simultaneous heating and cooling detection, AHU supply air temperature deviation from setpoint, chiller COP below design benchmark, filter differential pressure above service threshold, zone temperature persistently above or below setpoint. These rules are specified as part of the digital twin design, not added later by the platform vendor.