The digital handshake part 2: the independent data layer, commissioning and the mesh
In the second and final part of his series on digital operations, Justin Kirby reflects on bridging from static asset data to live performance data streams.

In the first part, I explored right-to-left policy rules and the critical distinction between static asset and live performance data. Here, I’ll play back the market conversation surrounding how the independent data layer (IDL) acts as a semantic bridge, how advanced commissioning ensures data plumbing matches physical reality, and invite the wider industry to help co-create a full lifecycle-driven operational framework.
Mapping is the true function of the IDL established by smart buildings specialists such as master system coordinators (MSC). In an operational context, semantic modelling simply means adding human and machine-readable meaning to data. This moves the estate past random sensor codes so it can map the real-world relationships between physical components, giving the operations and maintenance teams and their platforms the exact context they need to act.
The IDL acts as the semantic bridge, using open ontologies like Brick, Haystack or ASHRAE, to bind the static asset data to the live performance data streams. Crucially, it does not just link the data points. It maps the underlying relationships, system zones and performance of the entire estate. By anchoring this within an open IDL, the client gains the mechanism to view live performance data relating directly to high-cost, energy-heavy plant.
By managing this relationship from inception, the MSC enforces the logic required to build an open IDL, delivering a semantic data model that the client fully owns. Currently, software vendors very often handle all the data formatting, classification mapping and relationship modelling because they receive information in completely disparate formats.
Because that heavy work happens inside their specific software tools, the platform vendors end up owning the functional data model by default. This makes it incredibly difficult to separate your estate’s data from the platform itself, whether that platform is a smart building system, a data-led maintenance tool, an integrated workplace management system (IWMS) engine or a tenant engagement app.
“Until performance-related contracts become standard, the master systems coordinator provides the necessary coordination to bridge the gap between initial upfront paperwork and live operational reality.”
An open container changes this entirely. By separating the digital logic from the contractor labour, the MSC can remain completely platform-agnostic. When logic and labour are combined, traditional integrators inevitably bring their own commercial partnerships and proprietary platforms to the table. Because the MSC is entirely decoupled from that physical delivery, they can focus solely on ensuring the data architecture is built independently of the software stack.
In the real world, the MSC inherits a complex, highly fragmented array of initial project documentation. Out of the box, the main contractor’s BEP, the client’s EIRs, design specifications from the MEP consultant and client design guidelines rarely match. The MSC’s first task is to collaborate across the team to force these conflicting procurement documents into a unified, functional alignment.
This coordination is a vital technical bridge. We need this because design-and-build parties do not yet share explicit legal and financial responsibility for long-term operational and business outcomes. Until performance-related contracts become standard, the MSC provides the necessary coordination to bridge the gap between initial upfront paperwork and live operational reality. Even as contractual models slowly evolve toward performance assurance, having a dedicated team on the ground is the only way to police this alignment.
When engaged early in the project, the MSC can actively use their frontline data experience to prevent the overspecification of technology for its own sake. Because the MSC’s involvement lasts longer into the building’s lifecycle, and spans both new builds and complex retrofits, they understand how data actually behaves in operation. This unique perspective allows them to challenge upfront specifications, ensuring owners don’t deploy an expensive, hyper-complex ‘Frankenstack’ architecture bought simply to tick a smart building badge without delivering real operational utility. This role allows them to act as the governance layer during the physical installation.
This structural separation allows the client to freely swap out applications, such as an occupant experience app, a building performance engine, a CDE or a core IWMS/centralised maintenance management system tool, completely removing the risk of a 20-year vendor lock-in.
However, we must be realistic, because that seamless transition is far more difficult to guarantee contractually and practically. It requires the MSC’s current lived experience to provide rigorous, ongoing coordination and governance as the client’s digital maturity develops, ensuring that any new platform introduced down the line can actually interface with the established data model without breaking the existing architecture.
Verifying the flow for operational stability
Data containers and policy rules are only as good as the physical reality on site. The Smart Buildings, Same Outcomes panel at DCW, featuring Mike Darby of Demand Logic, Joanna Harris of Sodexo, Dean Jelfs of Dome Consulting and Jordan Collins of SES, highlighted a fundamental shift in how we verify that a building actually works. Commissioning is moving far beyond legacy practices.
As project frameworks increasingly mandate commissioning specialists to verify that design intent matches operational performance, they are increasingly being engaged during the upfront design phase. Their value lies in their ability to pressure-test design briefs against operational realities. When value engineering threatens to cut critical components to save minor upfront capital expenditure (capex), commissioning specialists provide a vital reality check. They can show exactly where short-term savings directly contradict the building’s long-term functional goals. Those short-sighted cuts are precisely what make future troubleshooting incredibly complex.
Traditional projects rely on a rushed, compliance-driven box-ticking exercise at handover just to achieve contractual sign-off, followed by fragmented seasonal commissioning months down the line. Neither of these traditional approaches ensures that the building is operationally or functionally optimised when the doors open.
“As project frameworks increasingly mandate commissioning specialists to verify that design intent matches operational performance, they are increasingly being engaged during the upfront design phase.”
Digital technology transforms this process through a broader digital commissioning framework. Pre-practical completion, monitoring-based commissioning (MBCx) principles are applied to verify that the technical logic and data plumbing established by the MSC layer are physically present and broadcasting correctly. Post-practical completion, the role transitions into ongoing continuous commissioning (CCx). This active validation loop runs inside the open data container, using empirical data rather than manual spot-checks to ensure systems remain optimised for performance and operational stability on an ongoing basis.
An invitation to the mesh
These joined dots are top of mind because they represent the exact frontline discussions unfolding on the Digital Operations Stage a fortnight ago. This reflection does not pretend to hand down a final word, not least because there are several other critical jigsaw pieces and stakeholders that must be woven into this conversation as it evolves.
To fully realise a right-to-left operating model, we have to bring more people to the table. For example, we need to loop in the MEP design consultant. Their role is fundamentally evolving, particularly as the industry looks toward emerging, performance-related contractual models.
We also need to engage the developers of the operational platforms themselves, such as specialised data-led maintenance engines. These platforms are the tools that actually analyse the operational data and drive the automation. They sit directly between the raw telemetry and the end client. If they don’t get that data structured in the precise way they need to deliver on specific outcomes, then those outcomes simply will not happen.
Ultimately, this piece is put forward as an open discussion to challenge how asset owners, design teams and supply chain partners map their respective responsibilities. By playing these frontline observations back to the market, the goal is to shift the wider industry conversation away from isolated vertical silos and toward co-creating a coordinated, full lifecycle-driven functional mesh that secures true operational stability from day zero.
Keep up to date with DC+: sign up for the midweek newsletter.