BUSBuilding Understanding Standard
Standard / Specification

BUS-1 v0.3

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

Start reading PDF (1.3 MB) Schemas & tests

Status of this document

This is version 0.3 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.3 closes four of the gaps its predecessor recorded against itself in Annex F.1, each of them measured against the two mature semantic models in this field rather than against opinion. Ports are declared by the asset that has them, so a package can now say which side of a valve, which branch, and that a coil has a supply and a return (9.4). A network is an entity and a protocol is a registered token, so the fact that two devices share a trunk is asserted once about the pair rather than repeated as a string on every point (8.10). bus-vector-1 is specified as a closed profile of SVG, which makes figure mode implementable and gives the security requirement of 19.3 a format to attach itself to (13.4.3). And a sequence can state whether it is design intent or what a controller is actually running (10.5) — the narrow and honest part of a gap whose wide part, extraction of deployed control logic, remains open and has no precedent in any standard.

What this version declines is recorded with its reasons rather than passed over: no point-function taxonomy, no equipment classes for network hardware, no prototype templates, no control language, and no growth of the symbol role vocabulary until an implementer reports hitting its ceiling. A reviewer can argue with a decision. An omission gives them nothing to argue with. Annex F holds the declines; the companion Decision Record holds the reasoning behind every design decision, including the alternatives rejected.

New in this version are crosswalks in both directions. Annex G maps inward, from Project Haystack 4.0.0 and Brick Schema 1.4.4: it fixes the rules by which a foreign vocabulary reaches the classifications field, so that two implementers exporting the same source model produce the same package. Annex H maps outward, to object stores and property graphs: it fixes the four decisions a consuming ontology platform would otherwise make differently from the next one — link realization, denormalization, open vocabularies in closed stores, and where quality and provenance land. Neither maps a taxonomy onto anything; this document has none by design.

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.

New in this version, from external review: a PROVISIONAL clause SHOULD end with a one-sentence promotion criterion — the concrete evidence that would move its label to AGREED. The label without the criterion invites opinion; the criterion turns it into a request for a specific experiment, and reports against those criteria are the most useful form of feedback this draft can receive.

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 1Scoperead →Clause 2Conformanceread →Clause 3Normative referencesread →Clause 4Terms and definitionsread →Clause 5Architecture and design rulesread →Clause 6Identity and addressingread →Clause 7Datatypes, properties, and semanticsread →Clause 8The information modelread →Clause 9Relationshipsread →Clause 10Operational intentread →Clause 11Alarmsread →Clause 12Eventsread →Clause 13Portable presentationread →Clause 14Provenance and governanceread →Clause 15Extensionsread →Clause 16The exchange packageread →Clause 17The JSON bindingread →Clause 18Versioning and compatibilityread →Clause 19Security, privacy, and integrityread →Clause 20Relationship to existing workread →Annex AConformance test suite outlineread →Annex BSymbol role vocabulary, tier oneread →Annex CUnit codesread →Annex DWorked exampleread →Annex ESchema filesread →Annex GMapping to Project Haystack and Brickread →Annex HMapping to object stores and property graphsread →