Standard / Charter

Founding charter

The document that states what this is for, whom it serves, and what it deliberately will not do.

THE BUILDING UNDERSTANDING STANDARD

Founding

Charter

A vendor-neutral foundation for portable building understanding

Version 0.1 · Discussion Draft · July 2026

“Operational understanding is infrastructure. It belongs to the building owner, and it must endure.”

THE CORE BELIEF OF THIS CHARTER

WORKING DOCUMENT FOR REVIEW AND DISCUSSION

Contents

1 Preamble

2 Core Belief

3 Mission

4 Vision

5 Rights of the Building Owner

6 Guiding Principles

7 Scope and Boundary Model

8 Portable Representation and Freedom of Experience

9 The Reconstruction Guarantee

10 What This Standard Is Not

11 Practical Success Tests

12 Governance Commitments

13 Closing Declaration

Status of this document

Version 0.1 is a discussion draft, published to establish intent and invite comment. It defines principles and obligations, not schemas or encodings; those follow in the technical specification.

The words must, should, and may are used here in their ordinary sense. They will be given formal normative meaning in a later version, alongside conformance profiles and test suites. Nothing in this draft is final.

Charter at a Glance

The Building Understanding Standard exists so that a building owner can preserve, transfer, recover, and extend the complete operational understanding of a building without depending on any single vendor, software platform, or individual career.

This page summarizes the charter. Sections 1 through 13 are the authoritative text.

The reconstruction guarantee

A compliant export must be self-sufficient: any compliant system must be able to rebuild the same building understanding from it, without reverse-engineering proprietary databases or starting the building over from scratch.

Five founding truths

Buildings outlive software. The standard must remain useful across decades of platform and technology change.

Knowledge should outlive careers. Operational understanding must survive retirement, turnover, reorganization, and the loss of institutional memory.

Owners own the understanding. The operational model, meaning, representation, and history of a building are owner assets.

Vendors should compete on value. A vendor relationship should endure because the vendor innovates, not because the owner is trapped.

Portability must preserve meaning. A data dump is not enough. Context, intent, relationships, provenance, and representation must move with the data.

The success test

The standard succeeds only if…

A building’s understanding survives every vendor, every upgrade, every software replacement, and every staff change.

1  Preamble

Buildings are among the longest-lived assets in the world, and they never stop changing. Tenants turn over, equipment is replaced, spaces are repurposed, operating requirements shift, and technology advances. What routinely fails to persist is the operational understanding accumulated through years of design, commissioning, maintenance, troubleshooting, and adaptation.

Vendors change. Software is sunset. Contracts end. Integrators move on. Experienced staff retire. The building remains — but too often its understanding starts over from scratch.

That loss is not inevitable. It is a design failure. The industry has treated operational knowledge as a temporary by-product of software and service relationships rather than as a durable asset of the building itself.

A building should never have to relearn what it already knows.

This charter sets out the principles for an open standard that preserves the operational understanding of a building across time, platforms, vendors, and people.

2  Core Belief

Operational understanding is infrastructure. It is as fundamental to the long-term performance of a building as its physical systems, drawings, and records.

That understanding belongs to the building owner. It must not be trapped inside proprietary databases, undocumented interfaces, visualizations that cannot be reused, or the memory of a few individuals.

Technology should build on a building’s accumulated understanding — never erase, obscure, or hold it hostage.

3  Mission

The mission of the Building Understanding Standard is to define an open, vendor-neutral, durable, and extensible framework for preserving, transferring, recovering, and extending the operational understanding of buildings throughout their lives.

The standard exists so that every new platform, vendor, or team begins from what the building already knows, instead of reconstructing it.

4  Vision

We envision a future in which building owners move freely between technology partners while retaining the full meaning, history, representation, and operational intent of their buildings.

In that future, vendors compete on the quality of their intelligence, controls, workflows, user experience, and service — not on the cost of leaving them.

The goal is not to remove vendors from the relationship. It is to make the relationship beneficial rather than coercive: a vendor remains because it creates value, not because the owner cannot leave.

5  Rights of the Building Owner

A compliant implementation must uphold seven rights of the building owner.

OWN

The owner controls the complete operational understanding of the building — not merely a subset of raw point values or exported reports.

PRESERVE

Knowledge, intent, representations, relationships, decisions, and history endure across decades and organizational transitions.

TRANSFER

The owner can migrate between compliant systems without losing meaning, context, structure, provenance, or reusable representation assets.

