What I’m bringing to Monday Live — and why the next interoperability problem begins after two systems successfully connect

By Greggory Don Butler

For most of the history of automated buildings, interoperability has meant getting things to talk.

Different manufacturers. Different protocols. Different point names. Different databases. Different generations of equipment. Different ideas about what the building is.

That problem is not solved, but the industry has made extraordinary progress.

Now something important is happening.

We are moving from making systems connected toward making buildings machine-understandable.

NIST’s Building Digitization and Semantic Interoperability project describes an interoperable Digital Twin synchronized with the physical building and containing semantically rich representations of building systems and components. NIST is exploring knowledge graphs, machine learning and large language models while working toward standardized machine-readable semantic models capable of supporting analytics, automation and control.

NIST — Building Digitization and Semantic Interoperability:
https://www.nist.gov/programs-projects/building-digitization-and-semantic-interoperability

NIST also identifies ASHRAE 223 as part of this work and describes building-specific semantic models assembled using information from sources including BACnet systems, BIM models and building operations staff.

That is a major evolution.

The machine increasingly does not merely receive a point.

It can understand what that point represents, what equipment it belongs to, how components relate, what context surrounds them and potentially what action should follow.

Meanwhile, the Coalition for Smarter Buildings has moved major interoperability projects—including the Interoperable Building Box—into the Linux Foundation, with the stated goal of reducing fragmentation and enabling scalable open building infrastructure.

Linux Foundation — Coalition for Smarter Buildings:
https://www.linuxfoundation.org/press/coalition-for-smarter-buildings-foundation-enables-building-management-innovation-with-open-source-technical-project-contributions-to-the-linux-foundation

CNS/CP approaches another part of this problem through Connection Profiles: named descriptions of the provider, consumer, capabilities and context involved in a particular interaction.

CNS/CP:
https://cnscp.io/about.html

These developments attack different parts of an enormous problem.

But while looking at them together, another question became unavoidable:

What happens after the connection succeeds?

I initially misunderstood the Connection Profile

This is the part I want to discuss on Monday Live because the correction matters more than pretending I understood everything immediately.

When I first looked at CNS/CP alongside the TA-14 Authority Passport Protocol, I assumed the likely interoperability path would work like this:

CNS/CP would eventually produce a stable Connection Profile or bounded interface object.

TA-14 would receive that object.

Then TA-14 would evaluate it externally and determine what could safely enter a TA-14-governed runtime.

That was my model.

Anto Budiardjo corrected it.

His point was that if TA-14 has a cross-organizational interaction, the Connection Profile for that interaction is ours to author.

The Connection Profile is not something CNS/CP has to manufacture for TA-14.

It is the declared contract for the crossing itself.

What crosses?

What does not?

Who is the provider?

Who is the consumer?

What is the interaction?

What is returned?

Where does that interaction end?

That correction exposed something much larger.

The connection and the consequence are not the same architectural event.

CNS/CP can define a relationship across an organizational boundary.

But after something successfully crosses that boundary, another question remains:

Does the receiving domain possess sufficient present evidence, authority, continuity, scope and standing to turn that received information into consequence?

That was the seam.

So I built the TA-14 side of the seam.

The result is TA-14 Admissible Federation Architecture

Going back through the already-published TA-14 corpus revealed that the underlying rule existed before this CNS/CP discussion.

The TA-14 Authority Passport Protocol had already established a principle for carrying bounded authority context across independently governed domains:

Authority context may travel. Execution authority does not automatically travel with it.

The receiving domain must establish its own authority for consequence.

That principle has now been formalized into TA-14 Admissible Federation Architecture — AFA v1.0-RC1.

Its founding invariant is:

Authority context may cross domains.
Execution authority must be established locally.

That sounds simple.

It is not.

Because modern connected systems are very good at allowing one successful condition to silently become another.

Identity becomes trust.

Trust becomes authorization.

Authorization becomes presumed standing.

Standing becomes assumed permission.

Successful transport becomes successful execution.

A valid credential becomes a valid action.

A successful connection becomes permission to produce consequence.

AFA exists to prevent that collapse.

Machine-readable truth is not automatically execution authority

This is where the NIST work makes the question even more important.

Imagine a future building in which the digital representation is excellent.

The semantic model correctly identifies an air-handling unit.

It understands the unit’s components and relationships.

BACnet provides operational information.

The Digital Twin reflects the building.

Analytics identify an abnormal condition.

