01
Energy optimisation
Comparing measured consumption against design intent per system and per zone, so drift is attributable to a plant item rather than to the building in general.
What a digital twin actually requires
Five inputs, of which we deliver two today. This page exists to be precise about the distance between a well-structured model and a twin, because that distance is routinely misrepresented in this sector.
Definition Roadmap
A 3D model on a web page is not a digital twin
It is a viewer. A twin is a model bound to asset data, fed by live data from the building, governed by engineering rules and read by analytics that produce operational decisions. Remove any one of those five and the word does not apply.
BIMRACE delivers the first two inputs today: models structured to carry asset information, and the asset data itself, produced as a handover deliverable. The live-data and analytics layers are roadmap.
We publish this distinction because "digital twin" is currently applied to almost anything with a 3D view, and a client who buys a twin and receives a viewer has been mis-sold something expensive.
SOLID CONNECTORS: DELIVERED TODAY
FAINT CONNECTORS: NOT BUILT
The five inputs
What each one is, and whether we have it
Input 01BIM modelLive
Geometry and structured data, authored so that asset information can be
carried on the elements rather than in a separate register that immediately drifts. This is
core delivery work and a service you can appoint today.
Input 02Asset dataLive
Equipment registers, specifications, serial and location data,
maintenance attributes — structured against the model rather than delivered as a folder of
PDFs. Handover information packaging is a live capability.
Input 03Live dataRoadmap
Telemetry from BMS, meters and sensors, bound to the model elements
that generate it. Not built. This requires integration work with the operator's systems that
we have not undertaken on a live asset.
Input 04Engineering rulesIn development
Design intent expressed as thresholds a system can test against —
the same rule sets we are building for design-stage checking, applied to operational data.
In development for design; not yet applied operationally.
Input 05AnalyticsRoadmap
Reading the combination over time to produce operational decisions.
Not built. Everything below is what this layer would be for, described as a concept.
Applications Roadmap
What this would be for
Described as concepts, because that is what they are. None of the following is a capability BIMRACE offers today, and none should be read as one.
02
Asset monitoring
Equipment condition and runtime read against the register, with the model providing the location and service context.
03
Predictive maintenance
Intervention scheduled from observed behaviour and duty rather than from a fixed calendar that ignores how hard the plant has actually worked.
04
System performance
As-operating performance measured against as-designed criteria, which is the check that almost never happens after handover.
05
Occupancy intelligence
Actual use against designed capacity, informing both operation and the brief for the next project.
06
Operational analytics
Portfolio-level patterns across assets — which designs perform, which repeat the same failures, and what should change upstream.
What we will do today. Model and structure your asset so that a twin remains possible later — correct classification, asset parameters populated during authoring, clean system assignment and a handover data structure that an operational platform can actually ingest. That is real, deliverable work, and it is the part most projects get wrong in a way that is expensive to fix afterwards.
What we will not do is sell you a model viewer and call it a twin.