Decision record

THE BUILDING UNDERSTANDING STANDARD

Decision

Record

Choices made in the design of BUS-1, the alternatives rejected, and why

Companion to BUS-1 v0.2 · July 2026

A specification records what was decided. It rarely records what was considered and put aside, which is the part that gets relitigated.

WHY THIS DOCUMENT EXISTS

WORKING DOCUMENT — DECISIONS REMAIN OPEN TO CHALLENGE

How to read this

Each entry records one decision in three parts: what was chosen, what was rejected, and the reasoning. The rejected alternative is the important half. Three years from now the question will not be what the specification says — that is written down — but why it is not the other way, and that answer is usually lost.

Entries carry a maturity label, following the convention of the earlier technical specification:

• AGREED — settled in working session and stable enough to build against. Reversing it would invalidate work.
• PROVISIONAL — decided, but on thin evidence. Expected to be challenged by the first real implementation.
• OPEN — named here because the decision is pending and its absence is load-bearing.

Where a decision resolves a disagreement between the two v0.1 drafts, the entry says which draft the resolution came from. Both drafts were right about different things and the record should say so.

Contents

• AFoundational rules
• BThe entity catalog
• CRelationships
• DOperational intent
• EProperties and semantics
• FPortable presentation
• GPackage, encoding, and security
• HStill open

A Foundational rules§

A-1 Objects own intrinsic properties only AGREED

Decided. An object carries only facts intrinsic to itself. Location, membership, service, control, measurement, and every other contextual fact is expressed as a typed relationship. Stated as a normative design rule rather than left implicit in the schema.

Rejected. Allowing convenience properties such as parentSpace or servesZone on the object, alongside the relationship graph.

Because. It is the only generative principle in the model. For any candidate field it answers object-or-graph without further argument, and it catches the mistake every building schema makes — treating location as a property. The cost is verbosity; the benefit is that there is exactly one place any given fact lives, so the two cannot diverge. Taken from the earlier technical specification, which stated it and which the parallel draft only implied.

A-2 Relationships are first-class entities AGREED

Decided. A relationship has its own identifier, type, endpoints, qualifiers, validity period, provenance, and extensions.

Rejected. Relationships as properties or pointer arrays inside objects.

Because. Three capabilities depend on it: recording who asserted a connection and on what evidence; ending a relationship without deleting either endpoint; and allowing an extension to say something about the connection itself. In the worked example, relationships are roughly a third of package size. That cost is real and was accepted knowingly.

A-3 The model is normative; encodings are representations AGREED

Decided. The information model is the standard. JSON is the first binding. Additional bindings may be added without touching the model.

Rejected. Specifying JSON directly as the standard, with no abstract layer.

Because. Buildings outlive serialization formats. An implementation that encodes the JSON binding into its internal design rather than the model will find the second binding expensive, and implementers are warned of this explicitly.

A-4 Omission is permitted; silent omission is not AGREED

Decided. A package manifest must declare, for every substrate domain, whether it is carried in full, in part, or not at all, with a reason code from a fixed list.

Rejected. Requiring completeness, or leaving completeness to be inferred from the content.

Because. No exporter can carry everything, so a completeness requirement would be widely ignored and quietly violated. Mandatory declaration converts an unbounded quality problem into a bounded disclosure problem, and puts the discomfort where it belongs: an exporter that cannot carry intent must say so, in a fixed code, in a file the owner reads.

A-5 Maturity labels on every section AGREED

Decided. Sections carry AGREED, PROVISIONAL, or OPEN.

Rejected. Asserting uniform normativity across the whole document.

Because. A working draft that asserts uniform normativity overclaims, and it makes review harder because a reviewer cannot tell where an opinion is actually wanted. Taken from the earlier technical specification.

A-6 Preservation over comprehension AGREED

Decided. An importer must preserve what it does not understand, unconditionally, and re-emit it. Understanding is optional; retention is not.

Rejected. Permitting an importer to discard unrecognized constructs in order to produce a clean internal model.

