Seven Days. Zero Meetings. The Systems Connected.

The Connection Took Minutes. Then the Data Began to Behave Like a Building.

The myth that interoperability requires years of custom master-systems integration is holding the industry back.

Building integrations are supposed to begin with meetings.

This one began with a LinkedIn chat, a simple question, and a link.

In seven days, a digital building model became a place where independent systems could meet, even though the people never did.

The systems recognized the same building objects, preserved their identities and relationships, performed different work, and returned what they learned. The data did not merely describe the building. It began to behave like the building.

So last Sunday, we stopped talking and connected.

We sent Greggory a link to a public online location where the building had been shared digitally, its spaces, equipment, identities, relationships, and meaning. The location happened to be GitHub, but the platform was not the point. What mattered was that another system could understand what had been shared.

Greggory asked for a secure connection that would let his system retrieve the building information directly. We sent the instructions and an access token, the digital equivalent of giving an authorized visitor a key. Within minutes, his system connected, recognized a real-world building object, and began using it.

No kickoff meeting. No integration workshop. No master systems integrator explaining the systems to each other.

Then Angela Bolton entered through a completely different domain. Both participants used the same building context, worked independently, and returned results connected to the same building identities and meanings.

We documented the progress, failures, and corrections as they happened.

It is now the second Sunday.

This is not a proposal for how interoperability might work someday.

It just happened.

The Test Began With a Real, Occupied Building

A sandbox only matters if it represents the complexity of a real building.

The PAE Living Building in Portland integrates design information, controls, energy data, work orders, and geospatial context across 3,410 component records and approximately 195,000 relationships. It is not perfect—but that’s why it is useful.

It is not perfect. That is precisely why it is useful. Real owners operate changing systems of systems maintained by different companies, people, and technologies over decades.

But we did not invite experimental systems directly into an occupied building.

We used RE1, a bounded sandbox containing the same kind of building data and meaning in a format others could safely inspect, connect to, and test. It allowed us to move rapidly without putting live building operations at risk.

PAE proves the connected building is real.

RE1 gives others a place to jump in.

The Future Took About Ten Minutes

We are often told that connecting building systems is years away. That’s only true if everything must be integrated at once before anything is allowed to happen. We took a different path: we shared just enough context for an independent system to understand one real object.

RDF acted as a Rosetta Stone, giving independent systems a common understanding of the building’s identities and relationships without requiring them to share the same internal architecture.

We did not debate data formats, schemas, or software platforms. We did not manually translate every field or meet to explain what the data meant.

RDF was not the destination. GitHub and the secure connection were simply tools that allowed independent systems to recognize the same building reality.

Once that technical agreement was in place, we connected.

The technology was not waiting for the future.

We were.

We didn’t just discuss interoperability in theory; we lived it. Here is the exact, unvarnished log of what happened when we connected our systems without a single meeting.

The First Useful Answer Was “No”

The first useful answer that Greggory’s system returned was not “yes”. It was HOLD.

His TA-14 governance system discovered a real power disconnect labeled EISO-1 and preserved its existing asset ID rather than creating a duplicate. It then evaluated the proposed action through its own governance process.

The systems agreed on the device, but Greggory’s system could not verify the requester’s authorization to act. It returned that decision as structured evidence tied to the same building object, and the missing authorization was converted into a facilities request.

That refusal was more valuable than an automatic yes. It demonstrated that connectivity does not have to mean uncontrolled action.

The first external work-order transaction then returned a server error. We reproduced it, traced it to a mismatch between asset IDs, corrected it, and succeeded on the next attempt. Later, insufficient human evidence led to the work order being reopened.

We did not hide the failures. We used them.

That is what a trustworthy operational building loop should do: connect, evaluate, stop safely, expose the problem, correct it, and preserve the evidence.

Why Our Failures Mattered

In traditional custom integration, errors are often buried or quietly patched by an integrator to save face. In an open, decentralized ecosystem, failures are valuable diagnostic data. Our test highlighted three key lessons:

• Failures are debugging maps: The initial server error from the external work-order transaction was traced to a simple mismatch between asset IDs. Because we used stable, shared IDs, we diagnosed, corrected, and successfully re-ran the transaction in minutes—not weeks of troubleshooting.
• Controlled stoppages prove the safety loop: The TA-14 system’s refusal to act without verified authorization (the “HOLD” on EISO-1) demonstrated that connecting systems doesn’t mean giving up control. A safe “no” is infinitely more valuable than an unchecked “yes.”
• Continuous verification keeps the loop honest: Reopening the work order due to insufficient human evidence proved that the operational loop is self-correcting. It demands evidence at every stage, preventing incomplete or unverified work from slipping through.

