Construction and information management frameworks provide clear guidance for static asset records (nouns), but the smart building domain lacks a shared top-down topology for dynamic performance data (verbs). Highlighting this missing framework, Justin Kirby asks how the sector expects to bridge project delivery and live operations without a clear pipeline map
As a facilitator and commentator, I’ve often heard the smart building domain described as a bit like a jigsaw puzzle. Everyone knows the individual pieces, but no one has the box art to show how they fit together.
That metaphor pairs neatly with the parable of the blind men and the elephant I’ve discussed previously. Every actor in a project, whether a controls engineer, software vendor, or facilities manager, touches a different part of the system and can become fixated on narrow slices of the scope rather than the whole operational reality. The trouble is that, in this telling, no guide or oracle ever steps back to show how those individual parts fit together into a functioning whole.
Beyond process schedules and buyer buckets
When the Smart Building Overlay to the RIBA Plan of Work was published in February 2024, it missed the opportunity to define the core problem statement it was meant to solve, or to provide that missing picture on the box.
What it did achieve, however, was kickstarting a vital industry conversation. It marked a genuine step forward by acknowledging that technology conversations happen far too late, advocating early stakeholder engagement, and setting a process schedule for who should meet at each standard project stage.
Yet scheduling conversations is an essential start, not a technical blueprint. It stopped short of defining the digital handshake needed to bridge the project-to-operations gap. When capital delivery completes without a shared macro-map of the data pipeline, disconnected systems can end up being thrown over the wall. Then integrators and operational teams are left to figure out on the fly how data physically transforms from field devices into operational software, doing whatever it takes so the building can be occupied, run, and deliver on the original design intent.
From what I can see, the closest thing the industry has to a picture on the box is the Independent Data Layer (IDL) diagram James Dice and the Nexus Labs community presented in May 2021.
The industry owes James a genuine debt of gratitude for that framework. It established two vital ideas. First, the concept of an independent data layer that potentially liberates asset owners from proprietary vendor lock-in, even if clarity is still required on how that independence is physically achieved in practice. Secondly, it clearly mapped where that layer sits in a technology stack across four distinct layers:
- Device Layer
- Network Layer
- Independent Data Layer
- Application Layer
Inside the IDL box, the diagram breaks down the specific functional components:
- Asset Register
- Data Storage
- Data Model
- Cloud Integration
- IDL Administration
- APIs
Evaluating what the IDL diagram represents shows it functions as a commercial marketplace framework. It tells an owner what product categories exist to buy, but it does not show the internal engineering mechanics. It does not explain the sequential transformation pipeline showing how raw signals from physical equipment become structured payloads, how those payloads gain semantic context, and how software applications finally make sense of them.
Two vectors for understanding the smart building domain
Smart buildings are routinely discussed through two lenses. People talk about their potential in terms of aspirational outcomes, or they give broad descriptions of connected sensors and automated controls.
Yet for that potential to be consistently realised in an occupied building, we have to address the structural gap between project delivery and ongoing operations. Smart buildings are being delivered, but not consistently. But friction during handover stems from treating all data standards as if they solve the same problem.
To understand where that handshake fails, we have to distinguish between two completely different paradigms I have written about previously. If one distinction can stop the industry from talking past itself, it is the difference between these two vectors. Bringing in the information management distinction between asset twins and performance twins is particularly helpful here:
- Vector 1 (Static Assets at Rest): The static compliance foundation. This covers cataloguing physical components for Day 1 statutory handover, baseline asset registers, and maintenance schedules. These are the static nouns that form the asset twin.
- Vector 2 (Dynamic Data in Motion): The dynamic operational frontier. This is driven by real-time telemetry, sensor readings, and semantic modelling to govern how an occupied building actively behaves on Day 2 and beyond. These dynamic verbs form the performance twin.
Both vectors feed directly into complete asset lifecycle handover. Yet through this lens, the structural imbalance across the current landscape is clear. Vector 1 is overcrowded with standards, crosswalks, and frameworks trying to fix static assets at rest, while Vector 2 remains an absolute vacuum.
Major working groups are undeniably doing heavy lifting in Vector 1, including:
- nima and the Construction Leadership Council: Driving full-lifecycle digital information management ambitions around ISO 19650.
- Public Sector Policy and Standards Alignment: Crosswalks and alignment work feeding directly into the FMS 002 Facilities Management standard and the NHS Estates and Asset Management Policy.
- buildingSMART: Broader IoT and interoperability initiatives, alongside evolving COBie into the new Asset Operations Handover framework.
Without an agreed Vector 2 framework, it is hard to see how they can stretch the vital work they’re doing in Vector 1 into dynamic operations. Because these bodies don’t explicitly draw a boundary where static asset governance ends, efforts to fix static registers routinely get tangled with dynamic operational requirements.
When working groups and standards bodies aren’t clear whether they are addressing static asset handover or live operational performance, their scope naturally expands into areas where the underlying dynamic map hasn’t been defined yet.
Mapping the Vector 2 frontier
While the industry continues to battle for ownership over Vector 1, Vector 2 remains the true unmapped frontier. Lacking a top-down macro-topology for how dynamic operational data physically transforms, the industry is left without a shared operational map to guide how data transforms from the physical device layer to the application layer.
To illustrate what a top-down pipeline map might look like, we can assemble a 5-tier topology drawn from open-source initiatives originally developed by engineering teams at Arup and later expanded through work at Google:
- Tier 1: Physical Plant and Field Devices (The physical equipment, sensors, and hardware on site)
- Tier 2: Device Naming Conventions (Building Device Naming Standard / BDNS)
- Tier 3: Ingestion Payloads and State (Universal Device Management Interface / UDMI)
- Tier 4: Semantic Contextualisation (Digital Buildings Ontology / DBO)
- Tier 5: Application Layer (Building Operating System / BOS)
I am not presenting these specific open-source tools as a finished commercial stack, nor am I advocating their adoption as a definitive standard. Neither Google nor Arup ever actually presented these elements assembled together as a single pipeline map. Each has practical limitations and adoption hurdles at the coal face, not least that the much-heralded Building Operating System was never launched into the market. Furthermore, I am not suggesting these five tiers are the only, or even the best, way to define the layers.
Instead, I am using them purely as a proof-of-concept scaffold to demonstrate the type of sequential pipeline map our industry is missing. It simply reflects what I can map from what is currently visible in the public domain to give some idea of what I mean. The real goal isn’t to prescribe the final solution, but to challenge the industry so that some group, or ideally several in collaboration, steps up to provide the definitive map of how dynamic data physically transforms.
The missing middle and the specification opportunity
Without that shared macro-topology, current industry conversations completely overlook the people sitting directly inside the project-to-operations gap. It’s like holding a firefighters’ conference where no one is allowed to talk about water. If you look at the market right now, the discussion about data handover seems to be limited to just two or three sides: information managers, asset managers, and facilities managers.
But sitting squarely between the project and operations side of those camps are the MEP contractors, Master Systems Integrators, and platform providers. They are the missing stakeholder group responsible for physically building and connecting the operational data bridge. Excluding the very people who deliver the deployment leaves them to improvise the dynamic data pipeline on the fly at practical completion.
Defining a clear Vector 2 topology brings the middle delivery teams into the conversation to develop the blueprint that’s needed to bridge project delivery and live operations.
When those middle delivery teams are left without that high-level blueprint, the engineering effort inevitably degrades from the top-down into the bottom-up. Lacking a macro-topology for how dynamic operational data physically transforms across the pipeline, specialists and engineers collapse into micro-mechanics. They get bogged down in intense, isolated debates over schemas, point tags, and payload structures. But arguing over those micro-mechanics without first agreeing on the overarching pipeline structure is like arguing over potholes when nobody has mapped the road.
Beyond aligning delivery teams and escaping the micro-engineering trap, a macro-topology provides the essential scaffolding on which all these complex data standards can finally be hung. Crucially, establishing this overarching framework helps the market by:
- Distinguishing specifications from software: Clearly separating open-source schemas and data specifications from the proprietary or custom vendor software built on top of them.
- Locating data & semantic modelling: Defining exactly where structural data modelling (formats and payloads) and semantic modelling (relational context and ontologies) occur within the physical data pipeline.
- Setting clear boundaries: Establishing explicit lines between static asset tagging and registers, device naming, point tagging, and operational ontologies like Brick, Haystack, RealEstateCore, or the emerging ASHRAE 223P.
This is where the opportunity lies for the authoring group reviewing the Smart Building Overlay to the RIBA Plan of Work. Defining this missing Vector 2 macro-topology as part of the overlay review would give the industry the essential scaffold it lacks and make a foundational contribution to these emerging standards.
Crucially, this is where a macro-topology directly influences how technology is specified, procured, delivered, and deployed to help realise those intended outcomes. Process scheduling outlines when tasks occur, but a clearer technical framework helps define the digital handshake upfront by clarifying which devices are required, how assets are categorised, and how data actually flows. High-level user journeys define the vision, but understanding these underlying mechanics helps turn that vision into operational reality.
Without addressing this underlying foundation, it remains difficult to see how Facilities Management can genuinely shift from a reactive cost centre into a value driver. The performance domain is increasingly moving operations away from traditional calendar-based scheduling towards condition-based, data-led maintenance. That transition is where operational value lies, underpinning how outcomes like energy reduction, net zero targets, and improved occupant experience are ultimately delivered.
Which leaves us with the fundamental question for our sector. Do working groups, standards bodies, and practitioners see these two vectors and this missing topology as a useful way forward? And if not, how else do we expect to bridge the project-to-operations gap?
Key Takeaways
- The core gap: The smart building domain lacks a macro-level technical framework, the picture on the box, to show how dynamic operational data physically transforms from equipment on the floor into software applications.
- Buyer maps vs. pipeline mechanics: Frameworks like the Independent Data Layer (IDL) excel as commercial marketplace maps, but they do not define the internal engineering pipeline required to bridge project delivery and live operations.
- Two data paradigms: To avoid industry confusion, we must distinguish between two distinct vectors:
- Vector 1 (Static Assets at Rest): Compliance registers, asset twins, and static document governance, such as ISO 19650 and COBie/AOH.
- Vector 2 (Dynamic Data in Motion): Real-time telemetry, semantic graph modelling, and performance twins governing Day 2 and beyond.
- Overcrowded vs. vacuum: Current standards bodies risk stretching static asset governance frameworks into areas where the dynamic data map remains an unmapped vacuum.
- The missing middle: MEP contractors, Master Systems Integrators (MSIs), and platform providers are routinely excluded from high-level digital conversations, forcing them to improvise the operational data handshake on the fly at practical completion.
- Macro-topology over micro-debates: Rather than getting bogged down in bottom-up debates over point tags or schemas, the sector urgently needs an agreed top-down pipeline map so complex data standards can finally be hung on a shared scaffold.