Because. This is the rule that stops the extension mechanism from becoming a lock-in mechanism, and it is the one most likely to be violated by an implementation that otherwise passes every test — because discarding the unfamiliar is what a well-engineered importer normally does.

B The entity catalog§

B-1 Space is recursive; Building and Zone are separate AGREED

Decided. One Space class with a spaceKind covering site, storey, room, area, shaft, and plant room, nesting through contains. Building remains its own class. Zone remains its own class.

Rejected. Five separate classes for Site, Building, Storey, Space, and Zone. Also rejected: a single Space class absorbing all five.

Because. Site, storey, and room differ in attributes, not in kind, so separate classes were over-splitting. Building stays separate because it is the unit of ownership and transfer and the manifest subject points at it. Zone stays separate because a zone is a set of spaces, not a region — it has no boundary, and modeling it as a space makes containment lie.

B-2 A single Asset class with a kind AGREED

Decided. Asset with an assetKind of equipment, component, device, or virtual.

Rejected. Four sibling classes, as in the parallel draft.

Because. The distinctions are real but they are role distinctions, and role is better carried as a discriminator than as a class. Taken from the earlier technical specification. Note that modeling a packaged unit as two entities — one that conditions air, one that hosts points — remains recommended, because the controller will be replaced several times during the life of the unit and history should follow the right one.

B-3 Party is an entity AGREED

Decided. A Party entity with a kind of person or organization, and a role in the building.

Rejected. Naming creators and approvers only inside provenance blocks, with no addressable party object.

Because. For a standard whose purpose is owner rights, the owner must be addressable. Without it a package cannot state whose asset it is, and a lease, service contract, or responsibility assignment has nothing to attach to. Absent from the earlier technical specification and carried over from the parallel draft.

B-4 Alarm Definition is a core entity AGREED

Decided. AlarmDefinition carrying condition, limits, delays, deadband, priority, routing, escalation, and acknowledgment policy.

Rejected. Representing alarms as a pointKind plus a boolean flag on enumeration members.

Because. Alarm configuration is operational intent by any honest reading, and the flag-based treatment carried almost none of it. This was the clearest omission in the parallel draft and the earlier technical specification had it right.

B-5 Event is a core entity, separate from time series AGREED

Decided. Event for a timestamped occurrence: an alarm instance, a mode change, an override, a manual command, a service action.

Rejected. Folding events into the deferred operational-history domain along with trend data.

Because. An event is categorically not a time-series sample. Deferring both together means the core cannot express "someone overrode this in 2019 and never removed it" — which is precisely the class of fact that disappears in migration and that no drawing records. Taken from the earlier technical specification.

B-6 Abstract supertypes with graceful degradation PROVISIONAL

Decided. A shallow abstract spine — Entity, PhysicalEntity, Asset — so a receiver that does not recognize a leaf class can still place it correctly.

Rejected. A flat closed set of concrete classes with no fallback.

Because. Without a fallback, an importer meeting an unknown class can only preserve it as opaque. The same reasoning produced the hierarchical symbol roles in F-5, and the two should behave alike: unknown leaf, known ancestor, correct handling.

B-7 Property definitions are entities AGREED

Decided. PropertyDefinition declaring name, datatype, unit, meaning in prose, optional enumeration, and optional external classification. Required for every property an exporter emits.

Rejected. A free-form property map, as in both v0.1 drafts.

Because. A free map interacts badly with the completeness declaration, which is the honesty mechanism the standard leans on. An exporter could place most of what it knows in bare key-value pairs, declare the domain complete, and pass every test — technically true, materially false. Requiring definitions costs the vendor a fixed one-time effort per product regardless of package size, which puts the cost on the vendor once rather than on the owner every time. See E-1 for what else this resolves.

B-8 Type and instance are separated PROVISIONAL

Decided. An AssetType entity carrying manufacturer, model, ratings, and specification, referenced by instances.

Rejected. Repeating manufacturer, model, and capacity on every instance.

