E Schema files§

Informative. The schema files themselves are normative for the JSON binding, per 17.4.

All four schema documents use the [JSONSCHEMA] 2020-12 dialect and resolve cross-references by $id. A validator MUST be configured with all four as a resource registry; they are not self-contained individually.

NOTE The $id values resolve to a placeholder authority and will be reassigned when a governance body exists. Implementations MUST treat them as opaque and MUST NOT fetch them at validation time.

F Open issues and decisions taken§

Informative. Recorded so review can be directed where it is wanted. The companion Decision Record gives the reasoning behind each.

F.1 Known gaps§

Four gaps recorded here against v0.2 are closed, in whole or in part, by this version: ports (9.4), networks (8.10), the neutral vector format (13.4.3), and the design-versus-deployed distinction that was the narrow part of control-logic extraction (10.5). A fifth closes outside this document: time-series history, deferred since v0.1, is specified by BUS-2, and the full profile is claimable without a dispensation for the first time (2.3). What follows is what remains.

• Extraction of deployed control logic — v0.3 makes the distinction between design intent and running code expressible and auditable (10.5). It does not extract anything. A sequence is still referenced rather than read out of the controller, ASHRAE 231 is still design-time, and extraction still has no precedent in any standard — neither Project Haystack nor Brick has a control-logic construct of any kind. This remains the largest gap between this document and the charter’s reconstruction promise.
• Analytic rule portability — the extension interface attaches a result. It cannot carry the rule that produced it, and the boundary between a portable rule and a proprietary method is genuinely unclear.
• Signature formats — narrowed in this version to the minimum necessary surface: 19.2-1 fixes what is signed — the manifest bytes, which bind every digest and the actuation declaration — and names detached [JWS] or CMS as the envelope. Algorithm agility and key management remain outside the standard, deliberately; a building standard that adjudicates PKI will be wrong about it within the decade.
• Revision under concurrent editing — narrowed in this version from open to a stated assumption with a forward path: 6.6.1 names the single-writer assumption, requires serialize-or-fork under concurrent authority (test EX-11), and sketches the minimal merge rule a future MINOR version is expected to define. The merge rule itself remains open.
• Package scale — nothing bounds entity count or decompressed size. Test RT-14 measures scale without setting a threshold. A real portfolio export will find the limit before the standard does.

Three constructs were considered for this version against the two mature semantic models and declined. They are recorded because a reviewer can argue with a decision and has nothing to argue with in an omission.

• Weather stations, occupancy vocabulary, EV charging, synthetic and machine-learned models, point groups — declined — each is expressible today as a bus:Asset with relationships, property definitions and verbatim classifications, and none meets the promotion bar of 15.5: implemented by several independent parties, and about the building rather than about a product. Where an implementer finds one of these genuinely inexpressible rather than merely unnamed, that is the report 15.5 is waiting for.
• Prototype and expected-content templates — declined — Project Haystack carries prototype structure on 47 defs — what an instance of a kind is expected to contain — and it is the best idea in Haystack that this model lacks. It is still declined. It is a conformance-profiling mechanism rather than an information model: it states what a good export contains, which is Annex A’s job. Adopting it would put this document in the position of asserting that an air handler without a discharge temperature sensor is defective, which is an equipment-taxonomy judgment and 5.3.3 forbids it. The right home is a future test in group EX, expressed against the completeness declaration rather than against a class.
• Quantity dimension vectors — adopted after this document first declined them. Every one of the 29 quantities in Annex C now carries an SI dimension vector in bus-units.json, with a kind field so that an angle is not compatible with an efficiency and real power is not compatible with reactive. This entry originally recorded the decline; the vectors were adopted in the same version because test TS-5 needed them — a series' unit and its point's unit are compared by quantity family, and a comparison with no algebra behind it is a spelling check.

F.2 Decisions that merit challenge§

• No equipment taxonomy — defended in 1.4 and 5.3.3. The counter-argument is that a package whose classifications are all in vocabularies the receiver does not implement is portable in form and not in substance. Property definitions (7.8) are the mitigation; whether they are sufficient is untested.
• Relationships as entities — roughly a third of package size. A compact form for relationships carrying no provenance is worth considering.
• The size of the symbol role vocabulary — 52 roots and 75 named leaves — small enough to ratify, possibly too small to be useful. The fallback rule means the cost of being wrong is low, but the first implementer to hit the ceiling should say so.

NOTE This entry said "forty symbol roles" through v0.2, when the vocabulary file already held 52 roots. It was one of five places where the prose had drifted from the data it describes. Both figures above are now read from bus-symbol-roles.json when this document is built, which is the only fix that stays fixed.

• No point-function taxonomy — Brick 1.4.4 carries 938 point classes and Haystack composes the meaning of a point from tags. This document has 7 pointKind values and will not grow them into a taxonomy. 1.4 and 5.3.3 forbid it; the 7 kinds already span Brick’s branches with derived and meter besides; and the meaning of a point is carried by quantityKind against a property definition (7.8.1), by bus:measures naming the thing observed, and by verbatim classifications (7.7). Adopting a point taxonomy would duplicate two mature vocabularies, require this document to adjudicate between them — which 7.7 explicitly refuses to do — and age at the speed of the faster-moving of the two: Brick has deprecated 185 of its own classes, 112 of them into another organization’s namespace. The counter-argument is in the first entry of this subclause and is not dismissed.
• No growth of the symbol role vocabulary without implementer evidence — 32 of the 52 roots have no leaves at all, so the right answer to "possibly too small" is leaves under existing roots rather than more roots — and Requirement 13.4-1’s truncation rule means a leaf costs a receiver nothing, since an implementation supporting only roots is conforming. F.3 asks implementers how many roles were unavailable. Until one answers, growth is guesswork, and Annex B names the failure mode it would produce: a three-hundred-role taxonomy project that never ships. Figure mode is the designed escape for anything outside the vocabulary, and it was unusable until this version specified bus-vector-1 — which is why the correct response to role pressure in v0.3 was 13.4.3 and not more roles.
• Free-text knowledge notes — defended in 8.9 on the grounds that structure encourages discarding what does not fit. The opposite argument, that free text cannot be reasoned over and will be ignored, is also strong.
• Vendor-tree media type — correct today and wrong as soon as a governance body exists. The transition needs specifying before adoption, not after.

F.3 What review is asked for§

Implementers are asked to attempt an export from a real system at profile core-intent, and separately to attempt a graphics export, and to report: what the exporting system holds that the model cannot express; which completeness reason codes were needed and which were missing; how many symbol roles were unavailable; and what the export could not do without vendor assistance.

The last question is the one the charter cares about most and the one a schema cannot answer.

Implementers attempting a graphics export are asked for four figures in particular: the total number of distinct symbol roles the source system’s drawings require; how many of those had no match in the tier-one vocabulary even after truncation; the five to ten most frequently needed missing leaves, grouped under existing roots where possible; and whether figure mode was an acceptable substitute for each miss, or whether the loss of design-system control was material. Growth under existing roots is preferred over new roots, and a root with no leaves is not a defect — it is a placeholder that keeps the truncation rule usable. Answers in this form are a dataset; answers in any other form are a mood.