Then the Same Data Found a Financial Problem

The power disconnect was only the beginning.

Angela Bolton of Fixed Asset Consultant approached the same building data from a completely different direction.

Within hours of receiving access, her assessment pulled 95 component records through the RE1 connection. It identified lifecycle and warranty gaps, including expired labor-warranty dates and missing acquisition-cost or value information.

The goal wasn’t just data retrieval; it was value. Could a finding become a work order or capital-planning input, all tied to the same asset ID so no one had to reconstruct the relationship?

Greggory examined authority and permission. Angela examined the asset lifecycle and financial consequences. Neither of the outside systems was built as part of our ONUMA platform. Neither participant had to adopt the other’s architecture or attend a joint integration meeting.

They entered through a shared building context, performed different work, and returned results that retained the building’s identities, relationships, and meaning.

The discovery continued all week.

Even the Stories Connected

The systems connected without coordinating. Then our stories did the same.

Greggory described the governed HOLD in When the Building Said No for AutomatedBuildings. Angela published the fixed-asset perspective on her own website. I am adding the building-owner and digital-twin perspective.

We did not coordinate an approved account. Each of us followed the work from a different domain and published what we saw.

Like the systems, our perspectives remained independent but connected around the same building evidence.

A Connected Point Is Not Yet a Smart Building

Building automation has spent decades connecting controls, sensors, meters, and equipment. But a connected point is not yet building intelligence.

A temperature reading becomes useful when it is connected to the space, the equipment serving it, an active complaint, the responsible party, and the permitted action.

A building-automation point becomes more valuable when independent applications can connect it to the same identities used by design models, work management, emergency response, and capital planning.

Each system should contribute what it does best while preserving the owner’s shared building context. Controls specialists do not need to become fixed-asset accountants. Asset consultants do not need to become automation programmers. AI agents should not be allowed to act merely because they found a connection.

A master systems integrator can still help coordinate, commission, and secure complex systems. But the integrator should not become the permanent translator, gatekeeper, or owner of the relationships between them.

If every new connection depends on a single company to manually explain and maintain it, that is not interoperability; it is vendor dependency. Owners who choose the former gain a digital asset; those who settle for the latter are simply paying rent on their own data.

Owners: Ask What Can Connect This Week

An “open systems” presentation is not proof that anything can connect.

Owners should stop accepting claims that interoperability is too complicated to demonstrate or that only one master platform can make their systems work together.

You do not need to connect an entire building or portfolio to begin.

Choose one real owner question and one representative building object. Ask an outside system to find it, preserve its identity, use the available context, do something useful, and return what it learned.

Do not accept an export as proof of interoperability. Ask whether the identities, relationships, and meaning survive outside the application.

Do not accept “the building is too complex” as a permanent excuse. Buildings are complex. That is precisely why their knowledge must be accessible, connected, and testable.

You do not need a multi-year master integration plan to prove the first connection. You need one useful question, shared identity, enough context to understand it, a controlled connection, and participants willing to jump in.

Ask your vendors what they can connect this week, not what they plan to integrate someday.

What to Ask Your Vendor This Week

• Can you connect to an existing asset ID without creating a duplicate?
• Can you read from and write to our shared building context without proprietary middleware?
• What one specific building question can you answer by connecting to this data this week?
• Does the data you return retain its building identity and relationships outside of your application?

The Evidence Is Open. The Work Is Continuing.

We are not asking you to believe another digital-twin claim. We are showing you the evidence.

The building model is available. The data is public. The presentations, timeline, articles, results, and documented failures show what happened from Sunday to Sunday.

• Review the Sunday-to-Sunday evidence and presentations
• Read Greggory Don Butler’s account: When the Building Said No
• Read Angela Bolton’s fixed-asset perspective
• Inspect the RDF building model used for the test
• Explore the public RE1 repository

Much of the initial connection happened within minutes. We spent the rest of the week discovering what came next: another domain, returned results, visible failures, corrections, and preserved evidence.

We began with a Living Building and carried its connected context into a sandbox. There, the data began to come alive.

But this is not where the experiment ends. We are continuing to connect systems, test what they can contribute, and publish what we learn. The next results will be presented during the September 16 Greenbuild webinar.

Here is the building. Here is the data. Here is how we connected.

If your system is ready, jump in.

If you are an owner, ask why your systems and vendors are not already doing this.

The risk is no longer in connecting your systems; it’s in staying disconnected and watching your building’s knowledge base remain trapped in siloed software.

_________________________________________________

Black and White Photos by Victoria Wang

Creation of Adam: Wikimedia
Timeline: Onuma prompt to ChatGPT