Cover image: The PAE Living Building RDF Semantic Model with 127,000 AI Native Relationships between systems.
The Case for AI Native Registries, Operational Context, and Live Building Intelligence
Everyone is talking about AI.
Owners want to know how it will reduce costs, improve resilience, optimize energy use, and help facility teams do more with less. Vendors are rapidly adding AI features to products. Consultants are publishing roadmaps and maturity models for becoming AI-ready. The excitement is understandable, but after months of working with the PAE Living Building and participating in discussions across C4SB, cloudBIM, Semantic Bridge, Digital Building Profiles, and other industry efforts, I have become convinced that the biggest obstacle to AI has very little to do with AI itself.
The obstacle is trust. More specifically, it is whether a building can provide a trusted answer to a simple question: what is this thing, where is it, and is the information still correct?
That sounds obvious until you attempt to connect BIM models, PDFs, maintenance systems, controls systems, energy platforms, GIS systems, spreadsheets, and decades of accumulated operational knowledge into a single picture of a building. The problem is usually not that information is missing. The problem is that information exists everywhere, often under different names, with different assumptions, timestamps, and levels of authority.
The Battery Challenge
One of our recent exercises involved tracing battery systems within the PAE Living Building. The batteries were there. They appeared in the BIM model and in operational systems. We eventually found them all. The challenge was not locating the equipment. The challenge was agreeing on what we were looking at, their names, numbers, or IDs.
Several assets had generic, default, or unknown identifiers or labels that made sense only within a particular application. In one system, an object might simply be called “Battery.” In another, it might be represented by a vendor-specific identifier. In a third, it might appear as part of a larger assembly with little indication of its operational role. As we worked backward through the information, we found ourselves performing a surprisingly human task: establishing identity.
That meant agreeing that this specific object is Battery 3 of 8, that it is located in a specific room, that it corresponds to specific sensor streams, and that it participates in specific operational workflows. Finding an asset is not the same thing as having a shared operational understanding of that asset. The battery existed, but its operational identity needed to be established. Name, rank, and serial number.
Buildings Have Time-Series Data Too
Most building professionals understand the value of real-time sensor data. If a battery drops from 95% to 15% charge, yesterday’s reading is not useful. If energy consumption suddenly spikes, operators want to know immediately. If a critical alarm occurs, nobody wants to wait for tomorrow’s report. We instinctively understand that sensor data loses value when it no longer reflects reality.
What is often overlooked is that building context works the same way. Room numbers change. Equipment gets replaced. Assets move. Spaces are renovated. Systems are upgraded. Technicians make field corrections. Responsibilities shift. The rate of change may be slower than a temperature sensor, but the principle is identical: the information must remain current enough to be trusted. A room registry, an asset registry, and a building context model are slower-moving forms of operational state.
Consider an Uber app. The map is useful because it shows the vehicle’s current location. If the location is five minutes old, trust begins to erode. If the traffic data is one hour old, the application becomes useless.
Buildings are no different. A Digital Twin that contains outdated room assignments, obsolete asset names, or stale operational relationships no longer accurately describes the building as it exists today. It describes a historical version of the building. That is why a building cannot reason from yesterday’s data. Neither can people. Neither can AI.
Three Layers of Building Intelligence
Much of the discussion around Digital Twins, RDF, AI, and interoperability becomes confusing because we often treat these technologies as competing approaches. In reality, they solve different problems. A registry answers the identity question: what is this asset, where is it located, which identifier is authoritative, and which room is correct? A semantic graph answers the meaning question: what does this asset serve, what systems is it connected to, and why does it matter? Operational systems answer the current reality question: what is happening right now, is the battery healthy, is energy use normal, and has a technician already responded?
In the PAE example, cloudBIM provides a current registry for spaces and assets. Semantic technologies such as RDF and ASHRAE 223P help describe relationships. Platforms such as SkyCentrics provide live operational information about energy, equipment, and system performance. None of these layers replaces the others. The registry tells us what something is. The graph tells us why it matters. Operational systems tell us what is happening now. Together, they create trust.
Humans and AI Need the Same Foundation
One of the most interesting realizations from this work is that humans and AI agents require almost exactly the same information. A facility manager wants to know where an asset is located and whether it is operating correctly. A technician wants to understand what systems are affected before performing a repair. An energy manager wants to understand performance trends and operational impacts. An emergency responder wants to know what critical systems are nearby. An AI agent asks essentially the same questions. The difference is not the information. The difference is who is consuming it.
Both humans and AI require a trusted identity, a reliable location, operational context, current state, and meaningful relationships. If the human and the AI agent are working from different assumptions, they will inevitably reach different conclusions. If they share the same foundation, they can reinforce each other. This is why I increasingly believe that AI Native is not really about AI. It is about creating environments where intelligence can participate. Some intelligence will remain human. Some intelligence will be agent-assisted. Some intelligence will become increasingly automated. The goal is not to replace people. The goal is to ensure that people, software, analytics, automation systems, and AI agents are operating from the same understanding of reality.
From Stored Data to Live Intelligence
The built environment has spent decades producing files. PDFs, CAD files, BIM models, spreadsheets, manuals, and reports all have value. They capture knowledge at a point in time. But operations happen in the present. As AI enters the industry, the distinction between historical information and current reality becomes increasingly important.
A file can tell us what someone believed about a building. A live registry can tell us what the building is. Operational systems can tell us what the building is doing. Semantic models can tell us why it matters. Intelligence emerges when all of these work together.
The organizations that succeed in the AI era will not necessarily be the ones with the most advanced AI tools. They will be the ones that establish trusted registries, maintain operational context, connect systems through practical interfaces, and continuously align digital information with physical reality.
That is the foundation of AI Native readiness. The registry tells us what something is. The graph tells us why it matters. Operational systems tell us what is happening now. A building cannot reason from yesterday’s data, and neither can the people and AI agents responsible for operating it. And this is how humans and AI become AI Natives.
A Call to Action
The industry does not need another PowerPoint about Digital Twins, AI, or interoperability.
It needs working examples.
The cloudBIM Working Group at C4SB is bringing together owners, operators, technologists, software providers, standards organizations, and researchers to test these ideas on real buildings.
If this article resonates with you, don’t just read about it.
Participate.
Bring a building. Bring a BIM. Bring a sensor. Bring a dataset. Bring a use case.
Help us move from theory to operations.