Because. Four hundred identical terminal units currently carry four hundred copies of the same product facts. Beyond size, it makes "every actuator was replaced with model X" a single assertion rather than four hundred edits. The cost is an indirection every reader must resolve, and this is the change most likely to irritate implementers, hence PROVISIONAL.

C Relationships§

C-1 Commands is separate from controls AGREED

Decided. commands / commandedBy for a point acting on a thing; controls / controlledBy for a controller, sequence, or strategy governing a process.

Rejected. A single controls predicate covering both.

Because. A point commands. A controller governs. Collapsing them loses the distinction between the mechanism and the authority, and it is the distinction an engineer needs when tracing why something moved. Taken from the earlier technical specification.

C-2 Directed feeds alongside undirected connectedTo AGREED

Decided. feeds / fedBy requires a medium and is directional. connectedTo is symmetric and qualified by medium and port.

Rejected. A single connectedTo qualified by medium, or a single directed feeds.

Because. A duct has a direction and a pipe joint does not. One predicate cannot carry both without one of the two lying. Each draft had half of this.

C-3 Electrical topology is modeled AGREED

Decided. powers / poweredBy added to the core vocabulary.

Rejected. Leaving electrical supply to be expressed through generic connection.

Because. Electrical dependency is what an operator traces during an outage and what an analyst needs for consumption attribution. Absent from the parallel draft entirely. Taken from the earlier technical specification.

C-4 Implementation is distinguished from intent AGREED

Decided. implements / implementedBy connects a Sequence or Schedule to the Intent it realizes.

Rejected. Attaching sequences to intent with the generic appliesTo.

Because. Sequences are implementation, not intent, and the relationship between them is directional and specific. This is what allowed Sequence to be pulled out of the intent object entirely (D-2).

C-5 Knowledge predicates are specific PROVISIONAL

Decided. explains, supports, and justifies alongside the generic appliesTo.

Rejected. Attaching all knowledge with appliesTo.

Because. A note that explains why a setpoint is what it is differs from one that provides evidence for it and from one that justifies a decision. Taken from the earlier technical specification. PROVISIONAL because it is unclear whether the distinction survives real authoring or whether authors will use whichever appears first in a menu.

C-6 Composition is distinct from membership AGREED

Decided. hasPart / partOf for composition; hasMember / memberOf for grouping.

Rejected. A single membership predicate.

Because. A filter bank inside an air handling unit is a part; the unit inside an air system is a member. Conflating them breaks maintenance history, because a part is replaced and a member is reassigned. Absent from the earlier technical specification.

C-7 Replacement never deletes AGREED

Decided. replaces / replacedBy, with both endpoints retained and the superseded entity marked decommissioned.

Rejected. Deleting the superseded entity and recreating its successor.

Because. Deletion severs every history record, provenance chain, and event that pointed at the old entity. Lifecycle transition is the mechanism by which a building keeps its identity across thirty years of component turnover, and it only works if nothing is ever removed to record that it was replaced.

D Operational intent§

D-1 Intent is decomposed, not a single object AGREED

Decided. Separate addressable Objective, Target, Constraint, and Schedule entities.

Rejected. A single Operational Intent object with sections for objectives, targets, constraints, and scope, as in the earlier technical specification.

Because. The composite object is easier to author and harder to reference. The statement most needed twenty years later is that one specific target was relaxed on a date by a person for a reason; if targets live inside a composite, changing one revises the whole and the audit trail blurs. Authoring convenience is a tooling problem; addressability is not.

D-2 Sequence sits outside intent AGREED

Decided. Sequence is its own entity connected to intent by implements.

Rejected. Sequence as a subsection of the intent object.

Because. A sequence is implementation. Placing it inside intent invites the conflation the separation exists to prevent, and it prevents one sequence from implementing several intents. Resolved in favor of the parallel draft only after C-4 gave it a proper connector.

D-3 Constraint stays separate from Target AGREED

Decided. Constraint is its own class with a constraintKind including safety, regulatory, and interlock.

