5 Architecture and design rules§
AGREED The design rules of 5.3 are the generative principles of the model. Every entity-level decision in clauses 6 to 15 follows from them.
5.1 Three layers§
| Layer | What it fixes | Lifetime |
|---|---|---|
| Information model (6 to 15) | Classes, properties, relationships, and the rules relating them. Normative and encoding-neutral. | Decades. Changes only through clause 18. |
| Binding (17) | How the model is written down. v0.2 defines one binding, in JSON. | Years. Further bindings may be added without touching the model. |
| Package (16) | How bound documents and resources travel and are verified. | Years. Container conventions change more often than the model. |
An implementation that has encoded the JSON binding into its internal design, rather than the model, will find the second binding expensive. Implementers are warned.
5.2 The boundary§
Applied to a graphic, the same test divides four layers rather than two, and the line falls between the third and the fourth. Clause 13.1 sets this out; it is the most consequential application of the boundary in this document.
5.3 Design rules§
Six rules generate the model. Where a later clause looks arbitrary, it is usually one of these applied.
5.3.1 Objects own intrinsic properties only§
This 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 of a thing rather than a fact about a pair of things. The cost is verbosity. The benefit is that any given fact lives in exactly one place, so the two cannot diverge.
NOTE Four constructs carry a reference intrinsically and are deliberate exceptions: Relationship names its subject and object; Binding names its element and target; Element names what it represents; Event names its subject. In each case the entity exists in order to connect, and would be meaningless without the reference. The exception is not available to ordinary entities.
5.3.2 Relationships are first-class entities§
A relationship has its own identifier, type, endpoints, qualifiers, validity period, provenance, and extensions (clause 9). This costs roughly a third of package size in the worked example. It buys the ability to say who asserted a connection and on what evidence, to end a relationship without deleting either endpoint, and to let an extension say something about a connection rather than about its endpoints.
5.3.3 Structure is specified; taxonomy is preserved§
The model defines a small structural class set and a controlled predicate set. It does not define what kinds of equipment exist. External classifications travel verbatim with their source vocabulary and version (7.7), and the shared vocabulary that does emerge grows bottom-up through property definitions (7.8) rather than top-down from a committee.
5.3.4 Intent is separate from implementation and from state§
What a building is meant to do is modeled separately from what it is doing and what it did. Sequences implement intent and are connected to it by bus:implements; they are not part of it. Conflating the three is the most common way intent is lost in migration.
5.3.5 Provenance is not metadata§
Any assertion may carry who made it, how, and how confident they were. An assertion whose origin is unknown is worth materially less thirty years later, and the model makes that visible rather than hiding it behind a uniform surface.
5.3.6 Omission is allowed; silence is not§
No exporter can carry everything. An exporter that carries less MUST say so, in a fixed vocabulary, in the manifest (16.6). This converts an unbounded quality problem into a bounded disclosure problem.