A proof that persistent IDs, shared data, and owner governance can let multiple teams build without vendor lock-in.
The first building was the real PAE Living Building in Portland, Oregon, one of the most advanced commercial buildings in the United States, engineered by the very teams occupying it.
The second was a cloud-based sandbox environment derived from the same operational data, semantic structure, and persistent identifiers.
Together, they became a test case for a question the industry still struggles to answer:
Can multiple teams build on the shared operational context without creating new silos?
The real lesson is not that a few teams moved fast. The real lesson is that interoperability is not primarily a technology problem. The technology already exists. Persistent IDs, RDF Turtle files, APIs, semantic relationships, and open standards have been available for years.
The harder challenge is willingness.
Willingness to collaborate. Willingness to stop protecting silos. Willingness by owners to require that data remain aligned instead of allowing every vendor to create another disconnected system.
That is what made this different.
For readers unfamiliar with the PAE Living Building and the year-long interoperability work leading to this exercise, see “From Models to Meaning: Connecting the PAE Living Building.”
PAE did not ask for another isolated application. They supported a shared context in which building data could remain connected, persistent, and reusable. Without that governance, the outcome would have been familiar: each vendor importing the data into its own platform, remapping it, and creating another silo.
That was not the case here.
Over the past year, Onuma, SkyCentrics, and teams involved with the Coalition for Smarter Buildings (C4SB) aligned the PAE building data. Then we decided to test something simple:
How quickly could entirely new teams build with minimal coordination?
The Foundation: One Year Before Six Days
The timeline was six days. The foundation took a year. The integrations took days.
This was not about creating two disconnected buildings. It was about proving that multiple operational environments can remain aligned to the same building through shared identifiers and open relationships.
What was accomplished in a six-day cloudBIMStorm Exercise
Over the past year, Onuma, SkyCentrics, and teams involved with the Coalition for Smarter Buildings (C4SB) have been developing the operational model of the PAE building. The work connected live infrastructure, building relationships, and persistent IDs into a shared cloudBIM environment.
At the same time, Fire Chief Victor Esch helped define and validate emergency-planning use cases. The question was practical: what information would emergency responders actually need in a crisis? Spaces, equipment, sensor references, fire-spread scenarios, shutoffs, and building context all had to remain connected to the same underlying data.
This was not theoretical semantic modeling for its own sake. It was grounded in a real building, real operational needs, and real emergency response scenarios.
The exercise used the real PAE Living Building and live operational data, but teams worked within a cloud-based sandbox environment derived from the same semantic structure and persistent identifiers.
This allowed rapid experimentation without disrupting live building operations while keeping every system aligned to the same operational context.
Both environments were intentionally simple:
Persistent IDs for spaces and equipment.
Clear relationships between building elements.
RDF Turtle files that could be shared.
APIs that could connect live operational data.
One rule: use the same IDs, add what you need, and return it without breaking alignment.
The important point is that the six-day result did not come from nowhere. A year of preparation made it possible.
Minimal requirements for keeping building systems aligned through persistent identifiers
The Test: Open the Exercise
So we launched a six-day cloudBIMStorm exercise.
We provided the core data files, persistent IDs, shared semantic structure, and basic guidance. Then we stepped back and let the teams work independently.
The test was not whether Onuma could build something. We already had ZAiMap.ai working from the same foundation. The real test was whether other teams, using their own tools, could build or extend the model without creating new silos.
Sandbox cloudBIM environment derived from the PAE Living Building for emergency-planning scenarios
Onuma / ZaiMap.ai user interface for emergency responders to access real-time data
That is where the exercise became important.
Verdicity emergency-planning interface built from the same shared building data
Alexander Hubik and the team at Verdicity, whom we had never worked with before, built an emergency-planning interface using the exact same Turtle file and persistent IDs as Onuma’s ZAiMap.ai. In six days.
They did not reinvent the building structure. They did not remap the data into a separate proprietary model. They used the shared model.
Shared persistent identifiers connecting cloudBIM and KNX systems
At the same time, Duncan Greene of One SightSolutions used KNX to extend the model with building-automation objects while maintaining the same persistent identifiers. HVAC equipment, controls, and related automation information could be added without breaking alignment.
Onuma / ZaiMap.ai user interface of the PAE building with a fire spread scenario using Skycentrics data
Skycentrics Time Series data from PAE Building visible inside the Onuma interface
SkyCentrics continued the live operational connection, making time-series and sensor data visible through the shared context into the Onuma System and ZaiMap.
Different teams. Different tools. Two operational environments. One aligned building context. No silos.
Why This Matters
Normally, this is where building data breaks.
A vendor arrives. They build an application. They export or import the owner’s data into their own platform. They remap the rooms, equipment, and assets to their own schema. It works for a while, but the building changes. Equipment moves. Sensors are added. Rooms are renamed. Data becomes stale.
Then the owner has another silo.
cloudBIMStorm demonstrated a different model.
Instead of asking each vendor to maintain its own disconnected copy of the building, the owner can require every system to reference the same persistent identifiers and shared operational context.
That changes the entire procurement question.
Instead of asking, “Can you build us a system?” owners should ask:
“Can you use our persistent IDs?”
“Can you connect to our shared building data?”
“Can you return your data in a way that other systems can use?”
“Can you add value without locking us in?”
Those are governance questions, not technology questions.
The Owner Lesson
This is the most important point for owners.
If you do not require alignment, you will end up with silos.
Not because vendors are bad, but because that is how the market defaults. Every vendor optimizes for its own platform unless the owner requires a shared foundation.
PAE showed another path.
The owner’s role is not to pick one magic platform that solves everything. The owner’s role is to establish the rules of engagement:
Persistent IDs stay persistent.
Building data remains owner-controlled.
Systems connect through open relationships and APIs.
New contributions come back without breaking the model.
Vendors can still innovate. They can build their own interfaces, analytics, controls, dashboards, emergency tools, and applications. But they do it on top of the same model.
That is how you get competition without fragmentation.
Open standards and open source connections will enable any system to stay aligned with the source data
The Bottom Line
It is simple. Persistent identifiers anchor both operational environments to the same building context. Turtle files share relationships and meaning. APIs connect live data. Governance keeps vendors aligned.
These basics scaled across multiple teams in six days.
The pattern is proven: PAE’s building, PAE’s commitment to breaking silos, Victor Esch’s emergency-planning validation, Onuma’s cloudBIM, SkyCentrics’ live data, ZaiMap.ai’s emergency interface, Verdicity’s six-day build, and KNX’s automation extension.
Real building. Real teams. Real results.
The next step is not more theory.
The next step is for owners to ask differently.
Do not ask for another closed system.
Require persistent IDs.
Require vendors to return connected data instead of creating another silo.
Require vendors to add value without capturing the data.
This is not complicated. But it is different.
The technology already exists. The remaining question is whether owners are willing to require alignment instead of accepting another generation of silos.
Part 1 of 2
Next: How to make this work in your building. The cloudBIMStorm model explained. What owners and developers need to do first.
The vendors named here are examples, not endorsements. The cloudBIMStorm model is open. Others can build on the same shared foundation while maintaining persistent alignment.