Rejected. Folding constraints into targets as a target with a different enforcement flag.

Because. Missing a target is a comfort complaint. Violating a constraint is a hazard. Any structure that lets a receiving system treat the two alike is a structure that will eventually hurt someone. This one is not open to efficiency arguments.

D-4 Unenforceable constraints are reported, not assumed satisfied AGREED

Decided. An importer that cannot evaluate a constraint expression must report it as unenforced and preserve it.

Rejected. Permitting the importer to drop or silently accept constraints it cannot evaluate.

Because. A safety limit that survives migration as an uninterpreted note is recoverable. One that survives as an assumption is not.

E Properties and semantics§

E-1 Quantity kind resolves through property definitions AGREED

Decided. A point’s quantityKind is a reference to a PropertyDefinition rather than a free token or an external vocabulary term.

Rejected. Defining a controlled quantity-kind vocabulary, or adopting an external one such as QUDT.

Because. Point semantics and asset properties are the same problem and now use one mechanism instead of two. Defining a vocabulary reintroduces the committee dependency the standard is trying to avoid, and adopting an external one binds a thirty-year guarantee to another body’s release schedule. This was an open issue in the parallel draft and B-7 closed it as a side effect.

E-2 No equipment taxonomy is defined AGREED

Decided. A small structural class set, with external classifications preserved verbatim including their source vocabulary and version.

Rejected. Defining a BUS equipment type hierarchy, or adopting Brick, Haystack, or ASHRAE 223 as the normative taxonomy.

Because. Equipment taxonomy is the most contested and fastest-moving layer of this field; binding a thirty-year continuity guarantee to it would be a mistake. Note that 223P remains an unpublished project committee draft and Haystack 5 is announced but unreleased, so there is at present no stable target to adopt even if adoption were desirable.

E-3 Taxonomy grows bottom-up through promotion PROVISIONAL

Decided. Property definitions that many independent vendors emit identically become candidates for promotion into the core, through the mechanism already defined for extensions.

Rejected. Leaving E-2 as a permanent refusal with no path to shared vocabulary.

Because. A refusal without a growth path is a gap. Promotion gives the vocabulary a route that runs on evidence of shared meaning rather than on committee negotiation, and it means the standard never has to guess in advance.

E-6 A BUS unit code vocabulary, not an external registry AGREED

Decided. Annex C defines approximately eighty unit codes covering the units used to operate buildings, written as an engineer writes them: degF, cfm, gpm, inH2O, kWh, tonRef. A unitSystem field names an external vocabulary for anything the annex does not cover, and an informative mapping is published alongside.

Rejected. Adopting the Unified Code for Units of Measure as the normative vocabulary, as v0.1 did.

