Researched by BEAST Library Curator | Verified by Harper | Quality: 8.4/10

The Portability Clause: Why Your Next Building-OS Contract Should Name a Data Standard, Not a Vendor

BLUF: The Building-as-a-Service (BaaS) and "building operating system" category spent 2025 fighting over apps — dashboards, fault detection, autonomous control. In 2026 the decision that actually determines whether your building stays free or gets locked in has moved one layer down: who owns the semantic model of your data. If your next BMS, BaaS, or analytics contract does not specify a portable, standards-conformant data layer, you are not buying software — you are renting the keys to your own building. Here is the one clause to add before you sign, and how to verify a vendor is telling the truth about it.

What changed: the moat moved from the app to the ontology

For a decade the pitch was the application. A vendor would connect to your BACnet network, ingest points, and sell you a layer of intelligence on top — analytics, optimization, a tenant app. The problem is that the value was never really in the dashboard. It was in the tagged, structured, machine-readable model the vendor quietly built underneath it: every chiller, AHU, VAV box, and sensor labeled, related to its parent system, and made queryable.

That model is the asset. When it lives only inside one vendor's cloud, switching vendors means re-modeling the entire building from raw points — a project that can take months and easily costs more than a year of the subscription you were trying to escape. Vendors like PassiveLogic have made this explicit: their pitch is that the platform "automatically structures, labels and fuses building data into an ontology," and through the DOE-backed Quantum digital-twin work they argue the ontology — not the app — is the durable layer. BrainBox AI (now part of Trane Technologies) and a field of building-OS platforms are converging on the same idea from different directions.

The strategic read for an owner-operator: do not evaluate building-OS vendors primarily on the app. Evaluate them on whether the data model they build is yours, portable, and conformant to an open standard. The app is a 12-month decision. The data layer is a 10-year one.

The standards war is consolidating — which is good news for buyers

The single most important development of the past year is that the smart-building metadata standards stopped competing and started merging. This matters because a fragmented standards landscape is itself a form of lock-in — if every vendor "supports semantics" in a different dialect, none of them are portable.

Three threads are now aligning:

Layer What it actually is Maturity (mid-2026) What to put in the contract
BACnet / Modbus / OPC UA Communication protocols — how devices talk Mature, mandated in many tenders "Open-protocol connectivity required"
Project Haystack Tagging convention for points Mature, widely deployed "Points tagged to Haystack 4+"
Brick + RealEstateCore De-facto metadata ontology (equipment + topology) Harmonizing; production-usable "Model exportable as Brick/REC RDF"
ASHRAE 223P Formal semantic standard (RDF) Proposed — not finalized "Roadmap to 223P conformance"

Here's what I'd do if this were my building

I would add one clause to every BMS, BaaS, and analytics RFP this year. Call it the data-portability clause. It has three verifiable parts:

  1. Ownership. "The semantic model of the Owner's building (equipment hierarchy, point labels, and relationships) is the property of the Owner, not the Vendor." This is a one-sentence change that turns the model from the vendor's moat into your asset.
  2. Exportability. "The Vendor shall, on request and at no incremental charge, export the full building model in a Brick/RealEstateCore-compatible RDF (or documented machine-readable) format." If a vendor can only export a CSV of point names with no relationships, the model isn't really portable — you'd be rebuilding the topology by hand.
  3. Roadmap. "The Vendor shall provide a written roadmap toward ASHRAE 223P conformance." You can't demand conformance to an unfinalized standard, but you can demand the vendor have a plan — and the answer tells you whether they intend to keep you portable or keep you captive.

How to verify the claim isn't theater: ask for a sample export from an existing client building (anonymized). A vendor genuinely built on an open model can produce one in days. A vendor whose "ontology" is marketing will stall, and that stall is your answer. As the 2026 commentary on semantic layers notes, when every vendor claims "ontology" and "AI-ready knowledge layer," the discriminating question is what the layer does in practice — not what the slide says.

APAC angle: Singapore is already pricing this in

This isn't a Western-market abstraction. Singapore's BCA Green Mark 2021 "Intelligence" criteria explicitly encourages open-protocol connectivity — BACnet Secure, OPC UA, REST/HTTPS/MQTT — and references an "Asset Ontology" to standardize semantic descriptions of building assets and their relationships. Projects can also contribute performance data to the SLEB Smart Hub for dynamic benchmarking. For a Taiwan or APAC owner-operator, the implication is direct: the open, semantically-modeled data layer is moving from a nice-to-have into the certification scoring itself. Buying a locked-in, dialect-only platform now is buying a future Green Mark gap. (BCA and IMDA extended the same open-data philosophy to the Green Mark for Data Centre 2024 criteria — relevant given APAC's data-center build-out and TSMC-driven power demand.)

The contract-design lesson from the HVACaaS side

The BaaS commercial model — paying for an outcome (energy target, equipment availability, response time) rather than a box — is growing fast: recurring service agreements captured roughly 55% of HVAC industry revenue in 2024, a segment growing at about 8.3% per year per industry analysis of HVACaaS models. Vendors cite preventative-service savings of up to ~30% and downtime reductions of 35–45% — treat those as supplier-reported ranges to validate against your own meters, not guarantees.

But here is the cross-cutting lesson that ties the two halves together: outcome-based contracts and portable data layers fail for the same reason — the measurement infrastructure wasn't designed at contract inception. An HVACaaS SLA you can't verify in real time is unenforceable; a building model you can't export on demand is unportable. Both are decided by clauses, not technology, and both are nearly impossible to retrofit after signing. The right time to win this is in the RFP, not the renewal.

Bottom line

The building-OS market is maturing past the dashboard. In 2026 the questions that protect a portfolio are unglamorous and contractual: Do I own my building's semantic model? Can I export it in an open format? Does my vendor have a path to 223P? Can I verify my outcome SLA in real time? None of these require new technology. All of them require you to ask before you sign. For deeper context on the case for independent orchestration over single-vendor point products, see our Library analyses and the Today in CRE trend stream.

Have a question about this topic? Ask our CRE AI Agent →