An AI system reasons across that information and proposes changing a setpoint.

Every part of that reasoning chain could be technically correct.

And the proposed execution could still be inadmissible.

Why?

Because knowledge and authority are different propositions.

The evidence could have become stale.

A technician could have established a protected maintenance condition.

The physical environment could have materially changed.

An authorization could have expired.

The proposed action could exceed the scope originally delegated.

The system could possess perfectly valid information without possessing standing to create the proposed consequence.

That gives us several architectural layers that should not be collapsed into one another:

Semantics can establish meaning.

Connectivity can establish a route.

Identity can establish who participated.

A Connection Profile can establish the declared contract for a crossing.

Evidence can establish facts about present or recorded reality.

None of those things, individually or collectively, automatically establishes:

This action may execute now.

That final proposition requires its own evidence and authority.

The Connection Profile is the crossing

The first bounded examination artifact is now AFA-IP-001 v0.3 — TA-14 Authority Passport Connection Profile for CNS/CP Boundary Examination: Passport Presentation & Acceptance.

It is deliberately bounded.

It is not CNS/CP certification.

It is not CNS/CP endorsement.

It is not OSTERA Working Group adoption.

It is not a completed CNS/CP registry publication.

It is not a claim of proven external interoperability.

AFA-IP-001 is a TA-14-authored examination artifact prepared for the proposed CNS/CP boundary so that the architectural separation can be inspected, challenged and eventually tested.

Its job is to answer a narrow question:

Can bounded authority context cross between independently governed domains without local execution authority silently crossing with it?

The architecture makes the boundary visible:

Issuing Domain → Authority Passport → Connection Profile → Receiving Domain → STOP

And after STOP, local governance begins:

Reality → Record → Continuity → Admissibility → Binding → Commit → Execution → Outcome

That STOP may be one of the most important parts of the architecture.

The receiving domain can know who issued the Passport.

It can know the lineage.

It can know the purpose.

It can know the delegation envelope.

It can verify integrity.

It can know freshness and revocation status.

It can accept the crossing, narrow it, hold it, reject it, quarantine it, suspend it or escalate it according to the boundary profile.

But none of those boundary dispositions, by themselves, create local Commit or Execution authority.

TA-14’s protected-consequence runtime remains responsible for its own governed determination before consequence.

Connection success is not admissibility.

Acceptance is not execution authority.

And now we can add another distinction:

Machine understanding is not machine permission.

The negative space may be more important than the positive space

This is where the Connection Profile becomes more interesting than an ordinary integration map.

We normally design interfaces by describing what is allowed through them.

AFA-IP-001 also defines what cannot cross.

For this profile, prohibited imports include local execution entitlement, TA-14 Local Lease, TA-14 Local Capsule, Commit authorization, Execution authorization, permission to produce Effect, and proof that the receiving domain’s present reality or evidence is sufficient.

That means the architecture does not rely on goodwill.

It does not say:

“We trust the receiving system not to misunderstand.”

It defines the negative space structurally.

Nothing omitted becomes permission by interpretation.

Or, in language TA-14 has used repeatedly:

Absence of refusal is not permission.

This matters well beyond one protocol.

AI agents will cross organizational boundaries.

Building systems will interact with cloud systems.

Digital twins will consume information from multiple owners.

Grid services will communicate with buildings.

Maintenance platforms will dispatch work into operating environments.

Financial systems will trigger operational consequences.

Independent AI systems will increasingly exchange credentials, requests, evidence and authority context.

The future is federated.

The question is whether authority becomes federated carelessly with it.

The Digital Twin can know the building without owning the consequence

This distinction becomes especially important as Digital Twins become more sophisticated.

A Digital Twin can represent reality extraordinarily well without possessing authority over that reality.

The twin may establish that a valve exists.

A semantic graph may establish what the valve serves.

Sensors may establish its current condition.

An AI system may determine that repositioning it would produce a desirable result.

A remote service may possess a valid identity.

A Connection Profile may establish exactly what information was exchanged.

And every one of those propositions may be true.

But another proposition still remains:

Is this specific execution admissible under current evidence, current authority and current conditions?

TA-14 treats that question as something that must be established rather than inferred from everything that came before it.

That is why the public TA-14 chain remains:

Reality → Record → Continuity → Admissibility → Binding → Commit → Execution → Outcome

And its determinations remain:

ALLOW / HOLD / DENY / ESCALATE

A sufficiently intelligent building must be capable not only of determining what could be done.