Because. Two reasons, one of taste and one of substance. The registry is a clinical informatics standard, and its presence throughout a building specification signals that the authors came from another industry — its US-customary forms are the ones a controls engineer would meet most and read worst: inches of water column is [in_i'H2O], cubic feet per minute is [cft_i]/min, Fahrenheit is [degF]. The substantive reason is coverage: the ton of refrigeration, in daily use across the industry, has no code in that registry at all, and neither does kilovolt-ampere reactive. A vocabulary that cannot express a unit every chiller in the country is rated in is not a vocabulary this standard can adopt.

E-7 The unit field is named unitCode AGREED

Decided. The field carrying the code is unitCode throughout, including on drawing coordinate systems, where v0.2 had briefly used the plural units.

Rejected. The bare name unit.

Because. "unit": "degF" reads like free text and invites an implementer to write deg F or Fahrenheit. Naming it a code signals that a vocabulary governs it. Fixing the singular and plural inconsistency at the same time removes a second trap.

E-4 Units are never converted on import AGREED

Decided. An importer must retain the original magnitude and unit and re-export them unchanged, whatever it does internally.

Rejected. Permitting normalization to a canonical unit system on import.

Because. Round-tripped conversion is a silent and compounding form of loss. It also destroys the ability to tell what was actually measured from what was computed.

E-5 Telemetry bindings are preserved verbatim AGREED

Decided. Protocol, address, network, and acquisition parameters are opaque to the standard and re-emitted byte-identical.

Rejected. Normalizing addresses into a canonical form where the protocol is recognized.

Because. This is the least glamorous part of the model and among the most valuable. A migration that preserves every semantic relationship but loses the addresses obliges an integrator to rediscover and rebind tens of thousands of points by hand, which is most of the real cost of switching.

F Portable presentation§

This group departs furthest from the parallel v0.1 draft, which deferred presentation entirely. The evidence that changed the decision is recorded in F-1.

F-1 Presentation is core, not deferred AGREED

Decided. The element and binding model enters the core specification now. Full presentation geometry becomes Part 2, developed in parallel rather than sequenced after.

Rejected. Deferring the whole domain to a later part on the grounds that no standard has ever done it.

Because. Three findings settled this. Schneider’s own documentation states that TGML artwork travels but the binding and linking information is lost, because bindings live in the database rather than the file. The vendor’s own N1-to-Metasys conversion utility drops color-change, animation, and sizing dynamics and requires manual rebinding. And the dominant third-party graphics house organizes its service line by platform with no conversion service between them — its business model is the missing format. The rebuild cost is structural and it is collected on every migration.

F-2 A graphic has four layers, and the ownership line falls between the third and fourth AGREED

Decided. Geometry and structure, semantic element identity, and bindings are owner assets and travel. Appearance — artwork, color, animation, interaction, typography, responsive behavior — is vendor and does not.

Rejected. Treating a graphic as a single indivisible artifact, which forces a choice between taking everything from the vendor and giving the owner nothing.

Because. The reason this has never been standardized is that everyone treats a graphic as one thing. It is four. Stated as a test: the vendor keeps everything a user sees and feels; the owner keeps everything a draftsman or engineer decided.

F-3 Elements reference a symbol role; the receiver supplies the artwork AGREED

Decided. A package states that at a location, rotated, on a layer, there is an element of a declared symbol role bound to given targets. The receiving system draws it in its own symbol library.

Rejected. Exchanging the artwork itself as the primary mechanism.

Because. This is what preserves the owner’s survey, placement, and bindings in full while leaving the vendor’s design system entirely untouched. It is not speculative: IEC 61970-453 exchanges power-system diagram layout with links to modeled objects and explicitly leaves the symbol library to the receiver, and it is in production.

F-4 Elements have a figure mode for bespoke artwork AGREED

Decided. An element may carry an embedded neutral vector payload that a receiver must render substantially as given, either instead of or alongside a role.

Rejected. Role-and-library as the only mechanism.

Because. Sometimes the owner paid for the artwork itself — a bespoke plant schematic, a one-line an engineer drew, a symbol no vocabulary contains. Role mode alone would strand exactly the drawings with the highest engineering content.

F-5 Symbol roles are hierarchical with fallback AGREED

Decided. Dotted paths that degrade: fan.centrifugal.supply to fan.centrifugal to fan. First tier approximately forty roles.

Rejected. A flat enumerated symbol list.

Because. A receiver that does not know the leaf still knows to draw a fan. This lets the vocabulary grow indefinitely without breaking deployed importers, which is the same property abstract supertypes give the entity model (B-6). Forty is small enough to ratify and large enough to be useful; the failure mode to avoid is a three-hundred-role taxonomy project that never ships.

F-6 A floor plan carries real geometry, not a document reference AGREED

Decided. Declared coordinate system with georeference where available; space boundaries as polygons carrying the Space entity identifier; architectural context as a declared layer; equipment placement tied to Asset identifiers; layers with declared purpose; scale with at least one reference dimension.

Rejected. Carrying the plan as an opaque drawing file with bindings layered on top.

Because. Space boundaries carrying entity identifiers are what turn a plan from a picture into a view of the model, and every downstream capability depends on it. Georeferencing matters more than it appears: an anchored plan survives into any CAD, BIM, or GIS tool indefinitely, and two plans from different vendors will register against each other.

F-7 Presentation scope is 2D with bindings AGREED

Decided. Two-dimensional presentation geometry with semantic bindings. Three-dimensional models are referenced as resources.

Rejected. Extending presentation to cover 3D geometry and building information modeling.

Because. Without this line held, the work becomes IFC with extra steps and dies of scope. IFC already exists, is an ISO standard, and is better at 3D than anything this project would produce.

F-8 Binding is an entity, naming both endpoints intrinsically AGREED

Decided. Binding carries element, target, channel, direction, mapping, quality behavior, and a write block. No separate bindsTo relationship is created.

Rejected. Modeling bindings as relationships with rich qualifiers, consistent with A-2.

Because. A binding carries a value-mapping table — states to selectors, ranges to color stops, command priority — which is more structure than qualifiers should hold. Naming endpoints intrinsically, exactly as Relationship does, avoids generating eight thousand relationship objects for a plan with four thousand bindings. Making it an entity also gives bindings provenance and revision, so the fact that an element was repointed in 2019 becomes visible; bindings drift constantly and at present nobody can prove it.

F-9 Quality behavior travels AGREED

Decided. What an element does when its value is stale, out of service, or unreachable is part of the binding.

Rejected. Treating stale-value behavior as rendering, and therefore vendor territory.

Because. It is engineered behavior, not styling, and it is invariably lost in rebuilds. A graphic that shows the last good value indefinitely instead of graying out is a safety issue, not an aesthetic one.

F-10 Command actions travel AGREED

Decided. A binding may be a write. The target point, the command priority, and the requirement for confirmation are all carried.

Rejected. Carrying only read bindings, on the grounds that actuation is too sensitive to place in a portable package.

Because. The ability to act on the plant from a graphic is engineered owner-funded behavior and meets the boundary test. Excluding it would mean every migration rebuilds the command layer by hand, which is the most safety-critical part to rebuild. The consequence is a materially sharper security posture, recorded in G-4.

F-11 Command priority is preserved verbatim and never substituted AGREED

Decided. A receiving system that cannot honor the source priority model must report it rather than substitute its own.

Rejected. Allowing the receiver to map priorities onto its own scheme silently.

Because. If a source binding writes at priority 8 and the receiver writes at 16, the graphic looks identical and the plant behaves differently. Nobody discovers it until an override fails to hold. This is the presentation-layer analog of E-4.

F-12 Write limits reference a Constraint rather than duplicating one AGREED

Decided. A write binding that restricts the permitted value range points at a Constraint entity.

Rejected. Carrying minimum and maximum on the binding itself.

Because. Two places to state the same limit guarantees they diverge, and the graphic is the copy that will be edited without the model being updated. It also ties presentation back into the intent model, which is a good structural sign for both.

F-13 Confirmation and interlock requirements travel AGREED

Decided. That a write requires confirmation, or is interlocked against another condition, is carried. The design of the dialog is not.

Rejected. Treating confirmation prompts as interaction design.

Because. These are operator-safety engineering decisions. The same boundary test that gives the vendor the dialog gives the owner the requirement.

G Package, encoding, and security§

G-1 Canonical JSON is the conformance target; dictionaries are optional PROVISIONAL

Decided. JSON remains the binding against which conformance is measured. Dictionary coding is an optional package area that a conforming importer must be able to expand.

Rejected. Making a compact dictionary-coded form the primary representation, or omitting dictionaries entirely.

Because. The model must never become hostage to a compression scheme. But verbose JSON will not survive a portfolio-scale export, and the volume driver turns out to be bindings rather than points — thousands of near-identical records differing only in target identifier, which is the ideal case for dictionary coding.

G-2 Binary encoding is deferred but evaluated against graphics-heavy packages OPEN

Decided. No compact wire format is selected. When one is evaluated, the benchmark is a package with a full graphics set, not a model-only export.

Rejected. Selecting Protobuf now, or ruling out a binary encoding.

Because. One technical point favors Protobuf specifically and is worth recording: it preserves unknown fields by design, which is exactly the behavior A-6 demands and which most binary formats get wrong. That is an argument for evaluation, not a decision.

G-3 The envelope carries versioning but not references AGREED

Decided. Object revision, schema version, effective time, and deprecation are envelope fields. Links to documents and resources are relationships.

Rejected. An envelope References field group, as in the earlier technical specification.

Because. Versioning was taken from that draft and improves on burying version inside provenance — revision is needed for synchronization and merge, not only for history. References were rejected because they violate A-1 and duplicate documentedBy.

G-4 Actuation is declared at the package level AGREED

Decided. A manifest states whether command bindings are present. Command bindings are separately excludable with their own reason code. Signing moves from OPTIONAL to SHOULD.

Rejected. Treating a package with command bindings the same as any other.

Because. Following F-10, a package carries addresses, semantics, setpoints, safety limits, the occupancy schedule, and the actuation map with priorities. That is a complete operational control kit, and a recipient should know before opening the file.

G-5 Personal data is withheld visibly or not at all AGREED

Decided. An exporter must be able to withhold personal data and must declare the withholding with a reason code.

Rejected. Permitting silent redaction.

Because. A redaction that is not declared is indistinguishable to a receiver from an assertion that was never made. This creates real tension with provenance, which is most valuable when it names a person; the standard resolves it by making the withholding visible rather than by preferring either side.

H Still open§

These are named because their absence is load-bearing. A reader who assumes they were considered and settled would be wrong.

H-1 Ports and connection points OPEN

Decided. Nothing yet. connectedTo accepts a port qualifier, which is a placeholder rather than a model.

Rejected. Adopting a Connectable and ConnectionPoint model of the kind ASHRAE 223P uses.

Because. Without ports it is not possible to say which branch, which side of a valve, or that a coil has a supply and a return. This is the largest remaining expressiveness gap and also the change most likely to turn a clean specification into an ontology. It should be decided against a real hydronic plant, not in the abstract.

H-2 Networks and drivers OPEN

Decided. Nothing. binding.network remains a free string.

Rejected. A Network entity with devices hosted on it, carrying gateway and driver configuration.

Because. Integration and driver configuration appears in this project’s own survey as a component that no existing standard carries — and the specification does not yet carry it either. A package can say a point is at an address on a named network and nothing about how that network is reached.

H-3 Extraction of deployed control logic OPEN

Decided. Sequences are referenced, not extracted.

Rejected. Specifying extraction of logic from a running system.

Because. ASHRAE 231-2026 gives a machine-readable control description language, but it is design-time: it describes what logic should be, not what a deployed controller is running. Extraction has no precedent in any standard and is the largest gap between this specification and the charter’s reconstruction promise.

H-4 Tenancy and lease OPEN

Decided. Nothing. A comfort obligation arising from a lease is expressible only as prose in an Objective.

Rejected. A Tenancy entity linking a Party to spaces over a period.

Because. The obligation and the evidence for it are separable, and at present the evidence is not modeled. Whether this belongs in a building-operations standard at all is a genuine scope question.

H-5 Analytic rule portability OPEN

Decided. The extension interface can attach a result. It cannot carry the rule that produced it.

Rejected. Specifying a portable rule form.

Because. The boundary between a portable rule and a proprietary method is genuinely unclear, and getting it wrong in either direction damages the standard — too far and vendors will not implement, not far enough and analytics remain captive.

H-6 Signature formats OPEN

Decided. The manifest admits signatures and constrains nothing about them.

Rejected. Specifying a signature profile.

Because. Following G-4 this matters more than it did. It should be settled before any package is relied on as evidence in a commercial dispute.

Take my building with me.

Not a data dump. Not a proprietary backup. A portable, durable, reconstructable understanding of the building the owner already paid to create.

END OF DECISION RECORD · JULY 2026