UNDERSTAND

The building model is documented, inspectable, and interpretable through open structures rather than hidden behind an opaque black box.

EXTEND

Future technologies can build on the existing understanding of the building without requiring the owner to begin again.

RECOVER

If a vendor, product, or service provider ceases to exist, the building’s operational understanding remains intact and can be reconstructed by another compliant implementation.

CHOOSE

The owner selects vendors on capability, performance, service, and value rather than on the cost of escaping lock-in.

6  Guiding Principles

These principles govern every design decision made under this charter.

Owner first — The interests and continuity of the building owner take precedence over any vendor’s preferred implementation.

Vendor neutrality — The standard must be implementable by competing vendors and must never require dependence on a single proprietary platform.

Semantic portability — Portability must preserve meaning, relationships, units, intent, provenance, and context, not merely transport raw values.

Durability — Stable identifiers and versioned semantics must allow understanding to survive technology cycles measured in decades.

Transparency — Core structures, schemas, relationship vocabularies, conformance requirements, and migration behavior must be openly documented.

Extensibility — Governed extension points must let innovation evolve without fragmenting the common foundation.

Knowledge preservation — Human rationale, assumptions, lessons, field knowledge, and decisions are first-class parts of building understanding.

Import and export symmetry — Anything required to reconstruct a compliant implementation must be exportable, and a compliant importer must be able to ingest it without reverse engineering.

Open governance — The standard must evolve through a transparent, multi-stakeholder process with public proposals, versioning, conformance tests, and reference tools.

Beneficial competition — The standard protects owner continuity while leaving vendors meaningful room to differentiate through genuine innovation.

7  Scope and Boundary Model

The standard draws a deliberate boundary between the portable understanding of the building and the proprietary methods vendors use to create value. This boundary protects the owner’s asset without turning every implementation into the same product.

The boundary test

If it describes the building, it belongs in the standard. If it describes the software experience, it belongs to the vendor.

7.1  The required neutral substrate

Every compliant implementation must support a canonical, addressable foundation sufficient to describe and reconstruct the building’s understanding. That substrate includes, at minimum:

Building identity — Stable identity, location, lifecycle context, and ownership information.

Spaces and spatial structure — Sites, buildings, floors, zones, rooms, and other spatial entities.

Systems and assets — Physical and virtual equipment, systems, assemblies, and their intrinsic properties.

Points and semantics — Measurements, commands, states, units, ranges, quality, and meaning.

Relationships — First-class, typed, addressable links such as contains, serves, measures, controls, connected-to, located-in, applies-to, and derived-from.

Operational intent — What the building or system is expected to achieve, including objectives, targets, constraints, schedules, and references to the sequences that implement them.

Operational history — Events, alarms, trend context, changes, and other durable records required to interpret behavior over time.

Human knowledge — Rationale, assumptions, commissioning knowledge, field notes, lessons learned, known quirks, and decisions.

Documents and resources — Linked drawings, manuals, sequences, specifications, photographs, and other owner-controlled artifacts.

Portable representation — Floor plans, schematic layouts, equipment graphics, component placeholders, point bindings, and navigation structure.

Governance and provenance — Authorship, timestamps, approvals, versions, source, confidence, change history, and reason for change.

7.2  Extension interfaces

The standard defines open interfaces for attaching insights, recommendations, analytic results, diagnoses, forecasts, and proposed changes to the neutral substrate. Each result must identify its scope, provenance, time horizon, confidence, and the objects it applies to.

The standard does not prescribe how an insight was produced. It prescribes how the durable result can be attached to the building in a portable and interpretable way.

7.3  Vendor innovation

Vendors retain the freedom to differentiate through algorithms, artificial intelligence, optimization methods, control strategies, software architecture, workflows, service models, rendering, and user experience.

The method by which a vendor learns something may remain proprietary. When that method produces durable knowledge about the owner’s building, the resulting knowledge must be representable in the portable layer with appropriate provenance and attribution.

8  Portable Representation and Freedom of Experience

Owners frequently pay significant sums to create floor plans, equipment graphics, schematic layouts, point bindings, and navigation structures. Those assets describe the building and embody real engineering labor. They should not become unusable simply because the owner changes platforms.

The standard therefore protects portability of representation while preserving freedom of experience. It defines a neutral structure for geometry, components, hierarchy, semantic bindings, labels, references, and basic display intent. Each vendor remains free to render, style, animate, navigate, and interact with those representations in its own way.

