When systems connect, intelligence emerges.

The industry debates what a “Digital Twin” is. That’s fine, but it’s not the point.

In our October post,  ‘It’s Alive: Intelligence and the PAE Living Building,’ we described how the building’s systems began to talk.  This follow-up shows the inverse: 

Intelligence emerges only when the lost pieces reconnect. 

Human insight, machine data, and operational knowledge don’t add up until they exist in a shared, living system of systems. Each control platform was sophisticated on its own, but they weren’t communicating. The building wasn’t “under-instrumented”; it was over-controlled and disconnected.

The Living Building is one of the most ambitious sustainable buildings in the country. When we joined the C4SB effort, we stepped into an extraordinary architectural and engineering achievement, as well as a familiar digital pattern.

The design team produced a beautiful model; however, the Building Information Model (BIM) and systems froze at handover because they were not optimized for operations. It lacked asset attributes, system relationships, and persistent IDs. It did not describe how the rooms, equipment, sensors, and systems were actually connected.

Design BIM vs. CloudBIM: Why the Difference Matters

Most owners assume their design BIM can simply “become” a Digital Twin. It can’t. A design BIM is built for construction, file-based, and heavy, with a frozen state at handover. It cannot support live data, evolving assets, or cross-system relationships.

A cloudBIM is cloud-native, API-ready, lightweight, and able to update as the building evolves, with stable IDs and semantics.

This distinction is so fundamental that it became a dedicated C4SB Working Group focused on defining what cloud-first BIM should be for Digital Twins to scale.

Even if equipment remains on-premises, the integration layer must reside in the cloud so that systems can communicate and behave as a system of systems. 

We gathered everything PAE had: BIM, PDFs, point lists, panel schedules, vendor dashboards, and immediately converted it into a cloudBIM. That gave us one living structure to clean naming, reconcile assets, expose gaps, and anchor every other stream of work.

What followed was not a clean sequence but a convergence of domains, architecture, engineering, controls, data modeling, semantics, and open-source frameworks all pushing forward at once. Identifiers conflicted everywhere: room IDs, equipment names, BAS points, PV strings. 

Buildings must perform long after construction, and LEED v5 signals this shift by emphasizing operational data, not just design intent. The work at PAE demonstrates what that future looks like: a building with a continuous, connected, and operational backbone, rather than siloed digital fragments.

Once we decomposed each system into its data, structure, and relationships, the building’s information became modular and reusable. A sensor stream could trigger a work order. A PV anomaly can trigger a comparison to utility draw. Once we decomposed the silos, we could recompose the systems to produce new insights and actions.

Decompose. Recompose. Reveal Intelligence.

The PAE System of Systems Activated

A Digital Twin isn’t a single model, dashboard, or app. The building can finally coordinate its own information.

Digital Twinning ensures that representations remain aligned with their real-world counterparts. When they stay connected, share meaning, and remain synchronized with the physical environment, they form a building-scale Digital Twin.

Proprietary is fine. Disconnected is not.

Short Video of the Living Building System of Systems: https://vimeo.com/onuma/paetwin

Three Things the PAE Living Building Needed

A system-of-systems only becomes intelligent when three fundamentals are in place. Whether you’re twinning a pump, a floor, or an entire campus, these are the required building blocks.

1. A Digital Representation of the Entity

A floor plan, equipment model, zone definition, or semantic graph, anything that defines the entity’s identity, boundaries, and attributes.

2. Live Data Connected to That Representation

Sensors, controls, meters, or systems must continually update the representation so it reflects what’s happening in the real world.

3. Understanding of Relationships

• Which sensors and assets belong to which rooms and systems
• How equipment, circuits, and loads relate across the building

PAE Invested in the Part Everyone Else Ignores

They opened their Living Building, including its electrical, mechanical, controls, and operational workflows, to the Coalition for Smarter Buildings (C4SB), the Linux Foundation community, and the broader industry. They exposed everything: gaps, inconsistencies, misaligned schemas, and the realities most owners keep hidden. 

We began by unifying BACnet, photovoltaic (PV), battery, occupancy, CO₂, and even utility-grid data into the cloudBIM foundation.

When SkyCentrics came online, the raw data exploded, thousands of points across PV, battery, BAS, and utility feeds. We still had to associate each point with the correct asset, fix naming, verify meaning, and understand where it lived in the system.

SkyCentrics Dashboard of PAE building sensor data

Rooms, equipment, panels, circuits, and spaces, all mapped so that live data could be attached to real things. The PAE Living Building is already exchanging information with the city’s utility network. That makes it an early seed of city-scale Digital Twins.

By the time we reached semantic alignment, the most challenging work had already been completed: cleaning geometry, reconciling schedules, mapping assets, fixing identifiers, and binding live data to physical locations. Once we established a few reliable cross-system anchors, a PV string tied to the right inverter, and an occupancy signal tied to an actual room. The dashboards had shown this data for months, but without shared meaning, it was hard to understand

When the Building Starts Talking to Itself

The first breakthrough arrived with a simple automation:

• A low-battery alert automatically generated a work order.

A small action, but a turning point. The system wasn’t just monitoring anymore; it was coordinating. That was the birth of a Digital Twin system: action, not just visualization.

The Pacific Northwest National Laboratory (PNNL) played a critical role in this effort, contributing data structures and alignment that accelerated the extraction of an RDF representation of the building. Their involvement signaled something bigger: the shift from files and diagrams to linked, computable data.

The building began to make sense. Relationships among spaces, assets, circuits, panels, sensors, and zones snapped into place, and the Digital Twin system started revealing what no siloed dashboard ever could.

One of the clearest examples came from the PV system. A sudden sunlight break can spike PV output, triggering penalties if the building can’t modulate fast enough.

And yet the work is not done.

Some vendors still refuse to share data, even when the owner paid for the sensors. That’s not a technology issue; it’s a business model issue. Our position is clear: systems that refuse to interoperate should not be specified.”

Because the most significant lesson from PAE is also the most promising:

The months of reverse engineering on this project can shrink to hours once owners adopt an open, cloud-first, semantically structured approach.

Execution Framework

Scaling this work requires structure, persistent IDs, semantics, and open data requirements set up front. C4SB is capturing these workflows, mappings, and semantic patterns in GitHub, allowing any owner or vendor to reuse them.

All are welcome, commercial or open-source, so long as it connects through open standards. If you want to move past the digital deadlock that has stalled the industry for decades, join us.