Seven Days From API Access to a Governed Operational Loop
A week ago, this was mostly a question.
Could an independent building-data environment, an AI-assisted workflow, real work orders, human actors, semantic relationships, and an external execution-governance architecture actually interact without forcing everything into one proprietary system?
Seven days later, the question has changed.
Now we are asking what happens next.
That change happened faster than I expected.
IT STARTED WITH ACCESS, NOT A DEMONSTRATION
ONUMA provided TA-14 access to the RE1 environment and API documentation.
RE1 is intentionally limited. It is a sandbox, not a fully populated operating building. Kimon Onuma was explicit about that: the model is stripped down because the purpose is to test the wiring between systems rather than pretend every piece of real building information already exists.
That limitation turned out to be useful.
TA-14 did not need a perfect digital twin.
It needed enough current building context and source identifiers to determine whether a proposed action could be connected to reality.
Thomas Dalbert provided the API path.
Within the first working session, we were able to retrieve the current ONUMA building structure and source identifiers and begin resolving relationships between the building, floor, space, and equipment context.
What had looked like a fairly abstract interoperability question became operational remarkably quickly.
Kimon’s response when the first request landed was simple:
“Great! We have liftoff.”
But the important part came next.
THE FIRST SUCCESS WAS A FAILURE
A work order was assigned.
The digital information existed.
The API worked.
The workflow worked.
A technician could receive the assignment.
And then TA-14 made the wrong location selection.
The original EISO-1 context had been associated with MR2-113. During the first API round, TA-14 selected a different space — EC2-131 — when creating the work-order request.
That distinction matters.
The ONUMA source record had not simply failed.
TA-14 made an incorrect selection.
Then the workflow, the floor plan, and the preserved building context exposed it.
This is where interoperability normally gets tempted to become reconciliation.
Change the location.
Correct the field.
Make the systems agree.
Continue the demonstration.
TA-14 did something different.
It stopped.
The existing evidence did not support the proposed physical consequence, so the determination was HOLD.
No silent correction.
No retrospective repair.
No pretending the previous state had never existed.
The error remained attributable to TA-14.
The corrected location was then established through the appropriate source and workflow, and a new chain proceeded from the changed reality.
That may sound like a small distinction.
I believe it is one of the biggest distinctions the automation industry is going to face.
Interoperability answers:
Can these systems exchange information?
Execution governance asks:
Is what they exchanged sufficient to justify what somebody is about to cause in the physical world?
Those are not the same question.
THEN THE HUMAN ERROR ARRIVED
A second work-order exercise produced another useful surprise.
The originating complaint and the work-order language conflicted.
The wording could have driven the technician toward the wrong diagnostic question.
We flagged it rather than interpreting our way around it.
Kimon responded that it was simply human error — he had typed the wrong wording as Facility Manager.
That is exactly the kind of thing a real building contains.
Humans mistype things.
Sensors fail.
Records are incomplete.
Equipment changes.
Authority changes.
People misunderstand each other.
AI makes plausible inferences.
The interesting architecture is not the one that assumes those conditions disappear.
It is the one that behaves correctly when they happen.
Again, the record was corrected prospectively.
Again, the prior state was preserved.
Again, the next decision did not get to borrow certainty from information that had already failed.
THURSDAY: FROM EMAIL THREAD TO LIVE WORKSHOP
By Thursday, what had started as API access had become part of the BOPping Your BIM workshop.
The broader conversation involved Kimon Onuma, Thomas Dalbert, Yong Ku Kim, Michael Bordenaro, and others looking at what happens when BIM, semantic information, humans, AI, asset-management thinking, and operational workflow begin touching the same building reality.
This was no longer a slide about what TA-14 might someday do.
The audience was looking at something that had already happened.
We had interacted with the building model.
We had received work.
We had encountered conflicting reality.
We had stopped.
We had obtained additional evidence.
We had allowed the source system and responsible participants to correct their own state.
And we had continued without rewriting history.
That distinction mattered.
The demonstration was not successful because everything worked perfectly.
It was successful because failure did not destroy the integrity of the process.
THE SPEED SURPRISED EVERYONE
The follow-up conversations may have been more interesting than the workshop itself.
Within hours, the group was already proposing the next bounded operational-loop test.
Angela Bolton brought fixed-asset and lifecycle information into the discussion.
An HVAC asset — AHU-1 — was selected.
The question became deliberately narrow:
What happens when a consequential decision depends upon warranty information that is not yet sufficiently established?
Instead of copying information into TA-14 and pretending TA-14 owned the truth, the architecture preserved the source boundary.
If ONUMA or another appropriate repository owns the warranty record, TA-14 should not become a second CMMS.
TA-14 should ask whether the required evidence exists, where it came from, whether it is attributable, and whether it is sufficient for the consequence under evaluation.
When the evidence was missing, the answer was not manufactured.
A human technician was assigned to look for the warranty documentation.
That is where the architecture became much more interesting.
Machine.
Human.
AI.
CMMS.
Building model.
Asset record.
Governance.
Each remained independent.
No architecture was required to surrender its native logic.
And yet they were able to participate in the same consequence chain.
Yong Ku Kim later described himself as “blown away by the rapid, agile collaboration within a few days,” contrasting it with months or even years of waterfall planning and meetings. He also noted how much of the dialogue and decision-making occurred within roughly 36 hours.
That may be the most important observation of the week.
WHY DID IT MOVE SO FAST?
Not because everybody agreed.
Not because one vendor controlled the stack.
And not because we created a giant integration specification before touching the building.
It moved quickly because nobody was required to abandon their native architecture.
ONUMA remained ONUMA.
The fixed-asset work remained independent.
The human technician remained a human.
The AI could analyze without becoming universal authority.
The Facility Manager retained the authority of that role.
And TA-14 did not need to own the building, the work-order platform, or the data.
It only had to answer its bounded question:
Does the present evidence and present authority support this proposed consequence now?
If yes: ALLOW.
If not yet: HOLD.
If prohibited: DENY.
If the issue exceeds the available authority: ESCALATE.
That small vocabulary becomes powerful when systems are allowed to disagree.
THE BUILDING BECAME THE REFEREE
I am keeping that phrase because it captures what happened.
Technically, however, the building is not becoming the authority.
It is becoming the common reference point between architectures.
ONUMA cloudBIM can tell us where an object is.
RDF and ASHRAE 223-style semantic relationships can help tell us what it is and what it connects to.
Operational systems tell us what has been requested, assigned, measured, completed, rejected, or changed.
Asset-management systems can contribute lifecycle evidence.
People contribute observations and authority.
Machines contribute measurements and physical capability.
AI can correlate and reason across those sources.
But none of those facts, individually, should automatically become authority to execute.
That distinction is now leading the group toward an Authority + Trust Graph.
The emerging question is whether a building can contain not only a graph of equipment and relationships, but a machine-readable graph describing who or what may assert, request, inspect, decide, fund, approve, execute, verify, or reject a consequence.
And even there, TA-14 adds one warning:
A graph can describe the possible path of authority.
It should not silently convert that path into present execution authority.
Present authority still has to bind to present reality.
FROM RE1 TO A REAL BUILDING
Michael Bordenaro identified the obvious next step.
His proposal was straightforward: prove the operational loop cleanly in the RE1 sandbox, preserve the record, and use that evidence to approach PAE Engineers about attempting the same kind of loop against a more demanding real-building context.
That is exactly how I believe this should progress.
Not:
“Trust TA-14 because we say it works.”
But:
Here is the record.
Here is where the first chain failed.
Here is why it failed.
Here is who made the mistake.
Here is the evidence that allowed the next chain to proceed.
Here is where humans remained authoritative.
Here is where machines remained machines.
Here is where AI helped.
Here is where the process stopped.
Here is where the governed operational loop advanced.
And here is what has not yet been established — including any claim of verified physical actuation that the evidence does not yet support.
Now let us try it somewhere harder.
WHAT HAPPENS AT 3,000 ASSETS?
RE1 is small.
That is part of what made this possible.
But consider what Kimon pointed out after reading the first account of the experiment.
We have exposed this much around essentially one building, a handful of workflows, and one AHU.
Now imagine a real facility with:
3,000 assets.
Different control systems.
Different manufacturers.
Different technicians.
Incomplete records.
Changing conditions.
AI agents.
Different authorities.
Warranty decisions.
Funding decisions.
Safety consequences.
Thousands of assertions moving through the building every day.
The errors and HOLDs we are finding are not failures of the experiment.
They may be evidence of conditions that already exist at scale but are often invisible.
That is why exposing them matters.
LET PEOPLE WATCH IT HAPPEN
Another lesson from this week is that this work should not disappear into a polished retrospective.
ONUMA and the broader BIMStorm community are publishing the evolving work, artifacts, and experiments as they happen at:
The work is also feeding directly into the Become the Building BIMStorm and the progression toward the Greenbuild program in New York.
The next near-term checkpoint is Greenbuild Live BIMStorm #2 on September 16.
The September and October online workshops are intended to lead toward the New York event.
That creates an unusual opportunity.
Instead of showing people only the finished architecture, they can watch the architecture encounter reality.
They can see:
the HOLDs,
the mistakes,
the corrected assumptions,
the missing evidence,
the independent systems,
the evolving trust and authority questions,
and whatever fails next.
That may be more valuable than a perfect demonstration.
WHAT CHANGED FOR ME IN SEVEN DAYS
A week ago, I was trying to explain an architecture.
Today, several independent people are helping expose where that architecture succeeds, where it fails, what terminology is wrong, and what needs to exist next.
Michael Bordenaro sent me a private note after one day of working together saying it felt as though we had been working together for twenty years.
I appreciate that deeply.
But what matters more is why that familiarity appeared so quickly.
Everyone involved is already trying to solve some version of the same underlying problem:
Buildings contain fragmented reality.
Authority is distributed.
Evidence is incomplete.
Systems are independent.
Humans make mistakes.
AI is becoming more capable.
And physical consequences still have to occur safely in the middle of all of it.
The industry does not need another architecture that hides those differences.
It needs ways to preserve them while still allowing work to happen.
That is what RE1 has begun teaching us.
The sequence TA-14 uses remains:
Reality → Record → Continuity → Admissibility → Binding → Commit → Execution → Outcome.
But after this week, those words feel less like a diagram.
They look like a building.
And the next question is no longer whether we can draw the architecture.
It is:
What happens when we let a real building challenge it?
That is where I hope we go next.
Follow the live BIMStorm work and artifacts:
Greggory Don Butler
Founder, TA-14 Authority
Contributing Editor, AutomatedBuildings.com