A compliant importer is not required to recreate an identical visual experience. It is required to preserve the underlying representation, meaning, geometry, hierarchy, and bindings, so that the receiving platform can render them without rebuilding the owner’s work from scratch.

9  The Reconstruction Guarantee

The defining promise of this standard is not data export. It is reconstruction of understanding.

A compliant exchange package must carry enough information for a receiving compliant system to rebuild the portable understanding of the building without undocumented dependencies on the exporting vendor.

Import and export symmetry

A system cannot claim full compliance if it exports less understanding than it requires to operate, or if it imports only a lossy subset of a compliant package.

At a minimum, compliant round-trip exchange must preserve:

Stable identity — Objects retain durable identifiers, or explicit and lossless identity mappings.

Object meaning — Classification, semantics, units, constraints, and status remain interpretable.

Relationships — The graph connecting spaces, systems, assets, points, intent, knowledge, and resources is preserved.

Operational intent — The receiving system can distinguish what should happen from what is happening and what happened historically.

Knowledge and rationale — Human understanding and the reasons behind decisions remain linked to the relevant objects.

Representation assets — Floor plans, graphics, bindings, and navigation structures can be ingested and re-rendered.

Provenance — Authorship, source, version, confidence, approvals, and change history remain visible.

Linked resources — Documents and heavy assets are included, or referenced through durable, integrity-checked resources.

Extensions — Unknown extensions are preserved rather than corrupted or silently discarded.

10  What This Standard Is Not

Not a product — The standard must be able to exist independently of Flux Core OS or any other implementation.

Not a replacement for field protocols — It complements BACnet, Modbus, OPC UA, MQTT, and other transport or control protocols by defining the durable understanding above them.

Not a mandate to open proprietary algorithms — Vendors may protect their methods, models, and optimization engines.

Not a requirement for identical user experiences — Rendering, interaction, navigation, and workflow design remain areas of competition.

Not a lowest-common-denominator data dump — Compliance requires preservation of semantics, relationships, intent, knowledge, representation, and provenance.

Not static — The standard evolves through versioning and governed extension while protecting backward interpretability.

11  Practical Success Tests

Every major design decision should be evaluated against the real transitions that building owners face.

TEST 1

A vendor disappears. Can another compliant implementation reconstruct the building’s understanding from the owner’s package?

TEST 2

An owner changes platforms. Can the owner migrate without rebuilding relationships, intent, graphics, and knowledge?

TEST 3

A chief engineer retires. Does the building retain the rationale, lessons, exceptions, and field knowledge that previously lived in one person’s head?

TEST 4

A major upgrade occurs. Can the building preserve its identity and history while individual systems and assets are replaced?

TEST 5

A graphic is re-rendered. Can a receiving platform ingest the floor plan or equipment schematic and reuse its geometry and bindings in a new visual language?

TEST 6

Thirty years pass. Can the building still be understood after every current vendor and product has changed?

12  Governance Commitments

Trust in the standard requires more than published schemas. It requires governance that prevents any single implementation or commercial interest from quietly redefining portability.

Neutral stewardship — Governance includes owners, integrators, operators, engineers, vendors, developers, and other relevant stakeholders.

Public evolution — Proposals, issues, decisions, compatibility implications, and version changes are visible and documented.

Stable versioning — Core semantics follow explicit compatibility rules, deprecation periods, and migration guidance.

Reference tooling — Open-source validators, encoders, decoders, examples, and test fixtures reduce implementation cost and inconsistent interpretation.

Conformance profiles — Compliance levels are defined clearly, so that partial implementations cannot imply capabilities they do not provide.

Round-trip testing — Certification tests export, import, preservation, and reconstruction, not merely schema validation.

Owner-accessible certification — Owners can understand what a product exports, imports, preserves, and reconstructs before purchase.

13  Closing Declaration

The Building Understanding Standard exists to make the operational understanding of a building a permanent, owner-controlled asset: portable, durable, transparent, extensible, and independent of any single vendor, platform, or person.

It creates a foundation on which vendors can innovate aggressively while owners retain continuity. It replaces captivity with beneficial partnership, and turns switching from reconstruction into migration.

Buildings do not forget. Systems do.

The purpose of this standard is to ensure that the understanding remains with the building.

END OF CHARTER · VERSION 0.1 · DISCUSSION DRAFT