BUSBuilding Understanding Standard
Standard / Specification

BUS-1 v0.2

Core information model, portable presentation, and exchange package. Twenty clauses and five annexes, browsable here and downloadable whole.

Start reading PDF (1.0 MB) Schemas & tests

Status of this document

This is version 0.2 of BUS-1, the first part of the Building Understanding Standard. It is a working draft published for implementer review. It has not been ratified by any standards body, and no governance body has yet been constituted to hold it.

Version 0.2 consolidates two independently drafted v0.1 specifications and the working sessions that reconciled them. The substantive change from v0.1 is that portable presentation is now part of the core rather than deferred, together with alarm definitions, events, a party model, and a requirement that every property carry a definition. Every design decision, including the alternatives rejected, is recorded in the companion Decision Record.

A reference implementation accompanies this draft and passes the Annex A suite in self-round-trip. Building it fed three clarifications back into this text — the newer-MINOR schema leniency noted in 18.2, the permitted envelope differences of 17.5, and the typed-model warning of 17.4 — which is the direction of travel a working draft should have.

Schema identifiers, namespace URIs, and the media type used in this draft are provisional. They resolve to a placeholder authority and will be reassigned when a governance body exists. Implementations SHOULD treat them as opaque strings and MUST NOT hard-code retrieval from them.

Reading the maturity labels

Every clause carries a maturity label. A draft that asserts uniform normativity across eighty pages overclaims, and it makes review harder because a reviewer cannot tell where an opinion is wanted.

  • AGREED — settled in working session and stable enough to build against. Reversing it would invalidate work already done.
  • PROVISIONAL — decided, but on thin evidence. Expected to be challenged by the first real implementation, and the place review effort is most valuable.
  • OPEN — named because the decision is pending and its absence is load-bearing. A reader who assumes it was considered and settled would be wrong.

Editorial conventions

This document and its companions use US English throughout, in prose and in identifiers. Contributors should not introduce British forms; a specification that spells the same word two ways invites the reader to wonder what else is inconsistent.

Two deliberate exceptions are retained as terms of art, and both appear in schema identifiers as well as prose:

  • storey — kept rather than story, following IfcBuildingStorey in ISO 16739-1, and because story is ambiguous in a document that also discusses narrative records. Appears as a spaceKind value and in storeysAboveGround.
  • .buspkg, bus: and all schema field names — lowerCamelCase and case-sensitive. These are identifiers, not words, and are never re-spelled to match prose conventions.

Requirement keywords are printed in a distinguishing color as a review aid; color carries no meaning and capitalization does. Inline code, schema field names, and enumeration values are set in a monospaced face.

Relationship to the Founding Charter

The Founding Charter states the commitments. This document specifies how they are met. Where the two disagree, the charter states the intent and this document is at fault.

Four charter commitments carry directly into normative requirements here, and are the ones most likely to be quietly broken by an implementation that otherwise validates:

  • The reconstruction guarantee — a compliant package must be sufficient on its own — 2.4.
  • Import and export symmetry — a system may not export less than it needs to operate — 2.4 and test EX-4.
  • No lowest-common-denominator dump — omission is permitted, silent omission is not — 16.6.
  • Portability of representation — geometry, semantic element identity, and bindings are owner assets and travel; appearance does not — clause 13.

Contents

Contents
Clause 1Scope and purposeread →Clause 2Conformance and the reconstruction guaranteeread →Clause 3Terms and definitionsread →Clause 4Conventions and datatypesread →Clause 5Architecture of the modelread →Clause 6The entity enveloperead →Clause 7Identity and classificationread →Clause 8Places, systems, and assetsread →Clause 9Pointsread →Clause 10Intentread →Clause 11Alarms and eventsread →Clause 12Knowledge, resources, and provenanceread →Clause 13Portable presentationread →Clause 14Relationshipsread →Clause 15Extension and preservationread →Clause 16The exchange packageread →Clause 17Canonical form and comparisonread →Clause 18Versioningread →Clause 19Security and safety considerationsread →Clause 20Referencesread →Annex AConformance test suiteread →Annex BSymbol role vocabularyread →Annex CUnit code vocabularyread →Annex DWorked exampleread →Annex ESchema files and open issuesread →