It must have an architectural location where consequence can stop.

HOLD must be something the architecture can actually mean.

This extends the building-industry interoperability conversation

AutomatedBuildings recently asked a crucial question:

What is the minimum trustworthy, machine-readable description of an existing building that lets AI help without forcing it to guess?

That remains an essential question.

NIST is directly advancing the underlying semantic problem: machine-readable models that represent building systems and relationships so increasingly capable applications can operate across interoperable information.

But successful semantic interoperability creates another question.

Suppose the AI understands the building perfectly.

Suppose the semantic model is correct.

Suppose the Digital Twin accurately reflects the physical environment.

Suppose the systems connect.

Suppose identity is verified.

Suppose the relationship is legitimate.

Suppose the request arrives intact.

Suppose the Connection Profile says the crossing is valid.

Who established that the receiving building is authorized to act on it now?

That is a different architectural burden.

This is the progression I think the industry increasingly needs to examine:

Can we connect?

↓

Can we understand each other?

↓

Can we prove what crossed?

↓

Can we establish what authority did not cross?

↓

Can the receiving domain establish present local admissibility?

↓

May the action commit?

↓

May the action execute?

↓

What record proves the outcome?

Interoperability therefore does not end when two systems successfully communicate.

Once those systems can produce physical, financial, environmental or human consequence, interoperability reaches an authority boundary.

Monday is not a presentation of a finished answer

This Monday, September 21, Anto has invited me onto Monday Live for a few minutes to explain how I arrived at this boundary, followed by discussion with the room.

That framing matters.

I do not want the room to simply agree with AFA-IP-001.

I want the room to try to break it.

The artifact contains explicit falsification conditions.

If successful Connection Profile acceptance necessarily conveys local execution entitlement, the proposed separation fails.

If TA-14 must redefine or absorb CNS/CP to consume the crossing, the bounded interoperability proposition fails.

If negative space cannot reliably be preserved, the seam is insufficient.

If the crossing cannot terminate before local execution entitlement, authority can leak across the boundary.

If previous acceptance remains valid after a material changed condition without revalidation, present-tense governance fails.

And if the evidence cannot be replayed without inventing missing continuity, the claim stays on HOLD.

That is what Monday should be.

Not:

Do you trust TA-14?

Not:

Do you trust CNS/CP?

Not even:

Do you trust AI?

The better question is:

Can two independently governed architectures meet at a declared boundary, prove exactly what crossed, prove what did not cross, terminate the crossing cleanly, and leave each side authoritative over its own domain?

If they can, we have something worth continuing.

If they cannot, the architecture should show us where it fails.

The future may depend on learning where authority stops

The smart-building industry has spent decades learning how to connect things.

Now it is learning how to make those connected systems machine-understandable.

AI is making that understanding increasingly consequential.

The next generation of interoperability therefore cannot merely answer:

Can these systems communicate?

Or even:

Do these systems understand one another?

It must eventually answer:

What crossed?

What remained local?

What authority survived the crossing?

What authority did not?

What changed after authorization?

What proves the receiving system still has standing to act now?

And what prevents correct information from becoming unauthorized consequence?

That is the boundary I am bringing to Monday Live.

The semantic model establishes meaning.

The connection establishes a route.

The Connection Profile defines the crossing.

The crossing establishes a record.

That record may become input to local governance.

But the crossing itself is not the permission to act.

Authority context may cross.

Execution authority must be established locally.

And perhaps the next great interoperability problem is no longer merely teaching machines how our buildings connect.

Inspect the work

TA-14 Federation & Authority — Connection Profiles, Authority Passports and AFA-IP-001 v0.3
https://www.ta14exchange.com/federation-authority

TA-14 Admissible Federation Architecture — AFA Showroom
https://www.ta14exchange.com/admissible-federation-architecture

TA-14 Admissible Federation Architecture (AFA) v1.0-RC1 — Zenodo
https://doi.org/10.5281/zenodo.22846133

CNS/CP — Connection Profiles
https://cnscp.io/about.html

NIST — Building Digitization and Semantic Interoperability
https://www.nist.gov/programs-projects/building-digitization-and-semantic-interoperability

Linux Foundation — Coalition for Smarter Buildings Foundation / Open Building Projects
https://www.linuxfoundation.org/press/coalition-for-smarter-buildings-foundation-enables-building-management-innovation-with-open-source-technical-project-contributions-to-the-linux-foundation