# Open questions and changes from the plan This specification was written from the reference implementation at `ff8574ec` and the specification plan of 9 October 2026 (an unpublished planning document, with the architecture, the open-source plan and the decision register beside it). Where the two differ, the text follows the code. This page lists every such place, the requirements the reference implementation does not meet yet, and the questions put to the steward, Erik Goverde: those he decided on 11, 14 and 15 October 2026, those he deferred to a later version, and those still open. ## 1. Changes from the plan | # | Topic | The plan | The code, and so this text | |---|---|---|---| | 1 | Where materials live | `materials/.json` at the root | `project/materials/.json` (Part III, 1) | | 2 | Levels | one file per level, `project/levels/.json` | one file, `project/levels.json`, holding the list in order | | 3 | Order of lists | not mentioned | `project/order.json` holds the order of every list but elements (Part III, 9) | | 4 | A view's detail chunks | `details/c-01.json` | `details/0000.json`, cut by an FNV-1a rule (Part III, 10) | | 5 | Site elements | `site//.json` | `site///.json`, like the other disciplines | | 6 | `eik.json` | format, profiles, units, disciplines and an id namespace | format and units only (Part I, 9.2) | | 7 | `.eik/` | generated indexes and neighbours, built by `ek index` | implementation state (a lock); `ek index` does not exist. The steward's decision of 11 October adds the optional derived layer `.eik/derived/` (Part IV, 1.1); its format is planned for 0.2 | | 8 | Binary assets | `assets/.`, stored by hash | not implemented; images are application records | | 9 | Element `width` | removed; a compound wall's thickness comes from its type | kept: every element has `width`; a layered type's thickness wins for the body (Part IV, 4.1). Decided on 11 October 2026: it stays | | 10 | Ids | `-<6 random base-32 characters>`, minted without coordination | any non-empty string without `/`, stable for the life of its record (decided on 11 October 2026); no two records' paths fold to one, and an id's path segment is at most 200 bytes (decided on 15 October 2026); the reference application mints UUIDs, and commands take the caller's id (Part I, 6) | | 11 | Material references | `materialId` | a layer's `material` text, matched to a material's name (Part II, 4). Decided on 11 October 2026: by id (`materialId`) before 1.0, with a migration (planned) | | 12 | Colours | under `display` | `color` on the type and on each layer | | 13 | Typed references | declared on every reference field | the code keeps a registry of element-to-element references (`ELEMENT_REFERENCES`); the schemas here add `x-eik-ref` from it and from the validator's checks (Part I, 7) | | 14 | Profiles | namespaced payloads (`framing: {…}`) and a `profiles` list in `eik.json` | flat members of the element; no declaration (Part II, 8). Decided on 11 October 2026: they stay flat | | 15 | Element schemas | one per category | one flat schema of 87 members; the per-category schemas here add the validator's category rules to it (Part II, 6) | | 16 | Wall tops in examples | `topRoofId` | legacy: folded into `top.attach` on load, refused in patches (Part II, 6.4) | | 17 | Commands | an envelope (`protocol`, `opId`, `actor`, `target`, `mode` with `propose`, `intent`), error codes, JSON pointers, mandatory preconditions, unknown keys refused | 91 command kinds without an envelope; modes apply and dry run; refusals as text; preconditions required on 51 kinds, optional on 26, absent on 14 (Part V). Decided on 11 October 2026: the envelope, error codes and a precondition on every command are planned for 0.2 | | 18 | `revision` (plan question 2) | keep it; a merge sets `max(ours, theirs) + 1` | already so (Part VI, 5.4) | | 19 | History | proposals, forks with an origin, git transport, a merge driver | versions, refs, alternatives, diff and merge are built, and since 14 October 2026 push and pull to a remote (Part VI, 6); the rest is not (Part VI) | | 20 | Agent interface | indicative tool names (`foga_*`), capability negotiation | 53 tools named for the reference application; no negotiation (Part VII) | | 21 | Compiler | normative body kinds N1–N6, tolerances, conformance vectors, typed quantities | the class-A rules are normative here; N1–N6, tolerances, vectors and typed quantities are informative or future (Part IV) | | 22 | Bridges | IFC 4.3, IFC 4 and IFC 2x3; GlobalIds from a repository namespace | IFC4 only; GlobalIds from the project id (Part VIII). Decided on 11 October 2026: GlobalIds stay derived from the project id; an IFC 4.3 export comes later | | 23 | Conformance classes | seven | the same seven and a *version store* class (Conformance) | | 24 | Single-file transport (plan question 4) | `.eik.json` | the reference names its files `.stomra.json`. What 0.1 settles, as decided on 14 October 2026: the file extension `.eik.json`, the media type `application/vnd.openeik+json`, and that a reader reads the form whatever its file is called (Part III, 11.1), with an informative registration template (11.2). What stays open: the IANA registration, a format id in the form itself, and an archive of a folder (section 3, question 20) | | 25 | An opening's offset | not stated | measured from its host wall's base (Part I, 4); the reference `AGENTS.md` says so too since Stomra pull request #778 (11 October 2026), having said "above the level" before, which is the same only when the wall's own offset is 0 | | 26 | Licences (F20) | CC0 for schemas, test vectors and examples | as the plan since 11 October 2026: CC0-1.0 for the schemas and examples; CC-BY-4.0 for the text, with the steward's OWFa 1.0 patent commitment (`PATENTS.md`); Apache-2.0 for the tools and packages | | 27 | Regional content | regional profiles for the values of national standards | none: no national classification or code list in the standard, and no regional profiles; such fields stay plain strings or application values; neutral classification references are planned for 0.2 (Part II, 8 and 11). Decided on 11 October 2026 | The plan's canonical form (RFC 8785) and the code's agree: the code's `canonicalJson` writes every JSON value as RFC 8785 does. ## 2. Requirements the reference implementation does not meet yet These are requirements of 0.2. Those of 0.1 that the reference implementation does not meet stay requirements of 0.2, in rows 1 to 41; rows 42 to 55 are 0.2's own, from Parts XIII to XVIII and the sections 0.2 adds. Each row says what the reference implementation does as the text beside its rule says it, with the change that met it where it has. | # | Requirement | What the reference does | |---|---|---| | 1 | Read `eik.json` and refuse unknown formats (Part I, 9.2) | met since Stomra #778 (live in Stomra since 11 October 2026, `main` `8ebedf05`): a folder or version naming another major version, another 0.x minor or units other than mm is refused; one without `eik.json` is read with a warning (rule 5) | | 2 | Keep unknown members (Part I, 10; Part V, 1.3) | Part I, 10 is met since Stomra #778 (`main` `8ebedf05`): a record keeps every member it does not know, at every depth, through reading, the store, versions, restores, merges and exports, and `ek validate` warns about each instead of refusing it; files that are no record are kept since #768. Part V, 1.3 is not: commands still refuse a member they do not know in an element, a patch or a view, and drop one in a type, except a member that a record of the model holds and that a command carries back as read, which they keep; a record a command changes keeps its own. So of a command that would add an extension member whose value is `null`, they refuse one in an element, a patch or a view, as Part V, 1.3 asks, and drop one in a type, where they should refuse it | | 3 | Do not drop unknown top-level command members silently (Part V, 1.4) | drops them | | 4 | Read a folder without a built-in library (Part III, 12) | adds its library of about 250 types, 6 title blocks and a detail family to every model; six of its nine single-file examples name a built-in gutter type they do not contain | | 5 | A sectioned beam's `height` is its section's depth (Part II, 5.3) | met since Stomra #777 (live in Stomra since 11 October 2026, `main` `21cd71c6`): set on every command and on load, a disagreeing patch refused. 278 sectioned beams in 11 cloud projects held another height and took their section's depth; their bodies did not change | | 6 | Member reference lines and axes (Part IV, 6.5) | the reference line and the taper rule are met since Stomra #777 (live in Stomra since 11 October 2026, `main` `21cd71c6`; joined sloped beams in three cloud projects moved to the body's middle line), and the axis (rule 5) since Stomra work 480 (live since 13 October 2026) for beams and columns with a section, `L` and `U` included, and for `T`, `2L` and `round` sections since Stomra work 558 (merged, `main` `ff98daa1`); a framing member keeps the box's middle (question 10) | | 7 | `eik.json` in every version's tree (Part VI, 2.2) | met since Stomra #778 (`main` `8ebedf05`): every version it saves holds the leaf `eik.json`, and a version saved before is read as `openeik/0.1-draft` in mm | | 8 | The derived layer (Part IV, 1.1), in the layout and with a result's form of 0.2 (1.1.2) | not built | | 9 | Ids unique in every list (Part I, 6) | checked for levels, grids, types, elements, views, sheets and references only; a type id may be empty | | 10 | Report a file whose path disagrees with its record (Part III, 4.2) | reads the record's members and ignores the path | | 11 | No `/` in an id (Part I, 6.4) | accepts `/` in every id but those of originals and copies, and escapes it as `%2F` in paths (Part III, 2), so a model it wrote may hold such ids | | 12 | Write no library records the model does not use (Part III, 13) | met for types since Stomra 641 (live since 23 October 2026, `main` `83aa3e13`), and for title blocks and detail families since Stomra 685 (live since 25 October 2026, `main` `9bd96356`): a record of its built-in library, unchanged and named by nothing, is left out of a folder and a version. A sheet that names no title block names its paper's generic frame, which is written. A frame an earlier build gave otherwise, never edited and unused, is still written | | 13 | Records it makes are of the thirty-one categories (Part II, 6.2) | since 11 October 2026 it has a category `person`; at `37e8f202` its built-in library holds five `person` types, which it writes into every folder it exports, and which a 0.1 reader keeps and warns about (Part I, 10, rule 5). Decided on 30 October 2026: a person is a `generic` element whose type stands for a person (Part II, 6.6, rule 9), and there is no category `person`. Its category `provision` is 0.2's (Part II, 6.10; row 41) | | 14 | A `swept` body only on a type, and the `line` frame only on an element, of a category placed along a line (Part II, 12.1, rules 4 and 7) | accepts both in a declaration of any category | | 15 | A type's declared envelope used in place of the derived body (Part IV, 11.1, rule 2) | since Stomra #787 (live since 12 October 2026, `main` `1e1089db`) for railing types only (a `swept` section); a declaration on a type of another category is kept and not drawn | | 16 | A bridge names the declared envelopes it exports in its fidelity report (Part IV, 11.1, rule 6, a SHOULD) | marks each such element in a property set of the IFC file, not in the report | | 17 | The `generic` category (Part II, 6.6; Part IV, 11.3; Part VIII, 1, rule 4) | has none, and refuses a record of it | | 18 | Keep the elements and types of a category it does not know (Part I, 10, rule 5) | refuses them when it reads them (a record's category is an enumeration), and does not carry them through a pull | | 19 | Clone a remote (Part VI, 6.5) | met since Stomra 500 (live since 14 October 2026, `main` `cd7173c9`): it clones `main`, a single-ref clone, into a new project connected to the repository as its remote; Stomra 495 (`main` `a7b7b13b`) fetches, pushes and pulls | | 20 | Members of its own only as extension members, under a prefix (Part I, 11.2, rule 2), and no values beyond the enumerations of 0.1 (rule 6) | writes, without a prefix and where a model uses them, members and a value 0.1 does not define. By the steward's decision of 30 October 2026 (open questions, 115), each member, category, value and reference that the generator's `LATER` held, reviewed at `bcfd44c7`, goes to 0.2 or under the reference implementation's registered prefix, `stomra` (registered since 17 October 2026). Those 0.2 takes are written in Part II, 4, 7 and 14 and Part IV, 4.6, and the reference implementation writes them as it does now. The others it is to write as extension members when it writes 0.2 (Part I, 11.5): an element's and a type's `person` as `stomra:person`, a person being a `generic` element (decision D9); a view's `display.colours` as `stomra:colours` in its `display`; a view's `calloutShape`, `calloutLabelOffset`, `calloutCornerRadius` and `breakLines` as `stomra:calloutShape`, `stomra:calloutLabelOffset`, `stomra:calloutCornerRadius` and `stomra:breakLines`; a detail family's `dimensions` as `stomra:dimensions`. Its category `person` (the five `person` types of its built-in library among them) and its category `provision`, whose elements carry `provision`, are decision D9's: a person is a `generic` element (Part II, 6.6, rule 9), and a provision a record of Part II, 6.10. What remains outside the specification: the members it added after `bcfd44c7`, an element's `tenderPart`, `action` and `littera`, a type's `littera` and `costCodes`, and the `costCodes` of a room's finishes (its works 758 and 768; open questions, 116). `textBackground`, on a detail item and in a view's display, is 0.1's since 24 October 2026 (Part II, 13.2) | | 21 | Name a single-file model `*.eik.json`, and label it `application/vnd.openeik+json` (Part III, 11.1, both SHOULDs) | names its own `*.stomra.json`, and labels none with a media type | | 22 | Names of files escaped as Part III, 2 says, and every escape decoded (decided on 14 October 2026) | met since Stomra 506 (live since 15 October 2026, `main` `a34cc1a1`): `segment` and `unsegment` follow rules 1 to 7, `ek export` writes the L-house's gutters as `study-roof%3Agutter%3Astudy-roof%3Aedge%3A0.json` and `…%3A2.json`, and its version trees of `@openeik/tools`' four test folders, the L-house among them, have the roots that package computes. A file named the older way is read with a warning naming its path, and moved with the next change saved (rule 9); a folder that holds both names of one record is refused. Before it, it escaped only `%`, `/` and a leading `~` | | 23 | No two records whose paths fold to one, and no id whose path segment is longer than 200 bytes (Part I, 6, rules 7 and 8; decided on 15 October 2026) | compares no paths folded, and bounds no id's path segment (it bounds a few ids by characters: a material's to 60): its validator accepts both, and its writer writes both, two such files being one where names fold | | 24 | Kept paths that hold no name a file system refuses or reads otherwise, fold to no other path of the model and pass through neither `eik.json` nor `AGENTS.md`; a version that a reader of a folder would lose a file of refused (Part III, 7, rules 2 and 8; Security and privacy, 5.3, rule 2; decided on 15 October 2026) | keeps such files as kept files, writes them, holds them in the versions it saves, and reads a version that holds them; its `keptPath` excludes only the exact paths of the engine files, so it saves `AGENTS.md/notes.md` from a folder with a folder named `AGENTS.md`. It saves a kept text over 1 MiB or with NUL from a single-file model it imports, and a version it saved before Stomra 506 holds a record or a level whose id starts with `.` under a hidden name. A 0.1 reader refuses each such version | | 25 | Keep the members of `eik.json` it does not know (Part III, 8.1; decided on 15 October 2026) | keeps them in a folder whose `eik.json` names `openeik/0.1-draft` in mm (`eikJsonKept`), but writes its own `eik.json` over one that names another format id of 0.1 (`openeik/0.1`), and holds its own, `{format, units}`, in every version's tree it saves, so that no version, and no folder written from one anew, has them | | 26 | The face of a wall whose type has no layers lies half the wall's `width` from its baseline (Part IV, 4.5, rule 1; Part II, 6.7; added on 20 October 2026) | met since Stomra 612 (live since 21 October 2026, `main` `7e68027f`): `hostThickness` takes a wall's `width` where its type has no layers. Before, it took the wall's `height`, so that an edge trimmed to such a wall, 3000 mm high, stopped 1500 mm off its centreline | | 27 | A pipe's insulation by a code and a thickness, a run's own beside its own code, and no `bti` written (Part II, 6.9, rules 3 and 4; decided on 24 October 2026) | met since Stomra 669 (live since 24 October 2026, `main` `2ea04ddd`): it writes a pipe's and a duct's code and thickness, a run's own beside its own code, and no `bti`; it reads a `bti` of an older model as rule 4 says | | 28 | A duct's insulation thickness is the model's: its type's `duct.insulation`, or a run's own `thickness` (Part II, 6.9; Part IV, 12.1, rule 3) | met since Stomra 669: when a duct's code is written, the thickness its table gives (`K25`: 50 mm) is written into the model, and a run is drawn by the model's thickness | | 29 | A component's `along` at most its run's length (Part II, 6.9, rule 7, a SHOULD) | keeps an `along` past its pipe's or, since Stomra 676, its duct's end when the run gets shorter, and stands the component at the end | | 30 | A view's filter hides a component in a pipe or a duct with its run, by the run's system and number (Part II, 13.1) | met since Stomra 669 for a component in a pipe, and since Stomra 676 (live since 24 October 2026, `main` `f02ba07e`) for one in a duct: a component is hidden with its run, by the run's system and number | | 31 | A view's filter names a number from 1 to 99 without a leading zero (Part II, 13.6, rule 1) | met since Stomra 669 for what it writes: it writes `heating:05` as `heating:5` and refuses `heating:0` in a new command; it still reads both in an older model or log | | 32 | A terminal in the IFC system and number of the runs joined to it (Part VIII, 1.1, informative) | met since Stomra 669: a terminal other than a component is in the system and number of the runs of its system joined to it, else in the project's only heating system, else under 1 | | 33 | A terminal's design temperature difference from 1 to 80 K (Part II, 6.9, rule 5), where an application works it out from a heating system's temperatures too | met since Stomra 669 for what it writes: a new heating system whose return is as warm as its supply or warmer, or whose supply less return lies outside 1 to 80 K, is refused; it still reads such a system of an older model, and then works out no flow | | 34 | Where another roof of its group buries a gutter, found exactly from the faces' outlines (Part IV, 4.7, rule 6; decided on 26 October 2026, open questions, 75) | finds it at 25 points along the eave line, and runs a piece on to the first point it finds buried, which leaves the piece up to a twenty-fourth of the eave line longer, and drops a piece shorter than that; it draws a half-round's arc in 10 pieces. The steward's decision lets a tolerance of a twenty-fourth of the eave line hold until it finds it exactly | | 35 | A shaft's RECESS where it ends inside its host, and its opening in a foundation a stair's shaft cuts (Part VIII, 1.3; decided on 26 October 2026, open questions, 77) | met since Stomra 750 step 1 (live since 28 October 2026, `main` `5f5fc807`): it writes a RECESS where a shaft ends inside its host and an OPENING where it runs through it, and an opening in the foundation a stair's shaft cuts, as its bodies cut it. Before, it wrote an OPENING in every slab, ceiling and roof a shaft met, a recess too, and none in a foundation | | 36 | A door's operation type looking the way it opens (Part VIII, 1.2, a SHOULD; decided on 26 October 2026, open questions, 71) | met since Stomra 727 step 4 (merged on its main on 28 October 2026, `main` `bb4037f2`): it writes a door's operation and a window's partitioning with `doorOperation` and `windowPartitioning` of `@openeik/tools`, on the type, an IFC type for each way its doors open, and a sliding door's side looking the way it opens; on the reference implementation's seven examples, all 217 doors, windows and their types are written as the bridge of `@openeik/tools` writes them. Before, it wrote SLIDING_TO_LEFT where a door slid towards its opening's start and SLIDING_TO_RIGHT towards its end, whichever side it opened to, NOTDEFINED for a door that swings, and NOTDEFINED on every type and window | | 37 | A rebar element hosted by a slab, a foundation, a beam, a column or a slab edge element, and a mesh element by a slab, a foundation or a wall (Part II, 6.1, rule 6; decided on 26 October 2026, open questions, 81) | lays a bar set (`bars`) in a slab, a foundation, a beam, a column or a wall (`barHosts`), and writes one in a wall (`rebar.quick`, its set `wall`), which rule 6 does not allow; refuses a bar set in a slab edge element, and reinforcement in a layer (`reinforcement`) in anything but a slab or a foundation | | 38 | A `rectangle`'s `radius` rounds its corners and is at most half its smaller side, and a `custom` section is its outline (Part II, 5.2, rules 7 to 10; decided on 27 October 2026, open questions, 87) | reads a `rectangle`'s `radius` since 27 October 2026 (main `d12a2c54`); it refuses a larger `radius` only in a command that writes it, and reads a project that holds one, which a reader that performs the whole-model check refuses (Part III, 12), drawing it with its corners rounded to half its smaller side; such a project takes its other commands, which Part V, 6, rule 3 refuses while the model fails the check. It reads a `custom` section since 28 October 2026 (main `35bef7f5`), refusing an outline that breaks rule 9 in a command that writes it | | 39 | Folders that follow owners: each record in its owner's folder, both layouts read, and the change of layout (Part III, 4.4; decided on 27 October 2026, open questions, 85) | decides each record's owner as Part III, 4.4, rules 1 to 5 do (`elementOwner`, `typeOwner`, `sheetOwner`, its work 670), but for a `generic` record of `systems`, which it gives to `setup`; writes 0.1's folders, reads no other, and writes an owners file of 0.1's folders with globs that name categories (`ownersFile`); makes no change of layout. To be met when it writes 0.2 | | 40 | A truss layout's trusses, ridge beam, ridge posts and anchor pairs named in English (Part IV, 7.4.13, rules 13 and 15; 7.4.16, rule 10; decided on 30 October 2026) | names them with Swedish words: a truss `Takstol T3`, a girder's ply `Takstol T1 (bärande, lager 2)` and one along the ridge `Takstol T1 (bärande, längs nocken)`, a hip truss `Valmstol H1`, a jack `Kortstol J3`, a ridge beam `nockbalk`, a ridge post `nockstolpe` and an anchor pair `Takstolsvinkel, par (truss clip pair)`, where the rules name them `Truss T3`, `Truss T1 (girder, ply 2)`, `Truss T1 (girder, along the ridge)`, `Hip truss H1`, `Jack truss J3`, `ridge beam`, `ridge post` and `Truss clip pair`; it names every member's role in English already | | 41 | A provision for a void as Part II, 6.10 and Part VIII, 1.10 write it (decided on 30 October 2026) | its requests for openings (its work 670, step 6.1) are provisions, with Part II, 6.10's members, but for three points: its answer's `state` is `accepted` where the text says `cut`; its answer's `cut` names one recess by its id, a string, where the text names what the cut made in a list, `[{"recess": …}]`; and its IFC print writes the set `Pset_ProvisionForVoid`, IFC 2x3's name, which buildingSMART's rule PSE001 refuses in IFC4, where the text writes `Pset_BuildingElementProxyProvisionForVoid` | | 42 | Read and write OpenEik 0.2: `openeik/0.2` in `eik.json` and at the top of the single-file form, and a model of 0.1 read by 0.1's rules (Part I, 9.2, 9.6, rule 3; Part III, 11, rule 5) | refuses a folder or a version that names another 0.x minor (row 1), and so reads no folder of 0.2; writes `openeik/0.1-draft` (row 25), in 0.1's folders (row 39). To be met when it reads and writes 0.2 | | 43 | Migrate a model of 0.1 to 0.2 in one write (Part I, 9.8) | makes no migration: it writes 0.1 and makes no change of layout (rows 39 and 42) | | 44 | An emergency luminaire is an `electrical` element of the kind `emergencyLight`; the `fire` kind `emergencyLight` is deprecated (Part XIII, 2.3, rule 7) | writes emergency luminaires as `fire` elements until its work on this kind lands (Part XIII, 2.2, the note) | | 45 | A device's protective earth, `electrical.earth` (Part XIII, 2.2; open questions, 94, decided on 30 October 2026) | has no `earth`: it writes `HasProtectiveEarth` for an outlet whose `connector` is `type F`, and for no other (Part XIII, 2.2, the note) | | 46 | A railing on the outline of a slab or a shaft, on a wall's top or along a slab edge element, written without its deprecated `profile` (Part II, 12.2.1; Part I, 9.8, rule 4) | writes and rewrites the copy of a railing on an outline, as 0.1 asks, and one point, `[[0, 0]]`, for a railing on a wall's top or along a slab edge element; it stops writing the profile when it writes 0.2 (Part II, 12.2.1, the note) | | 47 | Sheets as records of Part XIV, and drawings issued in its SVG profile with its files and records (Part XIV, 2 and 6 to 11) | its sheets are application records, whose members Part XIV, 2.3's note maps onto that part's; the SVG it draws is its screen's markup, which the SVG profile refuses (Part XIV, 6.12, the note); its issuer, off its flag since Stomra 566, writes Part XIV's files (Part XIV, 1.6's note) | | 48 | Assets by digest in a folder, and as pointers in its versions (Part XV, 2 and 3) | keeps the PDFs it publishes as files of its project, outside the model, and its issued SVGs as kept files (Part XV, 11, the note); its own store of asset bytes is its own (open questions, section 4, D11) | | 49 | Commands in an envelope, refusals with codes, and a precondition on every command (Part XVII) | implements none of Part XVII yet (Part XVII, 13, the note): its commands carry no id (Part XVII, 3, the note), and of its 91 kinds of command 14 take no precondition (Part XVII, 9.2) | | 50 | A suggestion is an envelope in the mode `propose` (Part XVI, 5, rule 5; decided on 30 October 2026) | keeps a change that a person's disciplines do not cover as a draft, sent to the parties that own its records; its exchange as BCF carries a suggestion's commands in a document of a form of its own (Part XVI, 5, the note) | | 51 | An IFC print names its version, the bridge and who printed it, and says that it is a print (Part XVIII, 7.2; Part VIII, 1) | its bridge writes the time of the export in the header's `FILE_NAME`, and no `IfcApplication` or `IfcOwnerHistory`: two exports of one version differ, and neither says which version it came from (Part XVIII, 7.2, the note) | | 52 | A member between two points, of the category `member` (Part II, 6.2.1; Part IV, 6.7; decided on 30 October 2026, open questions, 110) | has no `member` category: it records a brace as a beam with an `endRise`, which needs a run in plan of 10 mm or more, and its columns do not lean (Part II, 6.2.1, the note) | | 53 | A slab on a sloped plane (Part II, 6.3.1; Part IV, 4.2.1; decided on 30 October 2026, open questions, 111) | has no sloped slab: its slabs are level, and a sloped plate is written as a roof (Part II, 6.3.1, the note) | | 54 | The profile of a door's or a window's frame, mullion and sash (Part IV, 4.3.1, rule 15; decided on 30 October 2026, open questions, 97) | draws a frame's members as boxes of `frameWidth` by `frameDepth`, has no profile yet, and names a profile system only as a plan of its work 749 (Part IV, 4.3.1, the note) | | 55 | A room's boundary, ceiling and quantities (Part IV, 7.5; open questions, 72) | differs where Part IV, 7.5 decided otherwise, in the seven points its note lists: a room separator and a floor's edge as a line; the face two rooms share; a room's `height` as its last ceiling, where it takes 2500 mm; a ceiling under a roof whose extent is not convex; a door's or a window's opening from its host's base; a room's floor at its level plus its `offset`; and a barrel vault. None of them made a difference on the rooms compared | Two findings of the OpenEik manual (chapter 8) are fixed in `ff8574ec`: a hand edit that makes two openings overlap is now refused by `ek validate`, and a patch of a size the type sets is refused. ## 3. Questions for the steward Each question is marked **decided** or **deferred**, with the date and the decision, **proposed**, with what a part proposes until the steward decides it, or **open**. The steward's word of 11 October 2026 applied the proposed defaults; the non-profit body is still under consideration. On 15 October 2026 the steward decided questions 23 to 27 and 29 as recommended, deferred question 28 to a later version, and deferred the open parts of questions 6, 10, 17 and 18 to 0.2. 1. **Licences.** Keep Apache-2.0 for the schemas or use CC0 as F20 proposes? Which licence covers `examples/`? Which patent commitment goes with the text? **Decided, 11 October 2026:** as F20. The specification text is under CC-BY-4.0 (`LICENSE`), with a royalty-free patent commitment by the steward under OWFa 1.0, Patent Only (`PATENTS.md`). The schemas and the examples are under CC0-1.0 (`schemas/LICENSE`, `examples/LICENSE`). The tools and packages are under Apache-2.0 (`LICENSE-CODE`). 2. **DCO.** Should the founding commits be signed off too, or does the DCO start with the first outside contribution? **Decided, 11 October 2026:** the DCO starts with outside contributions; the earlier commits need no sign-off (`CONTRIBUTING.md`). 3. **The steward at stage 0.** Who signs as steward and holds the name until a neutral home exists? **Decided, 11 October 2026, provisionally:** Erik Goverde is the steward at stage 0 (`GOVERNANCE.md`). **Open:** before the public launch, a non-profit body to hold OpenEik, separate from any commercial service, is being considered; no legal form is decided. 4. **Regional content.** Room area classes, area kinds, rebar shape codes, steel and mesh designations of one country are left as plain strings. Who checks their licensing, and when does the first regional profile come? **Decided, 11 October 2026:** no national code lists in the standard. OpenEik carries no BSAB, CoClass, AMA, SS 21054 or other national classification or code list, and no regional profiles with such content: code lists belong to their publishers, so there is no licensing for the standard to check. The fields that hold national values today (room area classes, rebar shape codes, steel and mesh designations, the building-part catalogue `assembly`) stay plain strings or opaque application values. From 0.2 any record MAY carry neutral classification references, `classifications: [{"system", "code", "edition"?}]`, so that any system can be used without the standard licensing or listing it (Part II, 11, planned). Regional profiles are removed from the roadmap; Part II, 8, and the changelog say why. **Written, 30 October 2026:** the classification references, as [Part II, 11](https://openeik.org/spec/0.2/language#11), proposed for 0.2 behind the proposal `classifications`, rules 1 to 6, with `uri` from question 86; and [Part VIII, 1.8](https://openeik.org/spec/0.2/bridges#1.8), their IFC. 5. **The command envelope.** Adopt the plan's envelope and machine-readable error codes for 0.2, and make preconditions mandatory on every write? **Decided, 11 October 2026:** planned for 0.2: a common command envelope, machine-readable error codes and a mandatory precondition on every command (Part V, 3, 6 and 10; the changelog's Planned section). [Part XVII](https://openeik.org/spec/0.2/envelope), proposed on 25 October 2026, proposes all three; its own questions are 53 to 60. 6. **Ids.** Make the plan's minting rule (`-<6 base-32>`) a requirement for writers, and forbid `/` in every id? **Decided, 11 October 2026:** an id MUST be stable for the life of its record, and `/` MUST NOT appear in an id (Part I, 6.3 and 6.4). The reference implementation still accepts and escapes `/` (section 2, 11). **Deferred to 0.2, 15 October 2026** (the steward's decision): whether writers MUST mint ids by the plan's pattern. In 0.1 the pattern stays a recommendation ([Part I, 6, rule 5](https://openeik.org/spec/0.2/foundations#6)); what 0.1 bounds is the length of the name an id gives (question 26). **Decided, 21 October 2026** (the steward's decision): no. The pattern stays a recommendation (Part I, 6, rule 5). What a reader relies on is required already: an id is unique in its list and stable, holds no `/`, gives a path segment of at most 200 bytes, and folds to no other (rules 1, 3, 4, 7 and 8). A required pattern would make existing models invalid, the reference implementation's among them, whose commands derive the ids of what they make (`wall`, `wall-2` …), and those that keep the ids of an IFC file, and it would give a reader nothing. 7. **`width` on walls**, **materials by name** and **flat profile members**: keep them, or change them once before 1.0 with a migration? **Decided, 11 October 2026:** a wall's `width` stays (a layered type's thickness wins) and profile members stay flat. Materials will be referenced by id (`materialId`) rather than by name before 1.0, with a migration (planned; Part II, 4). 8. **Sheets, title blocks and images**: stay application records, or join the documentation profile? **Decided, 11 October 2026:** they stay application records (Part II, 9.1). **Revisited, 15 October 2026:** from 0.2, sheets and issued drawings join the standard, by the steward's decision (CHANGELOG, Planned for 0.2). In 0.1 they stay application records. [Part XIV](https://openeik.org/spec/0.2/drawings), written by the steward's decision of 16 October 2026, proposes them in full for 0.2. 9. **The built-in library.** Should writers stop writing library records that nothing names? **Decided, 11 October 2026:** writers SHOULD NOT write library records the model does not use (Part III, 13). The reference `ek export` writes about 250 built-in types into every folder: a gap (section 2, 12). Since Stomra 641 (live since 23 October 2026) it leaves out every type of its built-in library that is unchanged and that nothing names; its title blocks and its default detail family are still written. 10. **Member axes** of non-symmetric sections (`L`, `U`): the middle of the section, or its centroid? And the axis of a beam built from a framing family? **Decided, 11 October 2026, and refined the same day:** a member has a reference line, through the middle of its section (its bounding-box centre), which placement, roll, joins and trims use; and an axis, the centroidal line of the body as built after roll, which analysis tools and analytical exports MUST use. For an asymmetric section the axis follows the centroid; for a symmetric section the two coincide (Part IV, 6.5). Stomra pull request #777 (live since 11 October 2026) computes the reference line for sectioned beams; Stomra work 480 (live since 13 October 2026) computes the axis with the centroid offset for members with a section (section 2, 6). **Deferred to 0.2, 15 October 2026** (the steward's decision): the reference line and axis of a beam built from a framing family. In 0.1 such a beam takes its body from its family, a class-C rule, and has neither line ([Part IV, 6.5](https://openeik.org/spec/0.2/compiler#6.5)); the reference implementation keeps `z0 + height/2` along its profile, with its `endRise`. **Decided for 0.2, 21 October 2026** (the steward's decision): such a beam has a reference line, the middle of its height over its set-out line (`z0 + height/2` along its profile, rising by its `endRise`), as a sectioned beam's runs through the middle of its section and as the reference implementation keeps it; its joins and trims use it. It has no single axis: a family's parts, a truss girder's chords and diagonals or an I-joist's flanges and web, have no one centroid, so an analysis takes each `member` part as a member of its own, with its own axis through its middle. Part IV, 6.5 says so from 0.2. **Refined for 0.2, 22 October 2026** (the steward's decision, asked by an analysis application): a reader that cannot place a family's `member` parts, because it does not evaluate the family's expressions (Part II, 5.4), leaves such a beam out of an analysis and says so. A member of its own on the reference line would carry loads with a section the beam does not have. Part IV, 6.5 says so from 0.2. **Written, 30 October 2026:** [Part IV, 6.5.1](https://openeik.org/spec/0.2/compiler#6.5.1), proposed for 0.2 with the proposal `framing` (Part IV, 6.6): rule 1, the reference line from `(P0, z0 + height/2)` to `(P1, z0 + r + height/2)`, which joins and trims use; rule 2, no single axis, each `member` part a member of its own; rule 3, a reader that cannot place the parts MUST leave the beam out of an analysis, SHOULD say so, and MUST NOT stand a member on the reference line in its place. `compileModel` of `@openeik/tools` gives the line with the proposal. **Confirmed, 30 October 2026** (the steward, in the openEik.org thread: "allt ja enligt din rekommendation"; section 4): section 6.5.1 was written as a proposal of its own, `framingLines`, and folded into the proposal `framing`, which builds the parts of section 6.6; the fold stands. A tool gives such a beam its reference line when it is asked for `framing`. 11. **The derived layer's format**: fix the layout and the result schema in 0.2? **Decided, 11 October 2026:** yes, planned for 0.2 (Part IV, 1.1). 12. **IFC**: target IFC 4.3, and derive GlobalIds from a repository namespace rather than the project id? **Decided, 11 October 2026:** an IFC 4.3 export comes later (Part VIII). GlobalIds stay derived from the project id: the project id travels with every version and every fork of the project, so an element keeps its GlobalId across them, while a repository namespace would change when the model moves (Part VIII, 1). 13. **Application values**: the type's `assembly` (a building-part catalogue), `catalogSource` and `handbook`, the project's `standards` and the font choices are accepted as opaque values. Is that the right line? **Decided, 11 October 2026:** yes. Catalogue, handbook, standards and fonts stay opaque application values (Part II, 9.2). 14. **Part VIII.** The task named Parts I–VII; the plan has a Part VIII for bridges. Keep it? **Decided, 11 October 2026:** Part VIII is kept. 15. **A word in the history.** Commit `e12be88` matched the search for banned names in `spec/06-history.md`. Rewrite the history before the repository is published? **Decided, 11 October 2026:** no rewrite. The match was a few letters inside a code identifier, not a banned name. 16. **The schema annotation for national values.** With no regional profiles, the annotation `"x-eik-profile": "regional"` that the schema generator puts on fields with national values no longer fits its name (Part II, 8). **Decided, 11 October 2026:** renamed. The generator writes `"x-eik-values": "national"` on those fields (Part II, 8.3). 17. **Records at a declared level of detail.** A supplier of a building part (a railing, a window, a truss) wants to share geometry exact enough for clash and layout checks without giving away how it makes the part: the interface, not the implementation. That means the outer envelope, the fixing and connection points, clearances, positions such as posts and fixings, loads on the structure and the declared tolerances, but not internal profiles, joints, machining data, article numbers or costs. Should a type (or an element) be able to carry geometry at a declared level of detail, stating what it is authoritative for (for example "envelope, fixings, clearances", not fabrication), and how do readers and checks treat such records? Raised 11 October 2026 with the supplier proposal flow. **Decided in principle, 11 October 2026: proposed for 0.2** (Part II, 12.1; Part IV, 11.1; Part V, 11). A supplier's records, and every record in its proposal, can carry geometry at any level of detail, the supplier's choice: from the interface only (the envelope, fixings, clearances, positions and loads, with tolerances; enough for exact geometric checks and layout control) up to the full manufacturing model. The supplier publishes at least the interface; the implementation is its own to keep back or to share. A supplier may share everything; the point is that its proposal can have any level of detail. Interface only is a valid minimum, not the rule. - A record declares its `level` (`interface`, `assembly` or `fabrication`) and what its geometry is `authoritativeFor`, from a closed vocabulary: `envelope`, `fixings`, `clearances`, `positions`, `loads`, `parts` and `fabrication`. Every declaration is authoritative for `envelope`, with its tolerances. - Checks use what is declared, within its tolerances, and say when a declaration cannot decide a question. A compiler derives nothing beyond what a record declares itself authoritative for, and never derives fabrication data from declared geometry. - Declared geometry is the supplier's source, not derived output: no rule of the model can make it again, so it does not break the rule that derived data is not stored (Part II, 10). When a record it was made against changes, it is kept and reported as unconfirmed, not discarded. - Costs, prices and quotes stay out of the model: the quote lives with the proposal on the host. **Adopted into 0.1, 14 October 2026** (the steward's decision): Part II, 12.1, Part IV, 11.1 and Part V, 11 are normative in 0.1, with `declaredGeometry` in the type and element schemas. The schema details that were open are settled by the text: the member `declaredGeometry` and its shape; the body kinds and their names (Part II, 12.1, rule 4); the frames of a type placed at a point, of a hosted opening and of a type placed along a line, and an element's `world` and `line` frames; loads as characteristic values in kN and kN·m per named load case, in the model's axes, with the mirror's signs; `fabrication` as the supplier's application value or kept files named by path and hash; `basis` by hash; and an element's declaration winning over its type's, aspect by aspect. **Deferred to 0.2, 15 October 2026** (the steward's decision): whether the sizes a type sets (Part II, 5.3) must agree with its declared envelope; and the frame of a declaration on a type of a category that Part II, 12.1 does not name (a stair kit's, for one). In 0.1 nothing requires the sizes to agree with the envelope, which replaces the derived body where a body stands for the space taken ([Part IV, 11.1](https://openeik.org/spec/0.2/compiler#11.1)); and such a declaration is kept and checked, but placed nowhere: the part declares its geometry on its element, in the `world` frame ([Part II, 12.1](https://openeik.org/spec/0.2/language#12.1)). **Decided for 0.2, 21 October 2026** (the steward's decision): the sizes a type sets need not agree with its declared envelope. They stay its nominal sizes, which schedules and tags show, and the declaration is the geometry where it stands for the space taken (Part IV, 11.1); a validator MAY warn where they differ by more than the declaration's tolerance. Two more categories get a frame, those whose parts suppliers ship whole: a stair's type, a stair kit's (the stair's start at its base, x up its first run towards the profile's second point, y to its left, z up), and a wall's type, a prefabricated wall's (the baseline's first point at the wall's base, x along the baseline, y to its left, its exterior, z up). A type of any other category keeps none, and its parts declare their geometry on their element, in the `world` frame. **Written, 30 October 2026:** [Part II, 12.1.1](https://openeik.org/spec/0.2/language#12.1.1), proposed for 0.2 behind the proposal `declared`: rule 1, the sizes stay nominal, and a validator MAY warn where `width` or `height` differs from the envelope's extent along the type's frame's x or z by more than the declaration's tolerance for `envelope` (`declared-size`); rules 2 and 3, a stair kit's and a prefabricated wall's frame as decided; rule 4, no other category's type has one; rule 5, a compiler places them. Part IV, 11.1's note points to it. 18. **Railings for product systems.** A railing supplier needs side mounting, rectangular posts, an end distance, posts and infill below the slab, rail shapes, panel patterns and a corner cut, and its post positions in the record: the reference implementation and a supplier's tool place the posts of one railing differently. 0.1 also requires all thirteen type members for every kind, and does not state the rules for a railing's host and edges. Raised 11 October 2026 by a study of a railing supplier's tool against OpenEik. **Decided in principle, 11 October 2026, with the supplier proposal flow: proposed for 0.2** (Part II, 12.2; Part IV, 11.2). Optional type members `mount`, `postWidth`, `postDepth`, `postEndDistance`, `belowBase`, `topRail`, `panelPattern` and `corner`; type members required only for the kinds that use them; element members `insets` and `posts` (`at`, `omit`), with `railing.posts.at` as the normative post positions; the host and edge rules in Part II; and a railing's line on the edges of a slab or a shaft as a class-A rule. On that day the reference implementation met the host and edge rules and none of the new members. **Decided with the reference implementation, 11 October 2026:** `posts.at` is measured along the railing's line in plan and does not move with an inset; the corner of two different insets is where the moved edge lines cross; the value lists of `topRail`, `panelPattern` and `corner` as in Part II, 12.2; `posts.omit` is a list; a post rises to the top rail; positions beyond the line's end are reported, not refused (Stomra #786, live in Stomra since 12 October 2026 (`main` `1e1089db`)). **Adopted into 0.1, 14 October 2026** (the steward's decision): Part II, 12.2 and Part IV, 11.2 are normative in 0.1, with the new members in the type and element schemas, and the line of a railing on an outline and its given posts are class-A rules. **Deferred to 0.2, 15 October 2026** (the steward's decision): whether a hosted railing keeps the profile its writer copies from the host, or the profile becomes derived and is no longer stored; railings on a slab edge element or a wall's top (a parapet); and stair railings. In 0.1 a hosted railing's profile, level and offset are its writer's copy, rewritten with its host, and a reader follows the host where they disagree; a railing on a slab edge element or a wall's top stands on a line of its own; and a railing on a stair is placed by reference behaviour ([Part II, 12.2](https://openeik.org/spec/0.2/language#12.2); [Part IV, 11.2](https://openeik.org/spec/0.2/compiler#11.2)). **Decided for 0.2, 21 October 2026** (the steward's decision): - The line of a railing on the outline of a slab or a shaft is derived, as Part IV, 11.2 gives it, a class-A rule. From 0.2 its `profile` is no longer its writer's copy: the copy is deprecated (Part I, 9.6), a reader derives the line and ignores it, a writer no longer rewrites it when the host changes, and the element schema lets such a railing leave it out. Its `levelId` and `offset` stay as written, the host's level and 0. A railing on a stair keeps its copy. - Two hosts join: a wall, on whose top a parapet railing stands along its centreline, following its attached top where it has one; and a slab edge element, along whose outer face an edge railing runs. The reference implementation builds them first. - A railing on a stair stays reference behaviour until a stair's flights have a class-A rule: a railing cannot be placed more exactly than the stair it follows. **Built by the reference implementation, 23 October 2026** (Stomra 643, live since 23 October 2026, `main` `acf86581`), from which 0.2's text will be written: - **The record.** A railing names a wall or a slab edge element in `hostId`; its `railing` holds at most `inset` (mm) and `posts` (`at`, `omit`), and refuses `side`, `edges` and `insets`; its `levelId` is the wall's level, or the slab's of the slab edge element; its `offset` is 0; and its `profile` is one point that means nothing, since the schema of 0.1 asks for one. Its line is derived and never written, and the record does not change when its host does. - **On a wall's top.** With `a`, `b` the wall's baseline, `u` its direction, `n` its left and `T` its thickness (Part IV, 4.1), the line runs from end to end of the baseline at `a + u·x + n·(T/2 − d)`, where `d` is `railing.inset`, measured from the exterior face, and by default `T/2`, the middle of the wall's top. Its height follows the wall's top as built: the upper edge of its elevation outline where it has one (an attached top, a profile of its own), stepping where the top steps, else the wall's height. Its walking side is the wall's interior. - **Along a slab edge element.** The line runs along the element at a reach `d` from its outer face towards the slab, by default the middle of its top face, between the element's own ends (square, or mitred on a corner's bisector), at a constant height: the element's top, and never under its slab's top. Its walking side is the slab's. - **Posts** are placed as on an outline (Part IV, 11.2, rules 5 and 6), corners including a wall top's steps and slope breaks. - **Decided, 24 October 2026** (the steward's word on the recommendations, and "railings into 0.1"): the two hosts join 0.1, not 0.2, as heating, ventilation and plumbing did, since the reference implementation writes them. A railing on a wall's top takes no `side`, its walking side the wall's interior, so that flipping the wall flips it; the default inset of both hosts is the middle of the host's top; and their `profile` becomes optional, as the derived line of a railing on an outline makes it. An edge railing runs along the middle of its element's top by default, its inset measured from the element's outer face. Part II, 12.2 and Part IV, 11.2, rules 8 to 11 hold the text. The derived line of a railing on an outline, and an optional `profile`, stay 0.2's. **Written, 30 October 2026:** the 0.2 part, in [Part II, 12.2.1](https://openeik.org/spec/0.2/language#12.2.1), proposed behind the proposal `railings`: a railing on an outline may leave out its `profile`, whose copy is deprecated, a reader ignoring it and a writer neither rewriting nor writing it, its `levelId` and `offset` as written; a railing on a wall's top or along a slab edge element may leave out the one point 0.1 asks for; a railing on a stair keeps its copy, and one with no host its line; a validator warns of a deprecated profile (`railing-profile`). 19. **Extensions.** Applications add data of their own to a model: members in records and files in the folder. Every reader keeps them (Part I, 10; Part III, 7), but nothing keeps two applications, or an application and a later version, from using one name for two things. How does an application add data without clashing? **Decided on 14 October 2026** (Part I, 11; `registry/`): a prefix registered to the application marks everything it adds: members named `:` in records, and in the objects of result manifests and proposals below their top, and files in a folder `/` at the top of the model's folder. A prefix is 2 to 32 lowercase letters, digits and hyphens, and an extension member is a member of an object whose members a schema names, never a key of a map keyed by ids. The registry is `registry/extensions.json`, kept by merge request under the rules of `registry/README.md` (first come; a contact and a short description; no squatting on names that are not the registrant's), and checked against `schemas/registry/extensions.schema.json` by `npm test`. `eik`, `openeik`, every prefix that starts with `eik-` or `openeik-`, the folder names of a model and `assets` are reserved, in any case at the top of a folder. Every reader, validator, compiler and command processor treats a model with extension members as the model without them, but for keeping them (a precondition compares the whole record, extension members included), so no reader needs one; no version of the specification defines a member with a colon or takes a registered prefix; and a later version takes an extension into the core by RFC, under a name without a prefix, saying how its readers read the old members. `@openeik/tools` reports an extension member as one (`member-extension`, an info), not as a member it does not know, and follows no extension member as a reference. Decided with it, as proposed: the scheme, over one object per application keyed by its registered id (`"extensions": {"acme": {…}}`), which a patch replaces whole (Part V, 4) and which every schema would have to name, and over unregistered `x-` prefixes, which keep an application apart from the specification but not from other applications; the form of a prefix and the colon; and registering as a SHOULD. Still open: whether the reference implementation registers a prefix for the members it writes ahead of this text (section 2, 20); and the registry's licence (CC-BY-4.0, as a document of this repository, unless it is put under CC0-1.0, as the schemas are). 20. **The single-file form's file extension and media type** (the plan's question 4; section 1, 24). **Decided on 14 October 2026** (Part III, 11.1 and 11.2): the file extension `.eik.json`, as the plan proposed, and the media type `application/vnd.openeik+json`, a JSON type with the `+json` suffix and no parameters; a reader reads the form whatever its file is called. An informative template is ready for the IANA registration, planned before 1.0. The reference implementation keeps writing `*.stomra.json` until it changes (section 2, 21). Decided with it: the file extension `.eik.json`, over `.eik`, which a desktop system can open with a modelling application but no JSON tool recognises, and `.openeik.json`; and the media type's name. Still open: the contact address the registration names; whether the single-file form carries its format, as `eik.json` does for a folder (it carries only `schemaVersion`), or the media type a `version` parameter; and a file extension and a media type for an archive of a folder (a zip), which 0.1 does not give. 21. **Errata, deprecation, and how long an earlier version is read.** **Decided on 14 October 2026** (Part I, 9.5 and 9.6; `GOVERNANCE.md`): a version is published when it carries no pre-release suffix, and is then corrected only by errata, which make it say what its rules, as they were meant, already said; a change to those rules goes to a later version by RFC. Errata are listed per minor version in `errata/..md`, accepted by an editor and the steward, announced in the list, the changelog and on openeik.org, and gathered into patch versions, which change no requirement; the schemas' `$id`s serve the latest patch version, and a tag keeps each one. A reader of a published version reads its drafts' models as that version, with a warning. A deprecated feature is still read and is no longer written; only a version that may break compatibility removes it. A reader SHOULD read the version its own version replaced (for 1.0, the last 0.x version); how long implementations keep doing so is a policy in `GOVERNANCE.md`, not a rule: at least 12 months after the version that replaces it is published, and 24 months when that version is 1.0 or later, so the last 0.x version has 24; until its period ends a version is read whichever later version an implementation implements, not only by the version that replaced it; changed only by RFC and never shortened for a published version. Decided with it, as proposed: the periods, over 6 months, until the next version after, or longer for models kept as records of a building; an erratum accepted by an editor and the steward; and the working draft is not "published" at the public launch: 0.1.0 is published when it drops its suffix, and until then the draft changes in place, with the changelog. 22. **Exit criteria for 1.0.** **Decided on 14 October 2026** (`GOVERNANCE.md`, "Reaching 1.0"): for each conformance class 1.0 keeps, two implementations by makers independent of each other, one of them independent of the steward, pass the public conformance suite, and 1.0 waits until the reader, validator and writer classes each have them; the suite is published and tests every requirement of its classes or lists those it cannot; every open question is decided or deferred by a decision to a named version, and every requirement of the classes 1.0 keeps is met by an implementation that passes the suite, or changed by RFC; a release candidate is open for public comment for at least 60 days; the media type is registered with IANA; the specification states its security and privacy considerations; and the rules for errata, deprecation and extensions are in use. Decided with it, as proposed: the numbers (two implementations, 60 days, 30 more after a change), and that another class without two implementations leaves 1.0 rather than holding it back. Still open: whether 1.0 waits for the steering committee (Stage 1). 23. **Ids that fold to one name.** Two ids of one list that differ only in letter case or in Unicode normalisation name one file on many file systems: Part III, 2 escapes the characters and names that file systems refuse or read otherwise (its rules 1 to 6), and writes letters as they are. Should Part I, 6 refuse such a pair, or Part III, 2 escape the two apart? A reader of 0.1 decodes every escape (Part III, 2, rule 7), so a later version may escape more characters, an upper-case letter say, and a 0.1 reader still reads its folders as the same ids. **Decided, 15 October 2026:** refused, not escaped apart. Two records whose paths fold to one, compared name by name by their folds (each name in Normalization Form D, its case folded by the full case folding, and in Normalization Form C), MUST NOT both be in a model, nor two levels whose folders do: a validator reports such a pair as an error, and a writer refuses the model ([Part I, 6, rule 7](https://openeik.org/spec/0.2/foundations#6); the fold: [Part III, 4.3](https://openeik.org/spec/0.2/code-base#4.3)). As a reading of the decision, the fold is that of Unicode 13.0.0, so that every implementation folds a name alike whatever Unicode version its platform has; a review found current platforms that fold U+A7CB differently. 24. **Category names as path names.** A category names a folder (Part III, 4). Should it be escaped as a path segment, or `category` be held to a plain name by the schemas? Until then a writer refuses a category that is not a plain name (Security and privacy, 6.1). **Decided, 15 October 2026:** `category` is held to a plain name by the schemas, not escaped: a lower-case ASCII letter, then ASCII letters and digits, at most 32 characters, and no device name ([Part II, 6.2, rule 1](https://openeik.org/spec/0.2/language#6.2)); a writer refuses a category, or a view's kind, that would give a name that is not plain, which a plain name never does ([Security and privacy, 6.1, rule 1](https://openeik.org/spec/0.2/security-and-privacy#6.1)). 25. **Kept files whose names a file system reads otherwise.** Kept paths are not escaped (Part III, 7, rule 1). Should names that a file system refuses or folds be excluded from kept paths, or escaped? **Decided, 15 October 2026:** excluded, not escaped. A kept path holds no name that a file system refuses or reads otherwise, which Part III, 2 escapes in a name made from an id (its rules 2 to 5), and folds to no other path of the model, `eik.json` and `AGENTS.md` among them: a writer refuses such a kept file, a reader leaves it alone and warns, and a validator reports it, as a warning in a folder and as an error in the single-file form ([Part III, 7, rule 8](https://openeik.org/spec/0.2/code-base#7)). As readings of the decision: a `%` is no such character, since Part VI, 8.1 names an application's folders by its ids' escaped segments, which hold kept files; a reader of versions refuses a version that holds such a kept file, which no folder gives ([Security and privacy, 5.3, rule 2](https://openeik.org/spec/0.2/security-and-privacy#5.3)); and two kept files of a merge's two sides whose paths fold to one are a conflict ([Part VI, 5](https://openeik.org/spec/0.2/history#5)). 26. **The length of an id.** Part I, 6.5 recommends a pattern for minted ids. Must every writer mint ids of one pattern, and how long may an id be, given that a path segment of more than 255 bytes is refused by common file systems? **Decided, 15 October 2026:** an id's path segment, escaped as Part III, 2 says, is at most 200 bytes of UTF-8, and so are a level's and a view's: a validator reports a longer one as an error, and a writer refuses it ([Part I, 6, rule 8](https://openeik.org/spec/0.2/foundations#6)). Whether every writer mints ids by one pattern is deferred to 0.2 (question 6). 27. **Unknown members of `eik.json`.** Part I, 10 has readers keep the members of records they do not know. Must a writer keep the members of `eik.json` it does not know as well? **Decided, 15 October 2026:** yes. A writer keeps the members of `eik.json` it does not know, and writes them back as it read them ([Part III, 8.1](https://openeik.org/spec/0.2/code-base#8.1)); no application adds one (Part I, 11.2, rule 8). 28. **A protocol between stores.** Part VI, 6 says what a push, a pull and a clone do, not how they travel: OpenEik defines no wire protocol (Security and privacy, 1). The store API that `@openeik/tools` speaks is one store's. Should a later version define one? **Deferred to a later version, 15 October 2026:** OpenEik 0.1 says what a fetch, a push, a pull and a clone do, not how they travel between stores ([Part VI, 6](https://openeik.org/spec/0.2/history#6)). 29. **The reader class and the whole-model check.** Does the reader class require the whole-model check of Part III, 12, rule 5, or only the validator class? **Decided, 15 October 2026:** the whole-model check of Part III, 12, rule 5 is required of the validator class, and a reader SHOULD perform it. A reader that performs the check refuses a folder that fails it. A reader that does not perform the check reads the folder as it is. Every reader MUST refuse what it cannot read, the list in Part III, 12; a reader that does not perform the check need refuse nothing else ([Part III, 12](https://openeik.org/spec/0.2/code-base#12); [Conformance, 1](https://openeik.org/spec/0.2/conformance#1)). Units other than millimetres and an up axis other than Z are on that list (Part I, 3, rule 7). 30. **How a version holds an asset.** A version of 0.1 holds JSON text only (Part VI, 1), so the binary files of Part XIV (fonts, PDF renditions, outside drawings, signed containers) reach no version and no store. Should a version hold an asset as a pointer, a leaf of JSON text that names the bytes by their SHA-256 and their length, with the bytes kept beside the version, as Git LFS does; or as a third kind of tree entry that names the bytes themselves? **Decided, 18 October 2026, as Part XV proposed it:** a pointer, with the bytes beside the version ([Part XV, 3](https://openeik.org/spec/0.2/assets#3)). Trees, diffs, merges and a store's objects stay as they are, and a store can let bytes go without breaking a version. 31. **The kinds of asset in 0.2.** Which kinds of file may be an asset? **Decided, 18 October 2026, as Part XV proposed it:** `pdf`, `ttf`, `otf` and `asice`, which Part XIV names, and `png` and `jpg` for the photographs a review attaches; meshes later ([Part XV, 4](https://openeik.org/spec/0.2/assets#4)). 32. **The size of an asset.** How large may one asset be? **Decided, 18 October 2026, as Part XV proposed it:** at most 64 MiB, as an issued drawing; a host may set a lower limit and a quota for a building ([Part XV, 4](https://openeik.org/spec/0.2/assets#4)). 33. **Fetching bytes later.** May a fetch leave the bytes of assets behind, as a clone with Git LFS may, and fetch them when they are read? **Decided, 18 October 2026, as Part XV proposed it:** yes; a pull or a clone into a folder fetches the bytes of every asset of the version it writes ([Part XV, 6](https://openeik.org/spec/0.2/assets#6)). 34. **Withholding an asset.** May a store let go of an asset's bytes, and keep every pointer to it, when the asset has to go: personal data a person asks to have erased, a licence that has ended, an order? **Decided, 18 October 2026, as Part XV proposed it:** yes. A version that names a withheld asset stays readable, and readers report the asset as withheld ([Part XV, 7](https://openeik.org/spec/0.2/assets#7)). 35. **Unused assets.** Who may remove an asset that nothing in the model names? **Decided, 18 October 2026, as Part XV proposed it:** any writer; the versions before keep it ([Part XV, 2 and 8](https://openeik.org/spec/0.2/assets#8)). 36. **Where ownership is kept.** On a project with several firms, each owns the folders of its discipline (Part VI, 7, planned). Should ownership be stated in the model, in a file that travels and is versioned with it, or kept by each host? **Decided, 18 October 2026, as Part XVI proposed it:** in the model, `project/owners.json` ([Part XVI, 2](https://openeik.org/spec/0.2/ownership#2)). 37. **Who an owner is.** Should an owner be a party named in the file, a firm or a team whose accounts a host knows, or a person of Part XIV's registry? **Decided, 18 October 2026, as Part XVI proposed it:** a party named in the file ([Part XVI, 2](https://openeik.org/spec/0.2/ownership#2)). 38. **How ownership rules match.** How does a rule name the paths it covers, and which rule decides where several match? **Decided, 18 October 2026, as Part XVI proposed it:** globs over a version's leaf paths, `*` for part of a segment and `**` for whole segments; the last matching rule decides ([Part XVI, 3](https://openeik.org/spec/0.2/ownership#3)). 39. **What ownership asks for.** What approval does a change to an owned path need, and who holds it to that? **Decided, 18 October 2026, as Part XVI proposed it:** one owner's approval, or every owner's where a rule says `all`; a host SHOULD hold a change to the main line until then, and a tool SHOULD say which parties a change needs ([Part XVI, 4](https://openeik.org/spec/0.2/ownership#4)). 40. **Who approves a change to the datums.** The project record, the levels and the grids are every discipline's. Should the standard give them to every party? **Decided, 18 October 2026, as Part XVI proposed it:** the file says it, as for every path; the example of Part XVI and the guide *Working across disciplines* give them to every party, with `all` ([Part XVI, 2](https://openeik.org/spec/0.2/ownership#2)). 41. **A material's density.** Part II, 4.1 gives a material its density ρ. Is that the material's own density, as building physics reads it, or a structural unit weight that includes what the material carries as built, such as the reinforcement in concrete? **Decided, 22 October 2026** (the steward's decision, asked by an analysis application): the material's own density. A structural tool takes the self-weight of a material it recognises from its own source, such as EN 1991-1-1, annex A, and uses ρ times g only for one it does not, saying so ([Part II, 4.1](https://openeik.org/spec/0.2/language#4.1)). 42. **Two grades.** A type with a section states a grade in its section's `grade`, and its material may state one in its `strengthClass`. Which is the members' grade where they differ? **Decided, 22 October 2026** (the steward's decision, asked by an analysis application): the section's `grade`, where it is not empty, as the reference implementation's parts list takes it (`partGrade`). A reader MUST take it, and a validator MAY warn that the two differ ([Part II, 5.2](https://openeik.org/spec/0.2/language#5.2), rule 6). 43. **Where an analysis model puts a trimmed edge.** An outline edge trimmed to a wall's face (Part II, 6.7) stops at the face, and the slab's bodies with it. Where does an analysis model, which joins plates at their mid-planes, put that edge? **Decided, 22 October 2026** (the steward's decision, asked by an analysis application), as an informative note: on the line where the tool places the wall's plate, the wall's baseline unless it places it at the middle of its core layers; the slab's quantities stay those of the trimmed outline ([Part IV, 4.5](https://openeik.org/spec/0.2/compiler#4.5)). `@openeik/tools` gives the trimmed outline without compiling (`trimmedOutlineOf`, `edgeTrims`, `trimHost`), so that readers trim as the validator and the compiler do. 44. **True north without a location.** A project's `site` gives latitude, longitude, true north and a time zone together, as the reference implementation's schema requires them. A tool that knows which way north is, from a drawing say, but not where the site lies, cannot give it. **Decided for 0.2, 22 October 2026** (the steward's decision, asked by an analysis application): `trueNorth` may be given alone; latitude, longitude and the time zone stay together, as the site's location. The reference implementation changes first. In 0.1 a `site` gives all four ([Part II, 2](https://openeik.org/spec/0.2/language#2)). **Written, 29 October 2026:** [Part II, 2.2](https://openeik.org/spec/0.2/language#2.2), proposed for 0.2 behind the proposal `site`, rules 1 and 2: a site is `{trueNorth}`, or all four, its location given whole or not at all; a site without a location places no plan on a map, and a tool that needs the location says so. `schemas/proposed/site/site.schema.json` holds a project's site in place of 0.1's, and `@openeik/tools` applies it with the proposal. The reference implementation's schema still asks for all four (`siteSchema`). 45. **A pipe's insulation code.** The reference implementation gives a pipe type's insulation by the parts of one national code (`pipe.bti`: a class, a hanging, a material, a thickness and a surface, which a Swedish drawing writes as `R5DF40-C`), and a duct type's by one code of a project's table (`duct.insulationCode`). Should a pipe's insulation be the parts of a national code, a member named after it, or one code, as a duct's is? Raised 23 October 2026 by the draft of heating, ventilation and plumbing. **Decided, 24 October 2026,** as the draft proposed: one code and a thickness on every run type, `pipe.insulationCode` and `pipe.insulation` as a duct type's `duct.insulationCode` and `duct.insulation`, and a run's own `mep.insulation.code` and `mep.insulation.thickness`; the code is a national value. `bti` stays readable in 0.1, deprecated, since the reference implementation writes it: a reader takes its thickness and its parts written together as the code, and a writer writes the code and the thickness ([Part II, 6.9](https://openeik.org/spec/0.2/language#6.9), rule 4). The reference implementation changes next (section 2, row 27). 46. **A duct's insulation thickness.** A duct's code takes a thickness from its project's table, or from the reference implementation's own, which no model holds: a reader cannot draw a duct as thick as the reference does. Where is the thickness a body takes? Raised 23 October 2026 by the same draft. **Decided, 24 October 2026,** as the draft proposed: in the model, the type's `duct.insulation` and a run's own `thickness` beside its own `code`, never only a code table's; what a code means stays the project's legend, an application value ([Part II, 6.9](https://openeik.org/spec/0.2/language#6.9); [Part IV, 12.1](https://openeik.org/spec/0.2/compiler#12.1), rule 3; section 2, row 28). 47. **A heating system's temperatures.** A terminal's flow is derived from its power and a design difference, which the reference implementation takes from its heating system's supply and return temperatures, kept in the project's `standards`, an application value. Are they model data? Raised 23 October 2026 by the same draft. **Decided, 24 October 2026,** as the draft proposed: not in 0.1 or 0.2. A system's record, with its number, its temperatures and the schematic made from it, may come in a later proposal; a terminal's own `deltaT` is the model's ([Part II, 6.9](https://openeik.org/spec/0.2/language#6.9)). 48. **The plan's automatic tags.** The tags a plan draws of its pipes, ducts and terminals, what a view does to each (`display.mepTags`, `mepTagEdits`, with a lined-up tag's `elbow`), a hand tag's field `mep`, and the white ground of tags and texts (`textBackground`), which the reference implementation wrote before plan 606, were not in 0.1. Do they join the standard with frames and lined-up tags, which rest on them? Raised 23 October 2026 by the same draft. **Decided, 24 October 2026:** yes, in 0.1, as data of the documentation profile ([Part II, 13.2 and 13.3](https://openeik.org/spec/0.2/language#13)). Lining up tags stays drawing behaviour, and adds no member. 49. **A tag template's language.** A template's rows hold fields in the reference implementation's own language, with national marks for heights. Is the language the application's, or a vocabulary of the standard? Raised 23 October 2026 by the same draft. **Decided, 24 October 2026,** as the draft proposed: the application's, the rows application values ([Part II, 13.3](https://openeik.org/spec/0.2/language#13.3)); a neutral vocabulary of fields when a second application asks for one. 50. **A project's own symbols.** A symbol names a symbol of the application's library ([Part II, 13.5](https://openeik.org/spec/0.2/language#13.5)). May a project keep a library of its own in the model, so that another application draws its symbols? Raised 23 October 2026 by the same draft. **Decided, 24 October 2026,** as the draft proposed: later, as detail families (Part II, 1) with ports; no member in 0.1. 51. **Components on a duct.** A silencer, a fan or a fire damper on a duct is a terminal mounted on a duct, placed on it once, as before; it does not follow its duct. Should it be hosted as a component in a pipe is? Raised 23 October 2026 by the same draft. **Decided, 24 October 2026:** yes, once the reference implementation builds it: hosted on its duct at a distance along it, as a component in a pipe is ([Part II, 6.9](https://openeik.org/spec/0.2/language#6.9)). **Built, 24 October 2026:** the reference implementation hosts them since Stomra 676 (live since 24 October 2026, `main` `f02ba07e`), and Part II, 6.9 says so: a terminal whose type mounts on a duct names its duct in `hostId`, at `along`, and stands where the duct puts it; the kinds `damper`, `smokeDamper` and `flowRegulator` join `silencer`, `ductFan` and `fireDamper`; across the duct it is the larger of its type's size and the duct's outer size with 10 mm each side, which a writer writes as its `width` and `height`; and Part VIII, 1.1 gives each kind's IFC class. A duct part placed before 676 names no duct, and stays valid where it was put. Part IV, 12.6 builds the body. 52. **A party's discipline and its organisation.** Part XVI names a party by an id and a name. May a party say which discipline it works in, so that an application can offer it its discipline's records, and which organisation it is, so that a host can find the accounts that act for it? Anyone who may change the owners file can write any organisation into it: how does that not give an organisation rights? Raised 24 and 25 October 2026 by the reference implementation's sharing by discipline and by a host. **Decided, 25 October 2026, as proposed:** a party MAY give a `discipline`, one of eight plain values, and an `organisation`, its name and an Internet domain of its own, the domain saying which organisation it is. Neither decides anything alone: a party owns the paths its rules give it. A host links a party to an organisation's accounts only when the organisation has proved the domain to it, and the building is already shared with the organisation or an administrator of the organisation accepts; the building's administrators may undo the link ([Part XVI, 2](https://openeik.org/spec/0.2/ownership#2) and [7](https://openeik.org/spec/0.2/ownership#7)). 53. **The form of an error code.** The plan proposed refusals' codes such as `EIK-WALL-012`: a namespace, a domain and a number. The validator of `@openeik/tools` names its findings with lowercase, hyphenated codes (`opening-fit`), which the conformance suite's cases name, and which the specification does not define. Which form do refusals take, and do the validator's codes become the standard's with them? **Decided, 25 October 2026, as Part XVII proposed it:** the validator's form, so that one rule has one code whether a command is refused for it or a folder reported; the rule beside each code (`V.3.1`); a processor's own codes under its prefix; and the validator's codes the standard's in 0.2 ([Part XVII, 10.1 and 10.5](https://openeik.org/spec/0.2/envelope#10.1)). 54. **A moved base.** An envelope names the version its commands were made from. Where the ref has moved on since, should the processor refuse the operation, as a strict compare-and-swap would, or apply it to the newest version, each command's precondition deciding? **Decided, 25 October 2026, as Part XVII proposed it:** apply it to the newest version, the preconditions deciding, and say so in the answer; refuse it (`base-moved`) only where the envelope asks for its base exactly (`exact: true`). Every command in an envelope has a precondition, so a record changed since is refused either way, and a strict compare would only send the writer round again ([Part XVII, 5](https://openeik.org/spec/0.2/envelope#5)). 55. **The agent in the history.** A version names its `author`, and a proposal file its `by.person` and `by.app`; neither names an agent. Should a version's commit object gain `agents`, and a proposal file's `by` gain `agent`, in 0.2? **Decided, 25 October 2026, as Part XVII proposed it:** yes, both optional: a version lists each agent whose operations it holds, by name and version, and a proposal file names the agent as the envelope does. Until then a host names the agent in a version's `note` ([Part XVII, 4.3](https://openeik.org/spec/0.2/envelope#4.3)). 56. **A base by sequence.** The reference implementation's cloud projects keep a change sequence, not versions, and move it by compare-and-swap. Should an envelope's target take the sequence its writer read as its base, beside a version? **Decided, 25 October 2026, as Part XVII proposed it:** not in 0.2's first draft: the base is a version, or `null`; a host that keeps a sequence compares nothing more than the commands' preconditions, which every command in an envelope gives. A `sequence` in the target can come when a second host asks for it ([Part XVII, 5](https://openeik.org/spec/0.2/envelope#5)). 57. **How long an operation is recorded.** A processor that keeps a log answers an operation sent again from its record. How long must it keep the record? **Decided, 25 October 2026, as Part XVII proposed it:** at least 24 hours after the operation, and as long as it keeps the change's log entry where it can ([Part XVII, 3](https://openeik.org/spec/0.2/envelope#3)). 58. **A person by id only.** An envelope names its person by an id. A result manifest's `made.by` and a proposal file's `by.person` may hold an email address in 0.1 (Part VI, 8.2 and 8.7). Should an envelope refuse one? **Decided, 25 October 2026, as Part XVII proposed it:** yes: `by.person` is an id the processor knows the person by, never an email address, since operations are recorded and versions kept by everyone who has them; the files of Part VI keep what 0.1 allows ([Part XVII, 4.1](https://openeik.org/spec/0.2/envelope#4.1)). 59. **Envelopes for agents.** A batch without an envelope stays valid. Should an agent host have to take envelopes in 0.2, and should agents have to send them? **Decided, 25 October 2026, as Part XVII proposed it:** an agent host that implements Part XVII MUST take them, and SHOULD require them of agents, so that every agent's write is attributed and can be sent again safely; a person's application may go on sending bare batches ([Part XVII, 8](https://openeik.org/spec/0.2/envelope#8)). 60. **An envelope's unknown members.** A record keeps a member it does not know (Part I, 10), and Part V, 1.4 lets a processor warn about one at a command's top level rather than refuse it. Should an envelope's be refused? **Decided, 25 October 2026, as Part XVII proposed it:** refused, extension members aside: an envelope is not stored, and a misspelt member of it, such as `operationID` or `exacts`, changes what happens to every command in it, which a warning after the fact would not undo ([Part XVII, 2](https://openeik.org/spec/0.2/envelope#2)). 61. **Markup shapes.** Part XIV, 13.2 gives a review item one of six kinds, which say what it means, and a shape of points in paper mm. A markup drawn as a pen stroke, a polyline, a polygon, a rectangle or an ellipse keeps its meaning, and loses its form: the reference implementation's markups would come back as polylines. A text box's frame has no member, since only a cloud, an arrow, a highlight and a measure have a shape. Should the shape say how it is drawn, and how are colour and line weight kept? Raised 25 October 2026 by plan 688. **Decided, 26 October 2026, as Part XVIII proposed it:** the six kinds stay, since they are about meaning; a shape MAY give a `form`, `freehand`, `polyline`, `polygon`, `rectangle` or `ellipse`, a rectangle or an ellipse given by the four corners of its rectangle in order, turned as it lies, so that a reader that does not know `form` still draws a rectangle, and an ellipse as the rectangle that holds it; a text and a comment MAY have a shape, the frame of their words; colour, line weight and other style are an application's extension members (Part I, 11.2). A callout's box, a cloud's note box and a pen's several strokes wait for a second application to ask for them ([Part XIV, 13.2](https://openeik.org/spec/0.2/drawings#13.2) and 13.4, rule 9; [Part XVIII, 2.2](https://openeik.org/spec/0.2/review#2.2)). 62. **Where a model's review lives.** A review round of Part XIV is on one revision of a drawing. Plan 688 asks for a round on the model itself: items on elements at a version, each seen from a 3D viewpoint. Should it be in Part XIV, in Part VI, or in a part of its own? Raised 25 October 2026 by plan 688. **Decided, 26 October 2026, as Part XVIII proposed it:** in a part of its own, Part XVIII, with its own proposal, `review`, which builds on Part XIV's registry, profile, issues and statements and turns on the proposal `drawings` with it. A model's review is not a drawing's, and an application that never issues a drawing (an analysis, an energy tool, a host) can then implement it without the SVG profile and freshness; the issue's statements, the receipts and terms accepted, which drawings and versions share and contracts will rest on, are one text for a lawyer to read. Part VI, which is 0.1's and normative, is no place for a proposal ([Part XVIII, 1 and 2](https://openeik.org/spec/0.2/review#2)). 63. **How a version is issued.** An issue of Part XIV releases revisions. Should a version of the model be released by the same issue file, with `versions` beside `revisions`, or by a file of its own? Raised 25 October 2026 by plan 688. **Decided, 26 October 2026, as Part XVIII proposed it:** by the same file, `drawings/issues/.json`, which gains `versions` (each by its root tree hash), `renditions` (the prints sent with it, by their digests, and kept nowhere) and `terms`, and releases revisions, versions or both: one act of sending is one record, as a transmittal that sends drawings and the model they came from together is one, and one statement and one receipt cover it. Its folder keeps the name `drawings/`, which 0.2 may revisit when Part XIV's text moves into Parts II and III ([Part XVIII, 3](https://openeik.org/spec/0.2/review#3)). 64. **What an issue's statement signs.** A sign-off's statement names the drawing's two files as its subjects (Part XIV, 14.1). Should a statement about an issue name the issue record alone, or every revision's files and every version too? Raised 25 October 2026 by plan 688 and a host's answers on receipts. **Decided, 26 October 2026, as Part XVIII proposed it:** the issue record alone, by its path and its hash: it names each revision by its record's hash, which names its SVG, each version by its root and each print by its digest, so its hash covers them all, and the statement of an issue of five hundred drawings is as small as that of one. The statement keeps Part XIV, 14's envelope, keys, time-stamps and verifier, with its own predicate type, `https://openeik.org/attestation/issue/v0.1`, and the actions `issued`, `received` and `withdrawn` ([Part XVIII, 4](https://openeik.org/spec/0.2/review#4)). 65. **How a host's receipt is checked.** A host knows when an issue was sent, delivered, opened, viewed, downloaded, withdrawn and superseded for each recipient. It can sign a receipt of them, as it signs other records. How does a verifier know the host's key, offline? Raised 25 October 2026 by a host's answers on receipts. **Decided, 26 October 2026, as Part XVIII proposed it:** a receipt is a statement in Part XIV, 14's envelope, of the predicate type `https://openeik.org/attestation/issue-receipt/v0.1`, signed with a key the host publishes and time-stamped; a verifier is given the host's keys, with their windows of validity, as trust anchors, as it is given a time-stamp authority's certificate. The building names no host and holds no host's URL (Part XIV, 7.2), so the host's key is not a record of its registry. A host's receipt is the host's word: a recipient MAY sign `received` with their own key, which is what a contract that rests on receipt SHOULD ask for. The events and how long a link lives stay the host's ([Part XVIII, 5](https://openeik.org/spec/0.2/review#5)). 66. **Terms accepted.** A host may ask a recipient to accept terms of use before an issue opens. Nothing records it in the building. Should the standard define a record of it, and who signs it? Raised 25 October 2026 by plan 688, as a gap before contracts rest on review. **Decided, 26 October 2026, as Part XVIII proposed it:** a statement at `project/terms-accepted/.json`, of the predicate type `https://openeik.org/attestation/terms-accepted/v0.1`: a person of the registry accepted terms named by the SHA-256 of their text, with their title and version, for the building (by its project's id) or for an issue; signed by the person with their own key, or attested by the host with a key it publishes where the person accepted on the host after signing in. It is personal data, kept in every version that holds it; whether it binds is the law's ([Part XVIII, 6](https://openeik.org/spec/0.2/review#6)). 67. **A profile without fonts.** A model's review takes its states and decisions from the drawing profile, `drawings/profile.json` (Part XIV, 4), which requires a font set. A building that reviews its model and issues no drawing has no font to declare. Should a font set be required only where there is an issued drawing? Raised 25 October 2026 by plan 688. **Decided, 26 October 2026, as Part XVIII proposed it:** yes: one profile serves drawings and the model alike, so that both have one set of states, and `fonts` is required where the folder holds a linked issued drawing ([Part XIV, 4.1 and 4.3](https://openeik.org/spec/0.2/drawings#4.3), rule 5). 68. **Recipients a host adds.** The authoring tool writes an issue record once, when it issues, and a host never writes the building. A host then sends that issue as one or more transmittals, often days later, to people the record never named (a consultant forwards it to a subcontractor), and prints on demand, the same bytes each time, prints the record does not list. Must a receipt, an event and a `received` statement name only what the record names? Raised 25 October 2026 by a host's review of Part XVIII. **Decided, 26 October 2026, as Part XVIII proposed it:** no. A receipt's recipient is one the issue names, or one the host sent the issue to; for the second, the receipt is the building's only record of that sending, and gives `sentBy`, the person of the registry who sent it on the host, and `transmittal`, the host's own id for the sending, the one id of a host's that a file of Part XVIII holds. An event's digest may name a print the issue does not list, where the event gives `of`, the revision or the version of the issue it was printed from: since a print is the same bytes each time, anyone can print it again and compare. And `received` may be signed by a recipient the issue names, or by a person a receipt of the issue names as its recipient; a recipient outside the registry signs nothing ([Part XVIII, 4.3](https://openeik.org/spec/0.2/review#4.3), rule 4, and [5.3](https://openeik.org/spec/0.2/review#5.3), rules 3 and 5). 69. **A luminaire's light output.** Part XIII gives a luminaire's type its `power`, and says nothing of the light it gives. An application that shows a room lit, an agent that switches lights on and off, or a lighting check cannot tell a 5 W downlight from a 50 W pendant's light. Should a luminaire's type say how much light it gives, and how? Raised 26 October 2026 by the reference implementation's work 700, lights on in its walk. **Decided, 26 October 2026, as proposed:** four optional members of a type's `electrical`, only on the kinds `light`, `spot`, `emergencyLight` and `track`: `luminousFlux` (lm, the whole luminaire's), `colorTemperature` (K), `beamAngle` (degrees) and `distribution` (`down`, `up`, `downUp` or `allRound`). A reader may estimate a missing flux from `power`, and says so. A bridge writes them in a property set `OpenEik_Light`; a light source with its photometric data waits for photometric files as assets ([Part XIII, 2.2, 2.3 and 10](https://openeik.org/spec/0.2/electrical#2.2)). Which lights are on is a view's setting, the application's, and not proposed. 70. **A view's lighting.** Question 69 gave a luminaire's type the light it gives, and left which luminaires are on to the application. An agent that switches lights for a person walking a model, a client shown a building at dusk, and a walk exported from one application and opened in another all need to know which luminaires are on, and how far each is dimmed, as the view was saved. Where does that state live, and how is it switched, without making every switch a change to the building? Raised 26 October 2026 by the reference implementation's work 700, lights on in its walk; the steward asked the same day that it go into the standard. **Decided, 26 October 2026, as proposed:** a lighting scene on a 3D view, beside its sun: `display.lighting`, `{on: "all" | [id, …], dim?: {: 1 to 99}}`. A view without it has every luminaire off; `"all"` is every luminaire, those added later among them; a luminaire on and not in `dim` is at full, and 100 is never stored. Elements are never touched, so switching changes the view and not the building, and several 3D views give several scenes. Its rules: only on a 3D view; `on` names luminaires, and an id that names no element is a warning, since a luminaire may be deleted after; every key of `dim` is on. A command, `view.lighting`, turns luminaires on, off, to a level, or on alone, selected by id, room, switch, circuit, level, kind or all, and writes the view whole; deleting a luminaire takes it out of every scene ([Part XIII, 4.3 and 9](https://openeik.org/spec/0.2/electrical#4.3)). 71. **A door's and a window's own body.** Part IV, 4.3 cuts a door's or a window's opening out of its wall, a class-A rule, and leaves the opening's own body, its frame, leaves and glass, to reference behaviour. Its type's `openingFamily` or `windowFamily` (Part II, 5) gives the sizes of each part, and the element's `flipped` and `handFlipped` turn it and mirror it (Part II, 6.5), but no rule says where the parts stand, which way a leaf opens, or how a sliding door's leaves run. So the IFC bridge of `@openeik/tools` writes a door or a window as the box of its opening through its wall, and its fidelity report calls that approximated. People read door schedules from IFC: one leaf or two, swinging or sliding, to the left or to the right. Which parts become rules, and is the operation, how a leaf moves, one of them? Raised 26 October 2026 by the IFC bridge of `@openeik/tools` (Part VIII, 1, its notes), so that the reference implementation can print its clients' IFC with it. The reference implementation builds the body from the element, its type and its host wall alone, in about 1300 lines. Across the wall, the frame's exterior face lies `wallOffset` inside the wall's exterior face, and the frame is `frameDepth` deep, or as deep as the wall where `frameFollowsWall`; its members are `frameWidth` wide. A window's lights are a grid of `lightsX` by `lightsY`, with mullions `mullionWidth` wide, or where `mullions` puts them. A fixed light's glass, `glassThickness` thick, stands in the middle of the frame's depth; an opening light has a sash `sashWidth` wide and `sashDepth` deep, 12 mm inside the frame's exterior face, with its glass in its middle. A door has `lightsX` leaves, each `leafThickness` thick, in the middle of the frame's depth. A leaf hinges at the end of its opening nearer its wall's first point where `hinge` is `left`, and at the other end where it is `right`, `handFlipped` swapping the two; of several leaves, the first half hinge at the first end and the rest at the other. A leaf opens to the wall's exterior where `swing` is `outward`, and to its interior where it is `inward`, `flipped` swapping the two. With `operation: slide`, a single leaf runs on the face of the wall on the side it opens to, and travels its width towards its hinge side; several leaves run on two tracks 6 mm apart, every second one sliding over the one beside it. With `pocket`, a leaf slides into the wall on its hinge side. The rest is its product's: clearances of 3 mm, a threshold 25 mm high, a handle, glazing bars, casings, flashings, an inner sill, and the panels and tracks of garage doors. A `windowFamily` gives a frame centred on the wall's axis and a grid of panes; its `family` is a label only. The element's `open`, from 0 to 1, a member that the element schema allows and this text does not describe, turns or slides each leaf that far, up to `maxOpenAngle`, in its 3D view and in its IFC. Its IFC gives an IfcDoor the operation type SLIDING_TO_LEFT or SLIDING_TO_RIGHT where it slides, and NOTDEFINED otherwise, and an IfcWindow the partitioning NOTDEFINED. Reference: `openingSolids`, `shapedOpeningSolids`, `familyInWall` and `openingState` in `src/core/elements/openings.ts`; `lightSpans` in `src/core/elements/mullions.ts`; `slidingLeaves` and `slideSide` in `src/core/elements/slidingDoors.ts`; `windowSolids` in `src/core/geometry/familyGeometry.ts`; `doorOperation` in `src/core/io/ifcExport.ts`. The choice: the body stays reference behaviour, and every bridge writes a stand-in of its own; the parts that a clash check and a schedule read, the frame, the leaves or sashes and the glass, become class-A rules with the operation, and the product's details stay reference behaviour; or the reference's whole body becomes the rule, details and all. **Decided, 26 October 2026, as proposed:** the second, in two steps. Into 0.1, the operation, which every record holds already: the hinge, the side a leaf opens to, and how it moves (`operation`: it swings, slides along the wall's face, or slides into a pocket), as the reference reads them above, stated in Part II, 6.5; and, in Part VIII, 1, the IFC4 operation type each gives a door (IfcDoorTypeOperationEnum, left and right as IFC4 sees them, looking the way the leaf opens) and the partitioning a window's grid gives it (IfcWindowTypePartitioningEnum). For 0.2, a class-A rule in Part IV, 4.3 for the frame, the leaves or sashes in their grid, and the glass, from the sizes above, a `windowFamily`'s frame and panes included. The other details stay reference behaviour (class C). A body for a print, a clash check or a quantity is drawn closed: `open` is a pose for showing, which Part II, 6.5 then describes, and the reference implementation then prints its doors closed. With both steps, `ifcOfModel` writes a door's and a window's frame, leaves and glass, and its operation type, by rule, and no longer calls them approximated ([Part IV, 4.3](https://openeik.org/spec/0.2/compiler#4.3); [Part II, 6.5](https://openeik.org/spec/0.2/language#6.5); [Part VIII, 1](https://openeik.org/spec/0.2/bridges#1)). **Written, 26 October 2026:** the operation, into 0.1. [Part II, 6.5](https://openeik.org/spec/0.2/language#6.5), rules 1 to 6: the hinge side, `left` the opening's start and `right` its end, `handFlipped` swapping them; the side it opens to, `outward` the wall's exterior, `flipped` swapping it; several leaves hinged half at each end; `slide` along the wall's face or past the other leaves on two tracks 6 mm apart, and `pocket` into the wall, towards the hinge side; no operation where `operable` is `false`; a door that hinges at its top or bottom, and `slide` or `pocket` on a window, warned of. [Part VIII, 1.2](https://openeik.org/spec/0.2/bridges#1.2): IfcDoorTypeOperationEnum, left and right looking the way the leaf opens, and IfcWindowTypePartitioningEnum from the grid of lights. `@openeik/tools` checks rule 6 and writes the mapping; with it, its bridge's sliding doors that open to their wall's interior turned to the other side. The frame, leaves and glass stay for 0.2. **Written, 28 October 2026:** the frame, the leaves or sashes and the glass, proposed for 0.2. [Part IV, 4.3.1](https://openeik.org/spec/0.2/compiler#4.3.1), rules 1 to 13, behind the proposal `frames`: the frame from the wall's exterior face, inset by the gap, without a sill on a door; a window's lights in their grid or between given mullions, a fixed light's glass in the frame's middle and an opening light's sash 12 mm behind its face; a door's leaves side by side, glazed in rows where its `glazing` says, a sliding door's on two tracks 6 mm apart or on its wall's face; a garage door closed by one leaf; a shaped opening's frame along its outline, mitred; a `windowFamily`'s frame and panes; all drawn closed. The product's details stay reference behaviour (rule 12). `@openeik/tools` derives them with the proposal (`compileModel` and `ifcOfModel`, `frameParts` in `compile-frames.js`), warns of a family that leaves no room (`frames-fit`), and matches the reference implementation's own bodies on a probe of every kind of family (`test/fixtures/frames-bodies.json`), exactly but for a leaf's clearances. **Decided, 28 October 2026,** by the steward ("a"), asked when the frame was written: a shaped opening's outline is mirrored along its wall where its `handFlipped` is `true`, in its wall's cut ([Part IV, 4.3](https://openeik.org/spec/0.2/compiler#4.3), in 0.1) and so in its frame (4.3.1, rule 11, proposed), as the reference implementation places it since its work 202 and as `@openeik/tools`' validator placed it already when it checked an opening's fit and overlaps (Part II, 6.1, rule 5). Part IV, 4.3 placed the outline as recorded, so that a flipped hand mirrored a shaped door's hinges and not its shape. An outline that is its own mirror across the middle of its `width` cuts as before. **Revised, 27 October 2026,** by the steward ("reword 1.2"): [Part VIII, 1.2](https://openeik.org/spec/0.2/bridges#1.2) has a typed door's operation and a typed window's partitioning written on its IFC type only, its occurrence's left unset, as buildingSMART's normative rules BLT001 and BLT002 require, and on the door or window itself where it has no type; doors or windows of one type that differ get an IFC type for each way. Before, it had a bridge write both. 72. **A room placed by a point.** A room's profile is one point, its boundary found from the walls round it, or an outline drawn by hand (Part II, 6.1, rule 4). Part IV, 2 makes room boundaries a class-B rule, reference behaviour, and no rule gives a room's ceiling; Part II, 6.2 calls the element's `height` its room height, and the project's `rooms` (Part II, 2) holds rules for measuring rooms. So the IFC bridge of `@openeik/tools` writes an IfcSpace only for a room drawn by hand, up to a level ceiling, and leaves out the net perimeter and the wall areas that rest on its walls. Most rooms of the reference implementation's models are placed by a point, so a print of them holds few spaces. Should a room's boundary found from its point, its holes, its height to the ceiling and the quantities that rest on its walls become rules? Raised 26 October 2026 by the same bridge. The reference implementation finds the boundary from the records alone, through its whole body kernel. On the room's own level, every wall and column bounds rooms unless its `roomBounding` is `false`, and a wall whose `offset` is 1900 mm or more bounds none unless its `roomBounding` is `true`. Each is taken as the convex hull, in plan, of its bodies as built, all its layers and its joins included, so that a door's opening never joins two rooms. A straight wall's ends are lengthened by 15 mm, so that a joint up to 30 mm wide closes. A room separator is a strip 0.2 mm wide that runs 1 mm past each end, and a roof whose underside comes down to the floor bounds rooms too. The boundary is the face of the plan these leave that holds the room's point; its holes are the pieces that stand free inside it; a face of less than 100 mm² is none. A room in no closed face has no boundary. Where two rooms lie in one face, the first in the list of elements keeps it and the other has none, which gives the order of elements a meaning that Part III, 9, rule 3 forbids. A shaft is no hole. The ceiling is `room.height` over the room's base where it is given; else the lowest underside, more than 100 mm above the floor, of the slabs and ceilings over the room's point and of the roofs over any of it, a pitched roof's planes giving a sloped ceiling; else the next level at least 1800 mm up; else 2500 mm above the floor. The element's `height` is not read. From the boundary come the net floor area, the perimeter, the length along walls and columns less the doors in them (`rooms.doorsFromSkirting`), each wall edge's area up to the ceiling over it, less the doors and windows on it whose area is at least `rooms.openingMinArea`, the ceiling's area and the volume. Its IFC writes them as Qto_SpaceBaseQuantities, and the space's body as the room's volume under its ceiling. Reference: `roomsOf`, `roomBodies`, `traceUnion` and `enclosedRegions` in `src/core/elements/rooms.ts`; `ceilingPlanes`, `roomEdges`, `roomQuantities` and `roomVolume` in `src/core/elements/roomQuantities.ts`; `spaceTriangles` in `src/core/io/ifcSpaces.ts`. The choice: rooms stay class B, and a bridge writes spaces only for rooms drawn by hand; a writer stores the boundary it found, either in the record, which Part II, 10 forbids for derived data, or in the derived layer (Part IV, 1.1), which no version holds, so that a host printing a version cannot use it; or the reference's search becomes a class-A rule, stated on class-A bodies so that it needs no joins. **Decided, 26 October 2026, as proposed:** the third, for 0.2, in Part IV: - **The boundary.** On the room's level, the walls and columns that bound rooms, chosen as the reference chooses them, each as the convex hull in plan of its body before openings and joins (sections 4.1 and 6.1), a wall's lengthened by 15 mm at each end; and each room separator, as a line. The room's boundary is the face of the plan they leave that holds its point; its holes are the hulls inside it that touch none of those round it. Where walls meet at their ends or at a tee, a join changes no face that faces a room, so the rule should give the reference's boundary there; conformance cases from the reference's own rooms check it before the text is written. Where two rooms lie in one face, the room whose id comes first in code-unit order keeps it, and a validator warns. A roof that comes down through the floor, a loft's, bounds rooms in a later version; until then such a room is drawn by hand. - **The ceiling,** as the reference finds it, but for its last fallback: the element's `height`, which Part II, 6.2 already calls the room height, in place of 2500 mm, the height the reference writes into a new room's `height`. - **The quantities** above, under IFC's names, with what the project's `rooms` says. National area rules stay the application's (Part II, 8). With it, `ifcOfModel` writes an IfcSpace for every room that has a boundary, with its net perimeter and its wall areas, and no longer calls a ceiling approximated ([Part IV, 2](https://openeik.org/spec/0.2/compiler#2) and [7.2](https://openeik.org/spec/0.2/compiler#7.2); [Part II, 6.1](https://openeik.org/spec/0.2/language#6.1), rule 4). **Written, 29 October 2026:** proposed for 0.2. [Part IV, 7.5](https://openeik.org/spec/0.2/compiler#7.5), rules 1 to 7, behind the proposal `rooms`. What bounds rooms: each wall as the hull of its layers as its joins end them, by the corners and tees of Part IV, 7.4.2, its ends 15 mm further out; each column as the hull of its section; each room separator as a line 1 mm longer at each end; and the parts of a roof's faces whose underside comes down through the floor, with the floor's edges then as lines. The faces of the plan, more than 100 mm² each, and their holes. The face that holds a room's point, or the point moved 1 mm along +x, −x, +y or −y in turn, kept by the room whose id comes first; a validator warns of a room with no face (`rooms-enclosed`) and of a room in another's face (`rooms-shared`). The ceiling: the room's own height; else the undersides more than 100 mm over the floor of the slabs and ceilings over its point and of the roofs over it, each roof's only over its extent; else the next level 1800 mm or more up; else the element's `height`, which is also the ceiling beyond the roofs where only roofs are over it. A barrel vault is no ceiling by rule. The eight quantities of IFC4's `Qto_SpaceBaseQuantities`, and the volume, a prism for each part under one set of the ceiling's planes. `@openeik/tools` finds them with the proposal (`compileModel`, its result's `rooms`; `compile-rooms.js`), writes an IfcSpace for every room with a boundary and a ceiling, its body its volume, with all eight base quantities, and warns of the two. The decision assumed that a join changes no face that faces a room, and asked that cases from the reference implementation's own rooms check it before the text was written. They showed that it does: a wall's plan before joins left seven of the 25 rooms of its one example with rooms otherwise than the reference's. Where a room wraps round the outer corner of two walls, the reference's mitred corner, lengthened by 15 mm, leaves two slivers in the room. Where a wall butts another, its joined end runs on through the other wall. And where two walls stop 29 mm short of each other at a corner, the join closes the corner, and the plans before joins left the two rooms on either side one face. Part IV, 7.4.2, written by then for a framed layer's ends (open question 83), states the reference's corners and tees exactly, so rule 1 takes each wall's plan as those joins end it, and the room boundaries agree with the reference's. The roof that comes down through the floor, which the decision left for a later version, is written now too, as the reference finds it, so that 0.2 leaves no such room to be drawn by hand, by the steward's general rule of 29 October 2026 ("generela regeln är att INTE implementea temporära lösningar utan hitta long term state of the art solutoins på allt"), for him to confirm; the loft of its example agrees with it. Against the reference (`packages/openeik/test/fixtures/rooms.json`, its work 727), 32 of 39 rooms agree exactly: 12 of a probe of 14, and 20 of its example's 25. The other seven lie beside a room separator or a floor's edge, a line here and a strip 0.2 mm wide in the reference, and differ by 0.1 mm along it, the reference's to change. Part IV, 7.5's note lists what else the reference changes, where this specification decided otherwise. **Decided, 30 October 2026** (the steward, in the openEik.org thread: "allt ja enligt din rekommendation"; section 4): a roof that comes down through the floor bounds rooms in 0.2, as Part IV, 7.5, rule 1 writes it, and no such room is left to be drawn by hand. The decision of 26 October 2026, which left it for a later version, is changed so. 73. **A component's body and frame.** A component (Part II, 6.2) is a plate, a bracket, a bolt group, a weld, a timber section or a cast-in item. Its type's `component` names its family and depth, or its `insert` a cast-in item; Part II, 6.3 defines the frame that `axes` gives it and what `componentInverted` does, and says that what these members do to a body is reference behaviour. The steward decided on 17 October 2026 that a contour plate's frame becomes normative in 0.2, as the reference implementation places it. The IFC bridge of `@openeik/tools` writes a component as a box of its size at its insertion point, and leaves out a plate, a bolt group, a weld, and a component placed by `axes`, `upright` or a cast-in item's `insertAt`. Which frames and which bodies become rules? Raised 26 October 2026 by the same bridge. In the reference implementation, a component's frame has its origin at the insertion point, the profile's first point, at its level's elevation plus its `offset`; its x runs towards the profile's second point in plan, its y to the left of x (to the right where `flipped`), and its z up; or `axes` gives it, as Part II, 6.3 says. `componentInverted` hangs the body down from the origin. `upright`, on a plate only and never with `axes`, stands the plate up, its y up and its thickness centred on the origin. A plate hosted on a column stands on the column's top plus its `offset`, on the column's axis. A cast-in item hosted on a straight wall is placed by `insertAt`: `along` from the wall's first point, `up` from the wall's base and `across` from its exterior face, its body running into the wall from the face it names, `count` items `spacing` apart, along the wall or up it. The reference writes the place it finds into the item's `profile`, `levelId` and `offset`, and writes them again when the wall moves. The bodies: for a timber section, and for every family without a shape of its own, a box of the element's `width` along x, its type's `depth` across and its `height` up, centred on the origin; for a plate, its outline (its own `plate.outline`, else its type's width by depth) less its holes, `height` thick; for a weld, a fillet's triangle along x; for a bolt group, each bolt's shank, head, washers and nut, sized from a table of ISO bolts built into the application; for an angle bracket and a joist hanger, their legs, with nail holes; and for a cast-in item, a block, a bar, a lattice tie or a conduit with its bends. The families `toilet` and `basin` are no longer made: the reference reads them as sanitary terminals. A plate exports as IfcPlate, a bolt group as IfcMechanicalFastener, a weld as IfcFastener (WELD), and the rest as IfcBuildingElementProxy. Reference: `componentSolids`, `plateFrame` and `retiredComponentTypes` in `src/core/elements/components.ts`; `partFrame` in `src/core/elements/partFrames.ts`; `placedPlate` in `src/core/elements/plates.ts`; `boltGroupSolids` in `src/core/elements/bolts.ts`; `weldSolids` in `src/core/elements/welds.ts`; `insertPoint` and `insertWorldPlacement` in `src/core/elements/inserts.ts`; `insertSolids` in `src/core/geometry/insertSolids.ts`. The choice: the frame alone becomes a rule; the frame and the bodies that are boxes and prisms; or every family's body. **Decided, 26 October 2026, as proposed:** the second, for 0.2, completing the decision of 17 October 2026. The frame of every component becomes a class-A rule, as the reference places it, `insertAt` included; a cast-in item's `profile`, `levelId` and `offset` become its writer's copy, which a reader ignores where `insertAt` is given, as a hosted railing's profile is its writer's copy in 0.1. The box, the plate, the weld's fillet and each bolt's shank, a cylinder of its diameter along z, become class-A bodies. A bracket's and a hanger's legs, a bolt's head, washers and nut (from a table no record holds), a lattice tie and a conduit stay reference behaviour (class C); a supplier who needs one of them exact declares it (Part II, 12.1). `toilet` and `basin` are deprecated in 0.2 (Part I, 9.6). Part VIII, 1 names the IFC classes above. With it, `ifcOfModel` writes plates, bolt groups, welds and components placed by a frame of their own or as cast-in items, by rule ([Part II, 6.3](https://openeik.org/spec/0.2/language#6.3); [Part IV, 7.2](https://openeik.org/spec/0.2/compiler#7.2)). On the IFC side the steward said the same day: "steel plates and bolts should be plates and fasteners". A note of [Part VIII, 1](https://openeik.org/spec/0.2/bridges#1) gives each component its class by its type, a bolt group's predefined type by its bolt's kind and nuts, and `ifcOfModel` writes them so, with the bodies an application gives, since 26 October 2026. 74. **A slab edge element's section and mitres.** A slab edge element, an edge beam or an edge form, runs along an edge of its host slab or foundation (Part II, 6.1, rule 6). Its type's `edgeProfile` gives its section, a `rectangle`, an `L` or a `U`, by its `width`, `depth`, `web`, `flange` and `anchor`, with a `facing`, a `beam` and a `chamfer` where it has them; Part II, 6.3 says when its ends are mitred (`miterEnds`) and how `horizontalOffset` moves it. Part IV gives no rule for its body, and a railing along its top (Part IV, 11.2, rule 9) rests on its section as the reference implementation builds it. So the IFC bridge of `@openeik/tools` writes its section's bounding rectangle along the edge, with square ends; where its host's type has layers but no structure layer, it hangs the section from another height than the reference does. Should its section, its anchor and its mitres become rules? Raised 26 October 2026 by the same bridge. In the reference implementation, x points across the edge, into the host from the edge's line. A rectangle is centred on the line. An L stands its upstand, `web` thick, outside the line, the full depth of the section, and its bottom leg, `flange` thick, inside it, out to `width − web`; a U adds a second upstand at the bottom leg's far end. Every section hangs down from its anchor: the host's top (`slabTop`), or the underside of the host's structure layer (`structureBottom`), the host's top less every layer down to and including its first layer whose function is `structure`, or less the host's `height` where its type has none. `verticalOffset` raises it, and `horizontalOffset` moves it in. A `facing` is a board outside the section. A `chamfer` cuts the upstand's top inner corner, and a `beam` thickens the host slab under the edge, so both change the host's body too. Without an `edgeProfile`, the element is a rectangle of its `width` by its `height`, anchored at the structure's underside; a framing family draws its own section. An end is mitred where `miterEnds` is `true`, and, without it, where the edge round that corner carries a slab edge element that mitres by itself (Part II, 6.3). A mitred end lies on the bisector of its host's corner, whatever the offsets, and stays square where the two edges run straight on, where the corner is sharper than about 28°, and where the edge is too short for its mitres. It exports as IfcBuildingElementProxy. The reference also writes `notches` in a slab edge element, which 0.1 does not define (section 2, row 20). Reference: `profileRects` in `src/core/elements/edges.ts`; `edgePlacement` and `mitresAlone` in `src/core/elements/edgePlacement.ts`; `thickenedBodies` in `src/core/elements/edgeBeams.ts`; `chamferFills` in `src/core/elements/edgeChamfer.ts`. The choice: its body stays reference behaviour, and so does the railing that rests on it; or its section, anchor, offsets, facing and mitres become class-A rules, with or without what it does to its host. **Decided, 26 October 2026, as proposed:** class-A rules in Part IV, into 0.1, as Part IV, 4.5 and 12.6 went into 0.1: they add no member, the reference builds them, and Part IV, 11.2, rule 9 then rests on a rule. The section, its anchor and offsets, its facing, its chamfer's cut and its mitres, as the reference builds them; and, as rules of the slab's own body (Part IV, 4.2), the host's thickening under a `beam` and the chamfer's fill. A framing family's section stays its family's (Part II, 5.4), and `notches` stay out until a version defines them. With it, `ifcOfModel` writes slab edge elements, mitres included, by rule ([Part II, 6.3](https://openeik.org/spec/0.2/language#6.3); [Part IV, 11.2](https://openeik.org/spec/0.2/compiler#11.2), rule 9). **Written, 26 October 2026:** [Part IV, 4.6](https://openeik.org/spec/0.2/compiler#4.6), rules 1 to 8: the section's rectangles, its facing, its anchor at the host's top or its structure's underside, its reach and `flipped`, its ends mitred on the corner's bisector by `k = (1 − n_in · n_c)/(u · n_c)`, square where the edges run on, where `|k| > 4` or where it is 1 mm long or less between its mitres, and the chamfered upstand; rules 9 to 11, the host's thickened edges in bands under its structure, its lower layers giving way, the chamfer's fill, and the fit a validator checks; [Part II, 5.6](https://openeik.org/spec/0.2/language#5.6), rules 1 and 2, and 6.1, rule 6, what makes the section and the edge readable; [Part IV, 11.2](https://openeik.org/spec/0.2/compiler#11.2), rule 9, on them. `@openeik/tools` compiles them, and the railing along them, to the reference's millimetre. 75. **A gutter's body.** A gutter hangs on an edge of a roof (`hostId`, `hostEdgeId`); its type's `gutterProfile`, which 0.1 requires, gives a half-round or a box section and its offsets (Part II, 5 and 6.3). Part II, 6.3 says that `horizontalOffset` moves a gutter out from its roof's edge, and that a gutter along an edge that lies under another roof of its roof's group (`roof.joinGroup`) is left out there. Part IV, 4.4 gives the roof's top surface and its overhangs, and no rule for the gutter. So the IFC bridge of `@openeik/tools` writes its section along its roof's edge, moved out by the overhang, calls it approximated, and writes the whole gutter where another roof buries part of it. Should its section, its place, its ends and where it is buried become rules? Raised 26 October 2026 by the same bridge. In the reference implementation, a gutter runs along its edge's eave line, the edge moved out by its `overhang` (Part IV, 4.4, rule 3), from where that line meets the moved line of the edge before it to where it meets the next, with square ends. Its top is the roof's top surface at each end of that line, straight between. A half-round of inner diameter `diameter` lies outside the eave line, its back lip on the line and its rim level with the roof's top, its shell `thickness` thick; a box reaches `width` out from the line and is `depth` deep, its walls and bottom `thickness` thick. The type's and the element's offsets add: `horizontalOffset` out from the edge, `verticalOffset` up. Where a face of another roof of the group lies over the eave line more than 20 mm above the gutter's roof, the gutter is left out; the reference finds that at 25 points along the line, and drops a piece of 10 mm or less. It exports as IfcPipeSegment (GUTTER). Six of the reference's nine single-file examples name a built-in gutter type they do not contain (section 2, row 4). Reference: `gutterSolids`, `gutterPath`, `halfRoundCells` and `unburiedSegments` in `src/core/elements/gutters.ts`; `roofFaces` in `src/core/elements/roofs.ts`. The choice: it stays reference behaviour; its section and place become rules, and where it is buried stays each application's; or all four, where it is buried found exactly from the faces rather than at points. **Decided, 26 October 2026, as proposed:** all four, class-A rules in Part IV, into 0.1, as the reference builds them and as Part II, 6.3 already describes them, with one change: a gutter is left out where its eave line lies, in plan, under a face of another roof of its group that is more than 20 mm above its own roof's top there, found exactly from the faces' outlines rather than at 25 points. The reference changes, or a tolerance of a twenty-fourth of the edge holds until it does. A half-round's arc is the rule, and its faceting a compiler's, as a pipe's is (Part IV, 12.3, rule 5). Downpipes stay reference behaviour (Part IV, 7.2). With it, `ifcOfModel` writes gutters by rule, and leaves out what another roof buries ([Part II, 6.3](https://openeik.org/spec/0.2/language#6.3); [Part IV, 4.4](https://openeik.org/spec/0.2/compiler#4.4)). **Written, 26 October 2026:** [Part IV, 4.7](https://openeik.org/spec/0.2/compiler#4.7), rules 1 to 7: the eave line between the moved lines of the edges beside it, its height at the roof's top at each end of each piece, the half-round's and the box's sections, the offsets (turned round by `flipped`, as the reference does), square ends, and where another roof of the group lies more than 20 mm over its own, found exactly along the line, a piece of 10 mm or less left out; [Part II, 5.6](https://openeik.org/spec/0.2/language#5.6), rule 3, and 6.1, rule 13. `@openeik/tools` compiles them; the reference's 25 points are section 2, row 34. 76. **A stair's flights, landings and winders.** A stair's profile is its start and a point up its first run, or, for a circular stair, its centre and its start (Part II, 6.1, rule 7). Its `stair` gives its shape (`straight`, `L`, `U`, `spiral` or `helical`), the side it turns to, its location line (the line the profile gives, which its width lies on), its risers, going, first run, landing, gap and winders, and `repeatOf`, another stair it repeats; its type's `stair` gives the limits and the construction. Part IV, 5.1 gives its height, and Part IV, 2 and 7.2 leave its runs and landings to reference behaviour (class C). A railing on a stair waits for them (open question 18). The IFC bridge of `@openeik/tools` writes a straight stair as one flight, a solid of its treads, and leaves out every other shape, where clients' models hold L and U stairs. Which parts become rules, and for which shapes? Raised 26 October 2026 by the same bridge. In the reference implementation, the rise is the stair's top less its base. Without `stair.risers`, a stair has the fewest risers no higher than its type's `maxRiser`, and at least 2; each riser is the rise divided by their count, and there is one tread fewer than risers. Its going is `stair.going`, else its type's; the comfort rule, twice the riser plus the going, is only checked. The location line runs from the profile's first point towards its second: with `centre`, the default, the width lies half on each side of it; with `left`, the line is the stair's left edge, looking up the stair; with `right`, its right edge. A straight stair is one flight. An L or a U stair has `firstRunRisers` risers in its first flight, else half its risers rounded up, and a landing at the height they reach, `landingDepth` deep, else as deep as the stair is wide, and never less. An L's second flight turns 90° to its `turn` side, left by default, and leaves the landing's far end; a U's runs back beside the first, `gap` from it, 100 mm by default. With `winders`, an L turns on a square of winders (steps narrower at one end) cut at equal angles from its inner corner, or, with `balanced`, on winders spread along a walking line; a spiral or a helical stair turns about its centre. Each construction builds its own parts: a cast concrete flight is the solid of its steps down to a soffit `waist` below the line through their inner corners, measured square to that line, and a landing is a slab `landingThickness` thick; timber, precast and cross-laminated stairs have stringers, treads, risers and pieces of their own. The layout takes about 800 lines, the bodies about 800 more. Its IFC writes an IfcStair of a type by its shape, an IfcStairFlight for each flight with its risers and treads, a landing as an IfcSlab (LANDING) and a stringer as an IfcMember (STRINGER). Reference: `stairNumbers`, `stairLayout`, `turnWalk` and `stairSolids` in `src/core/elements/stairs.ts`; `stairPredefined` in `src/core/io/ifcExport.ts`. The choice: stairs stay class C; every shape's layout becomes a rule at once; or the layout of the common shapes now and the rest later, with most constructions' parts left to the reference. **Decided, 26 October 2026, as proposed:** the third. For 0.2, class-A rules in Part IV for every stair's riser count, riser height, going and location line, and for the layout of a straight stair and of an L or a U stair with a landing: each flight's treads and nosing lines, in plan and in height, and each landing's outline and top, as above. The bodies of a cast concrete flight and of a landing become class-A rules with them; the other constructions' parts stay class C. Part VIII, 1 names the IFC parts. Winders, spiral and helical stairs, and a stair that repeats another (`repeatOf`) come in a later version, after conformance cases from the reference's own stairs; until then a bridge says that it approximates them. A railing on a straight, L or U stair can then follow its flights by rule (open question 18). With it, `ifcOfModel` writes straight, L and U stairs with landings by rule, a concrete stair's flights exactly, and those of other constructions as the solid of their steps, which it says is approximated ([Part IV, 7.2](https://openeik.org/spec/0.2/compiler#7.2); [Part II, 6.1](https://openeik.org/spec/0.2/language#6.1), rule 7). **Written, 28 October 2026:** proposed for 0.2. [Part IV, 7.3](https://openeik.org/spec/0.2/compiler#7.3), rules 1 to 7, behind the proposal `stairs`: a stair's risers (its own count, else the fewest its type's `maxRiser` allows, at least 2), their height and its going; its location line; each flight's treads, numbered from 1 up the stair, and nosing lines; a straight stair's one flight; an L's or a U's first run (its own count, else half its risers rounded up), its landing at the height it reaches, as deep as given or as the stair is wide, and its second flight, an L's from the landing's far end, a U's back beside the first, 100 mm away where it gives no gap; and a cast concrete stair's flights, its steps down to a soffit `waist` below and square to the line through its risers' roots, cut level at its floor or its landing's underside, and its landings, slabs `landingThickness` thick under their tops. Other constructions' parts, winders, spiral and helical stairs and `repeatOf` stay reference behaviour (rule 7). `@openeik/tools` lays stairs out with the proposal (`compileModel`, its result's `stairs`; `stairLayout` in `compile-stairs.js`), builds a concrete stair's bodies, writes them as its IfcStairFlights and its landing as an IfcSlab (LANDING) and no longer calls them approximated, warns of a stair it cannot lay out (`stairs-layout`), and matches the reference implementation's own layout and bodies on a probe of eight stairs exactly (`test/fixtures/stairs.json`). 77. **A shaft's openings.** A shaft is an outline with a base and a top (Part I, 4; Part IV, 5.1). Part II, 6.2 says that it opens the slabs, ceilings and roofs it passes, and has no body, and Part IV, 1 that the openings cut in hosts are derived, but no rule says how. So the compiler of `@openeik/tools` builds a slab whole where a shaft passes it, and its IFC bridge writes no opening for the shaft: its print and its quantities keep the floor that the shaft opens. Should the cut become a rule? Raised 26 October 2026 by the same bridge. The reference implementation cuts the prism of the shaft's outline, exactly, from its base to its top, out of every layer of every slab, ceiling and roof whose body it overlaps in height by more than 0.5 mm, whatever their levels, and, where the shaft's type's `shaft.purpose` is `stair`, out of a foundation too. Walls and beams stay whole. A shaft that ends inside a host leaves a pocket in it. Its IFC writes an IfcOpeningElement (OPENING) through each slab, ceiling and roof it cuts, voiding it; a pocket is an OPENING too, and a foundation gets none. Reference: `shaftRange`, `shaftCutters` and `shaftHosts` in `src/core/elements/shafts.ts`; `subtractShafts` in `src/core/geometry/voidCuts.ts`; `shaftMeetings` in `src/core/elements/shaftOpenings.ts`. The choice: the cut stays reference behaviour; or it becomes a class-A rule, as a slab's own `voids` are (Part IV, 4.2, rule 4). **Decided, 26 October 2026, as proposed:** a class-A rule in Part IV, 4.2, into 0.1, as the reference cuts: Part II, 6.2 says already what a shaft opens, and the rule adds no member. A bridge writes an IfcOpeningElement in each host the shaft cuts, of the kind OPENING where it passes through the host and RECESS where it ends inside it, a foundation included; the reference changes there. With it, `@openeik/tools` compiles slabs, ceilings and roofs open where shafts pass, and its bridge writes their openings ([Part IV, 4.2](https://openeik.org/spec/0.2/compiler#4.2); [Part II, 6.2](https://openeik.org/spec/0.2/language#6.2)). **Written, 26 October 2026:** [Part IV, 4.2](https://openeik.org/spec/0.2/compiler#4.2), rule 8: the prism of the shaft's outline from its base to its top, out of every body of the slabs, ceilings and roofs it overlaps in height by more than 0.5 mm, and of a foundation's for a stair's shaft, through a body's face where it reaches within 0.5 mm of it; an opening where it takes all of the host within its outline, a recess otherwise. [Part VIII, 1.3](https://openeik.org/spec/0.2/bridges#1.3): an IfcOpeningElement OPENING or RECESS in each host. `@openeik/tools` compiles the cut, a pitched roof's included, to the reference's cubic millimetre, and its bridge writes the openings; the reference's OPENING for a recess is section 2, row 35. 78. **Where a member's profile sits on its body.** Part IV, 6 places a member's section: a beam's centred across its plan axis, its underside on its set-out line (the line its record places it by, Part IV, 6.2); a column's centred on its point. Part IV, 6.5 gives every member a reference line, through the middle of its section, and an axis, through its centroid. IFC carries a member's section as a profile, and says where the profile sits on the member by a cardinal point: the point of the profile that lies on the member's axis line, its 'Axis' representation, such as the profile's bottom middle (2), its middle (5) or its centroid (10), given in an IfcMaterialProfileSetUsage on the member. Part VIII names none of these. So the IFC bridge of `@openeik/tools` writes a beam's or a column's section on its type, as an IfcMaterialProfileSet, and places it on no member. Which line is a member's axis line in IFC, and which point of its profile lies on it? Raised 26 October 2026 by the same bridge. The reference implementation writes the same profile set on the type, a profile for every section shape but `sheet` (a `2L` as two angles composed), and, on a member, no IfcMaterialProfileSetUsage, no cardinal point and no 'Axis' representation: the member's body is triangles, or its plan outline extruded upward, with its roll, its end rise and its turn in its points. It computes both of Part IV, 6.5's lines (section 2, row 6), and exports neither. Reference: `ifcProfileDef` in `src/core/io/ifcProfiles.ts`; `sweepsOf` in `src/core/io/ifcSwept.ts`; `memberStructuralAxis` in `src/core/geometry/memberStructuralAxis.ts`. The choice: the set-out line, with the bottom middle (2), where the record places a beam; the reference line, with the middle (5), about which a roll turns the section and on which joins are found; or the axis, with the centroid (10), which an analysis reads. **Decided, 26 October 2026, as proposed:** the reference line, with the middle (5), as an informative mapping in Part VIII, 1, in 0.1, as section 1.1's is: it asks no new body. A bridge that writes a member's profile writes on the member an 'Axis' representation along its reference line and an IfcMaterialProfileSetUsage of its type's set with the cardinal point 5; a beam's roll and a column's `turn` turn the profile about that line, and a tapered beam's end section is an IfcMaterialProfileSetUsageTapering. IFC4 places a parameterised profile by the middle of its bounding box, as the reference line runs through it. A roll turns the section about the reference line (Part IV, 6.2, rule 5), so only 5 keeps a rolled beam in place; with 2, the profile would turn about the beam's underside. An analysis export writes the axis (Part IV, 6.5), with the centroid (10). A beam built from a framing family has no single profile (open question 10), and gets no usage. With it, `ifcOfModel` places every profile it writes on its member, and the reference bridge follows ([Part IV, 6.5](https://openeik.org/spec/0.2/compiler#6.5); [Part VIII, 1](https://openeik.org/spec/0.2/bridges#1)). **Written, 26 October 2026:** [Part VIII, 1.4](https://openeik.org/spec/0.2/bridges#1.4), informative: an 'Axis' representation along the reference line and an IfcMaterialProfileSetUsage with the cardinal point 5, the roll and the turn about that line, a taper's end as an IfcMaterialProfileSetUsageTapering, none for a framing family's beam, and an analysis export's axis with 10. Neither bridge writes them yet. 79. **Where the site stands on a map.** A project's `site` gives a latitude, a longitude and true north, and its `elevationOffset` the project's zero above a shared datum (Part II, 2). No text says which point of the plan the latitude and the longitude name. No member names a coordinate reference system, the map grid in which a surveyor gives eastings and northings, such as SWEREF 99 TM, nor a vertical datum, the system heights are given in, such as RH2000. An IfcMapConversion, IFC's placing of a plan on such a grid, needs both. So the IFC bridge of `@openeik/tools` writes one only where its caller names the system. Which point do the latitude and the longitude name, and how does a model name its systems? Raised 26 October 2026 by the same bridge. The reference implementation reads the latitude and the longitude as the plan's origin, true north as the plan's +Y turned clockwise (Part II, 6.8), and `elevationOffset` as the height of the project's zero in its vertical datum. It has no base point or survey point, and its model names no system: its IFC export names SWEREF 99 TM and RH2000 for every project with a site, projects the latitude and the longitude by the transverse Mercator projection (Krüger's series), and turns the plan's x axis by true north and the grid's convergence, the angle between true north and the grid's north there. Reference: `eastNorth`, `sweref99tm` and `gridConvergence` in `src/core/site/geo.ts`; `exportIfc` in `src/core/io/ifcExport.ts`. The choice: the caller names the systems, as now; the model names its systems by their EPSG codes, the numbers that the EPSG registry gives coordinate reference systems, and a bridge projects the latitude and the longitude itself; or the model holds the map conversion's numbers as a surveyor gives them (eastings, northings, height and the grid's direction) beside the latitude and the longitude: two statements of one place, which can disagree. **Decided, 26 October 2026, as proposed:** into 0.1, Part II, 2 says that the latitude and the longitude name the plan's origin, `[0, 0]`, at the project's zero, as the reference reads them. For 0.2, the second: an optional `site.crs`, `{horizontal, vertical?}`, each an EPSG code (`"EPSG:3006"` for SWEREF 99 TM, `"EPSG:5613"` for RH2000), given only with the latitude and the longitude, `elevationOffset` then being the project's zero in the vertical datum. A bridge projects the latitude and the longitude into the horizontal system and writes the IfcMapConversion; one that cannot project a system says so, and writes none. A writer turns a surveyor's eastings and northings into a latitude and a longitude, so that the model holds one place. With it, `ifcOfModel` writes an IfcMapConversion without its caller's help, for the transverse Mercator systems it projects already: SWEREF 99 TM and its local zones, and the UTM zones of ETRS89 and WGS 84 ([Part II, 2](https://openeik.org/spec/0.2/language#2); [Part VIII, 1](https://openeik.org/spec/0.2/bridges#1)). **Written, 26 October 2026:** the 0.1 part, in [Part II, 2](https://openeik.org/spec/0.2/language#2): the latitude and the longitude name the plan's origin `[0, 0]` at the project's zero, `elevationOffset` above the shared datum, true north `trueNorth` clockwise from +Y about it. `site.crs` is planned for 0.2 (CHANGELOG, Planned). **Written, 30 October 2026:** the 0.2 part, proposed behind the proposal `site`: [Part II, 2.2](https://openeik.org/spec/0.2/language#2.2), rules 3 to 5 (`crs`, `{horizontal, vertical?}`, each `EPSG:` and a number, only with the latitude and the longitude; what it says, the writer turning a surveyor's eastings and northings into one place; a bridge projecting into it, or saying it cannot), and [Part VIII, 1.7](https://openeik.org/spec/0.2/bridges#1.7) (the IfcProjectedCRS and the IfcMapConversion). `ifcOfModel` of `@openeik/tools` writes the map conversion from `site.crs` with the proposal, for the transverse Mercator systems it projects; the reference implementation still names SWEREF 99 TM and RH2000 for every project with a site. 80. **A linear device's length.** Part XIII, 2.3, rule 3 says that an electrical element's `width` and `height` equal its type's. A lighting track, or a linear luminaire, is laid to the length of the room it lights, as a pipe or a duct is laid to its run: one type, many lengths. The reference implementation's examples hold tracks from 800 to 4500 mm long of one type 2000 mm wide, and a validator with the proposal electrical refuses each (`electrical-size`). Raised 26 October 2026 by the reference implementation's check of the IFC bridge. What the reference does: a **linear device** is a device of the kind `track`, or of the kind `light` mounted on a ceiling or a floor whose type is at least three times as wide as it is deep. Its `width` is its length, its own where the element gives one, laid across the way it faces; its type sets its height and its depth (`isLinearDevice` and `deviceWidth` in `src/core/elements/electrical.ts`, Stomra work 554). **Decided, 26 October 2026, as proposed:** as the reference does. Rule 3 holds for every device but a linear one, defined as above; a linear device's `width` is its own, from 1 to 50 000 mm, and its `height` its type's. A writer gives a linear device its length; one that gives none takes its type's `width`. The body (section 7) and IFC (section 10) take the element's length. **Written, 26 October 2026:** [Part XIII, 2.3](https://openeik.org/spec/0.2/electrical#2.3), rule 3: a linear device is a device whose type is mounted on a ceiling or a floor and is a `track`, or a `light` at least three times as wide as it is deep, as the reference's `isLinearDevice` has it; its `width` is its own length, from 1 to 50 000 mm, and its `height` its type's; a writer with no length to give gives its type's `width`. The body (section 7) and IFC (section 10) are as long as the element; 2.1, 2.2 and 9 say so too. `@openeik/tools` checks the rule (`electrical-size`), and its compiler, and so its IFC bridge, which writes the compiler's body, take the element's length. The reference's widths over 50 000 mm are in 2.3's note. 81. **Reinforcement in a beam.** Part II, 6, rule 6 lets a rebar element be hosted by a slab or a foundation, and a mesh also by a wall. An edge beam's bars, and a beam's or a column's cage, have no host they may name: the reference implementation's guesthouse example holds 23 rebar elements hosted by an edge beam, which a validator refuses (`host-category`). Raised 26 October 2026 by the same check. **Decided, 26 October 2026, as proposed:** a rebar element MAY also be hosted by a beam or a column, and by a slab edge element (an edge beam); a mesh stays a slab's, a foundation's or a wall's. The bars' placement rules of Part II and Part IV hold in the host's own frame, as they do in a slab's; where they name the host's thickness, a beam's or a column's is its section's depth across the bars' plane. **Written, 26 October 2026:** [Part II, 6.1](https://openeik.org/spec/0.2/language#6.1), rule 6: a rebar element hosted by a slab, a foundation, a beam, a column or a slab edge element, a mesh element by a slab, a foundation or a wall; the rules that place reinforcement hold in its host's own frame, and where they name the host's thickness, a beam's, a column's or a slab edge element's is its section's depth across the plane the bars lie in; a note says what a host's own frame is. [Part II, 7](https://openeik.org/spec/0.2/language#7) names the hosts too. `@openeik/tools`' validator and command processor take the new hosts (`host-category`), and its IFC bridge writes a bar set in a beam, a column or a slab edge element. The reference implementation's bar sets in a wall, and its refusal of one in a slab edge element, are section 2, row 37. 82. **The legends of electrical drawings.** A detail item's legend names its `scheme`, one of six in 0.1 (`type`, `department`, `unit`, `class`, `systems`, `fire`). The reference implementation's electrical drawings colour rooms or devices by `electrical` and by `circuits` (its work 534), which 0.1's schema refuses: its installations example cannot be checked with the proposal electrical. Raised 26 October 2026 by the same check. **Decided, 26 October 2026, as proposed:** with the proposal electrical, a legend's `scheme` MAY also be `electrical` (by the devices' kinds) or `circuits` (by their circuits), in Part XIII beside its other records; 0.1's view schema stays as it is, and the schema generator keeps the two values out of it, as it keeps `display.lighting` (Part XIII, 4.3). **Written, 26 October 2026:** [Part XIII, 4.4](https://openeik.org/spec/0.2/electrical#4.4), rules 1 and 2: with the proposal, a legend's `scheme` MAY also be `electrical`, the devices by their kinds, or `circuits`, the circuit schedule, and no other value outside 0.1's six. The proposal's index, `schemas/proposed/electrical/index.json`, names them in its new `values`, with the enumeration of 0.1 they widen, and `@openeik/tools` accepts them there when it checks with the proposal. 0.1's detail item schema is unchanged; `tools/generate-schemas.mjs` already kept the two out of it (`LATER`). 83. **The members of a framing family in IFC.** A beam or a slab edge element built from a framing family (Part II, 5.4) takes its body from the family, whose `member` parts are placed by the family's expressions. 0.1 gives the expressions' language and leaves the placing to the reader (Part IV, 6.5); a reader that cannot place the parts leaves such a beam out of an analysis (decided for 0.2 on 22 October 2026). The IFC bridge of `@openeik/tools` evaluates no family, and so writes none of their studs, plates, joists and truss members: 78 members on the reference implementation's guesthouse example and 117 on its villa, which a structural engineer reads from IFC. Raised 26 October 2026 by the same check. The choice: leave them out until the steward decides whether the reference implementation's framing and truss engine becomes an open profile (the open decision on that engine); write each framing element as one body along its reference line, the family's envelope, marked approximated; or have `@openeik/tools` evaluate the family's expressions, which Part II, 5.4 specifies, and write each `member` part as an IfcMember or an IfcBeam with its own body. The third reads only what the model holds, the family and its expressions, and needs none of the engine that lays out a wall's studs; where the reference derives members from a wall, which the model does not hold, they stay out. **Decided, 26 October 2026, as proposed:** the third, for the families the model holds, with the second as the stand-in where an expression cannot be evaluated; members that only the reference's engine derives stay out until the open decision on that engine. **Amended, 29 October 2026:** of five open items put to the steward that day, item d was this question, and he answered "a spec, b spec, c spec, d rule, e hook". For this question that is a rule of this specification, with no box standing in. His general rule, the same day: "generela regeln är att INTE implementea temporära lösningar utan hitta long term state of the art solutoins på allt". The question was then put to him in two parts, and he answered "83.1 ja 83.2 ja". 83.1: the tools evaluate a family's expressions and derive each part's body, with no stand-in; a family whose expressions cannot be evaluated, or whose parts cannot be built, is a finding that a validator reports, a model to fix, and a compiler derives it no body. The stand-in of the decision of 26 October 2026, the second choice, is dropped. 83.2: the reference implementation's framing engine, which lays out studs, plates, headers and trusses from walls and roofs, becomes open rules too. 83.2 is decided, and is written as a proposal of its own, apart from 83.1's. **Written, 29 October 2026 (83.1):** [Part IV, 6.6](https://openeik.org/spec/0.2/compiler#6.6), proposed for 0.2 with the proposal `framing`, rules 1 to 15: a family evaluated with the element's parameters and its `Length`; each part that exists outlined in the family's plane, cut by its cuts, the parts it is joined to and a top chord's tail, and kept as its pieces; nail plates on their members' faces; the plane over a beam's set-out line, slope included, and along a slab edge element's edge; each piece a body, named by its part, and each part a member keyed `:` where the family has members; what a family may say, every member of Part II, 5.4 built; and a family that cannot be evaluated or built a finding of a validator and a compiler (`framing-expression`, `framing-part`), never a stand-in. [Part VIII, 1.6](https://openeik.org/spec/0.2/bridges#1.6): a family of profiles the element's own body, each part an IfcShapeAspect; a family with members its parts under the element by IfcRelAggregates, each an IfcMember, IfcBeam, IfcColumn or IfcPlate by its role, the element without a body of its own. `@openeik/tools` derives and prints them with the proposal, and agrees exactly with the reference implementation's own bodies of its villa's 117 rafters and its guesthouse's 78 trusses and rafters, part by part. The framing that 83.2 makes rules is not 6.6's. **Amended, 29 October 2026 (83.2):** the steward's "83.1 ja 83.2 ja", under his general rule quoted above, made the reference implementation's framing engine open rules, without approximations or stand-ins, and what cannot be stated yet is said with a code. Written the same day as [Part IV, 7.4](https://openeik.org/spec/0.2/compiler#7.4), proposed for 0.2 (the proposal `framingLayout`): a wall's framed layers laid out in plates, studs, end and corner studs, a T's backing, each opening's jacks, kings, headers, sill and cripples, noggings, battens and heel members, with the corners and tees they read (section 7.1, stated) and a wall's cut roof; one member added, a horizontal rule's `battens`. Not laid out yet, each said with its code: a wall a truss layout may bear on, and a wall whose members are materialised. A roof's truss layout and a floor's joists are other engines of the reference implementation, and their rules are the next of this part: a truss layout's members are then classed by Part IV, 6.6's table, as a family's are. **Written, 30 October 2026 (83.2, roofs and floors):** [Part IV, 7.4.13 to 7.4.15](https://openeik.org/spec/0.2/compiler#7.4.13), under the same proposal `framingLayout`. A roof's truss layout (7.4.13): its trusses, each its family's parts built as section 6.6 builds them, on a line across its span between the walls or beams it bears on, named or found, placed by its layout's rule within its range between its gables; a roof opening's trimmers, headers and dormer rafters, a ridge beam and its posts, and an anchor pair where each truss rests; and in IFC, each truss an IfcElementAssembly TRUSS with its members under it. The walls it bears on (7.4.14): studs under its trusses, their bottom chords across battens, the heel zone they hold, the heel plate at a rafter's seat, a ridge beam's pocket and post in a gable, and a rafter's notch. A floor's joists (7.4.15): joists, trimmers, rim joists, headers and blocking, round its holes and the posts through it. One member added, a roof opening's `header`. Not laid out yet, each said with its code (7.4.12): a hip set, its girder, hip trusses and jack trusses, and with it every framed wall of its model. `@openeik/tools` lays them out and prints them, and agrees exactly with the reference implementation on its two examples that have them and on a probe of five roofs and two floors; where it differs, the text decides, as the notes of 7.4.13 to 7.4.15 say. **Written, 30 October 2026 (83.2, hip ends):** [Part IV, 7.4.16](https://openeik.org/spec/0.2/compiler#7.4.16), under the same proposal `framingLayout`, closes the gap 7.4.12 left: a truss layout's hip ends, each framed by a girder of plies where the ridge ends, hip trusses of plies up its hip lines and jacks square to its end and its sides, or, on a short ridge with hips at both ends, by one girder along the ridge with half trusses hanging on it; the end bearing, an end wall's or the hip face's; the hip trusses' drop under both faces; the hangers; and the jack family and the flat-top family the rules make of the layout's own, written out in the language of Part II, 5.4, unless the model holds its own. No member is added: the rules read `hips`, which 0.1 has. Every framed wall under a hipped roof is laid out with its hip trusses and jacks. A sloped face that is neither an eave nor a hip end, a valley's, is framed by no truss and said, as the reference implementation frames none. `@openeik/tools` lays them out and prints them, and agrees exactly with the reference implementation on a probe of nine hipped roofs, none of its examples having one: 272 trusses, 2049 members and 533 connections. 84. **The well-known name `openeik`.** A host that signs receipts serves its keys at `/.well-known/openeik/host-keys.json` on its origin, so that a verifier can fetch them as trust anchors ([Part XVIII, 5.6](https://openeik.org/spec/0.2/review#5.6), proposed for 0.2). That path is a well-known URI (RFC 8615), and RFC 8615, 3 asks that every well-known URI be registered with IANA, in its registry of well-known URIs, whose policy is Specification Required; `openeik` is not registered. Raised 26 October 2026 by a host's plan to publish the keys it signs receipts with. The choice: register `openeik` now, for a part that is only proposed and still changes; register it once Part XVIII is published in 0.2, with a registration template in Part XVIII, as Part III, 11.2 has one for the media type; or name no path, and leave where a host's keys are to each host, which a verifier is then told for every host. **Decided, 26 October 2026, as proposed:** the second. One name, `openeik`, under which every file of the standard that a host serves goes, so that one registration covers them; registered with IANA once Part XVIII is published in 0.2, since the registry asks for a stable specification and a proposed part still changes in place. Until then a host serves its keys at that path, unregistered, and a verifier is told a host's origin by its caller, as it is told which keys to trust. 85. **Folders that follow owners.** Part III, 4.1 files an element in one of four discipline folders by its category, and keeps a wall, a slab or a roof in `architecture` even when it bears: the folder follows who places a record. Part XVI gives ownership by path, and its parties work in eight disciplines (Part XVI, 2, rule 4). So a path cannot say who owns what where the disciplines decide it. On the reference implementation, since its work 670 (live 26 October 2026), a wall, a slab or a roof ticked `structural` is the structural engineer's (the steward, 24 October 2026), as is a stair that carries; ducts and air terminals are ventilation's, pipes and the other terminals heating and plumbing's; planting, roads and parking are the site's. Under `systems/`, only the category tells a duct from a pipe, and nothing tells an air terminal from a radiator; under `architecture/`, nothing tells a bearing wall from a partition. An owners file for such a project either gives the structural engineer every wall or none, and a host that enforces it (Part XVI, 4, rule 4) asks other approvals than the application did. Raised 26 October 2026 by the reference implementation's sharing by discipline (its work 670, step 8). The choice: keep the four folders, and let a rule match a record's members as well as its path (`structural: true`, a run's system), which no tool that knows only paths can check, and which a host must read every record to apply; a trade folder under `systems/` (`systems/ventilation/…`), which separates the building services and leaves bearing walls where they are; or folders by owner: a record's discipline folder is the discipline that owns it, one of Part XVI's eight, so that a party owns its discipline's folders and a plain glob says it. **Decided, 27 October 2026, as proposed:** the third, for 0.2, written as follows. 1. **An owner.** An element, a type and a view MAY carry `owner`, one of the eight disciplines of Part XVI, 2, rule 4, set by hand; it wins over every rule below. Otherwise an element's owner is, in this order: `structure` for an element that carries `frameHost`, a wall, a slab or a roof that is `structural`, and a stair that is `structural`, or that has no `structural` and whose type's `stair.construction` is of concrete or cross-laminated timber; `structure` for the categories `beam`, `column`, `foundation`, `slabEdge`, `rebar` and `mesh`, and for a `component` that 0.1's rule 2 puts in `structure`; `ventilation` for a `duct`, and for a `terminal` whose system carries air or whose type is an air device (an inline duct part, a transfer air device, an air handling unit, a heat pump that air passes); `plumbing` for a `pipe` and every other `terminal`; `electrical` for an `electrical` device, a `cable` and a `cableCarrier`; `site` for `terrain`, `grading`, `propertyLine`, `planting`, `road` and `parking`; and `architecture` for every other element. A type's owner is its own `owner`; else `structure` for a wall, slab, roof or stair type that an element of `structure` by the first rule uses (its layers are the bearing build-up); else the owner its category gives an element. A view's owner is its `owner`, else `setup`. A sheet's is that of its `discipline` code: A and BR `architecture`, K `structure`, V and VE `ventilation`, VS `plumbing`, E `electrical`, M, L and G `site`, any other `setup`. `sprinkler` and `setup` own an element or a type only by `owner`. 2. **The folders.** An element: `///.json`. A type: `types///.json`. A view: `drawings//views///view.json`, its details beside it. A sheet: `drawings//sheets/.json`. The other lists keep their folders (Part III, 1): `project/` is the project setup's, `fabrication/` (the pieces and joints of the reference) structure's, `project/circuits/` electrical's, and `documents/` keeps the records any writer adds. These replace Part III, 4.1's table and its rules 1 and 2; its rules 3 to 6 hold for the eight folders `architecture`, `structure`, `ventilation`, `plumbing`, `electrical`, `sprinkler`, `site` and `setup`, and for `types/` of each, with `architecture` where 0.1 says it. 3. **An owners file follows.** A party that works in a discipline owns `/**`, `types//**` and `drawings//**`; Part XVI, 2's example becomes one such rule for each party, with no glob that names a category. 4. **What a path does not say.** Three rules of the reference are finer than a record, and stay an application's in 0.2: fields of a record that another discipline owns (the framing of a wall that architecture owns is structure's); the answer to a request for an opening, which the owner of its host gives (open question on the provision record, asked of the steward on 26 October 2026); and a record that only follows its host (studs moved with their wall), which the reference lets the host's owner change. A host that enforces paths asks the follower's owner too, and does not see the fields. An application MAY refuse more than its owners file says; it SHOULD NOT accept a change that the file's paths refuse without saying so. 5. **The change of layout.** A 0.2 writer writes the new folders; a reader MUST accept a record in either layout (Part III, 4.1, rule 4 already forbids reading meaning from a folder). The first version a writer makes in the new layout moves every record whose folder changes, once, and so touches both its paths (Part XVI, 4, rule 1): that version needs the owners of all of them, and SHOULD be made by a party that owns `**`, with a version message that says so. Every later version has the same paths as its records' owners. The cost: a migration of every tree, once, and a type whose folder follows its elements (a wall type moves to `types/structure/` when a wall that uses it is ticked `structural`). The gain: one function decides a record's owner and its folder, so the application that checks a change, the host that holds it for approval and a tool that only knows paths give the same answer. **Written, 30 October 2026:** as [Part III, 4.4](https://openeik.org/spec/0.2/code-base#4.4) and [Part XVI, 3.1](https://openeik.org/spec/0.2/ownership#3.1), proposed for 0.2 with the proposal `ownership`, and in `@openeik/tools` (`modelOwners`, `migrateFiles`, `migrateFolder`, `ownersForLayout`, `openeik migrate`). The five points stand as decided. What they left open is settled so: - **A component** that is neither `structural` nor of a plate's or a cast-in item's type may be a connector of its writer's library, which 0.1's rule 2 puts in `structure` and no other tool can know (Part III, 4.1, rule 4): it stays in the folder it was read from where that is one of the eight, else it is `architecture`'s, as a type of a component of another family. So the reference implementation's connectors stay in `structure`. - **A `generic` record** follows section 4.1, rule 5 for the eight folders: `structure` or `site` where its `generic.discipline` names it, else `architecture`, since `systems` names none of the eight; its `owner` gives a lift to whom it belongs. The reference implementation gives it to `setup`. - **An air device**, point 1's words, is written as Part III, 4.4, rule 3: by its type's kind (a duct's six components, `transferAir`, `ftxUnit`, a `heatPump` with a connection that carries air), else by its system, a component's being its run's; a type by its kind, or by its own system unless it mounts on a pipe. These are the reference implementation's `terminalIsAir` and `terminalTypeIsAir`. - **A type's owner by its elements**: only an element that bears by its own members, and carries no `owner`, makes its wall, slab, roof or stair type `structure`'s, as the reference implementation's `bearingTypeIds` has it. - **A sheet's discipline code** is a member of the sheet, `discipline`, one to four capital letters, which Part XIV, 2.1 now names; where a sheet gives none, the letters its number begins with, as the reference implementation's `sheetDiscipline` reads them. - **A record of a category a reader does not know** stays in the folder it was read from where that is one of the eight, else in `architecture` (Part III, 4.1, rule 6, for the eight folders). - **Reading both layouts** (point 5) needs no flag: no path is a record's in both layouts with two meanings. A writer writes one layout; a validator reports a record in a folder neither layout gives it, and warns about a folder in both (`layout-mixed`). The five new folder names are reserved in the extension registry. - **The migrating version** (point 5) changes no record but by moving it, so its diff shows each record `moved`, a new kind of change (Part VI, 4, rule 3); the rest of a model's migration to 0.2 may share it. It rewrites `project/owners.json` in the same version, by a rule that a tool applies (Part XVI, 3.1, rule 3): 0.1's globs and globs that name a category go, and each discipline whose parties lose one gets a rule of its folders, with the parties that lead; a party with no discipline that loses its paths is named for a person to place. - **What stays and what changes** (Part III, 4.4, rule 9): ids, GlobalIds and every record's hash stay; paths, the trees that hold them and every root from the migrating version on change, once, and so does every digest of pairs. A pair is compared with the record its path names, in either layout, so a result set whose records only moved stays current (Part VI, 8.4, rule 5), and so does a drawing issued before the change (Part XIV, 9.4). - **A merge across the change**: a line still in 0.1's layout that merges into one in the owners' touches its records' owners' paths (Part XVI, 5, rule 1). On the reference implementation's seven example projects (3 288 records, its `main` `f2bc53d2`), the rules give every record the owner its own functions give it, and the change of layout moves between 10 and 368 records each, from 0.1's folders as the reference implementation writes them. **Written, 30 October 2026 (point 4):** the request for an opening is a provision for a void, [Part II, 6.10](https://openeik.org/spec/0.2/language#6.10), proposed for 0.2 with the proposal `provision` (section 4, D9): its asker's record, whose answer its host's owner gives; Part III, 4.4, rule 2 gives a provision its asker's owner. A suggestion is a proposal made by an envelope in the mode `propose` ([Part XVI, 5, rule 5](https://openeik.org/spec/0.2/ownership#5)). The answer stays a field that a host that enforces paths does not see, as point 4 says of fields that another discipline owns. 86. **IFCX, buildingSMART's next IFC.** buildingSMART renamed IFC 5 to IFC X, written IFCX, in March 2026. An IFCX file is JSON: nodes named by paths, whose attributes are namespaced components (`bsi::ifc::class`, `bsi::ifc::prop::`, `usd::usdgeom::mesh`), and layers composed over each other, a later layer's opinion winning. Its public format is an alpha (`ifcx_alpha`, its schema unchanged since 3 July 2025), and a post-alpha draft is not merged; its project plan (version 1.0, 9 June 2026) was approved in August 2026, seeks its funding, and puts its publication by ISO, as a new part of ISO 16739 beside IFC 4.3, in 2029. Nothing in this specification named it. Should OpenEik print IFCX, and are its layers a form for OpenEik's history? Raised 27 October 2026 by the steward's question how OpenEik stands against IFC 5. The choice: leave IFCX aside until ISO publishes it; take its layers as OpenEik's store, a version a stack of layers; or keep OpenEik's records and history, and print IFCX as a bridge prints IFC4, a print of a version. **Decided, 27 October 2026, as proposed:** the third (the steward: "B ja"), with classification references named by URI (Part II, 11; "C ja"). 1. **IFC4 stays the print.** Every bridge prints IFC4 in 0.1 and 0.2 (Part VIII, 1); an IFC 4.3 print comes later, as planned. 2. **IFCX is a print too,** never a record or a store (Part XVIII, 7). `@openeik/tools` writes it experimentally ("A ja"), from the inputs of its IFC4 writer: the same objects, each path the UUID of the object's GlobalId as buildingSMART's converter writes it, the same classes, property sets and bodies, in metres. It follows buildingSMART's alpha and changes with it, and no conformance class covers it until buildingSMART publishes a format that is not an alpha. 3. **IFCX's layers are not OpenEik's history.** They compose with the later layer winning and no merge, where OpenEik merges by record and field and reports a conflict (Part VI, 5). A proposal, or the changes between two versions, MAY be printed as an IFCX layer over a version's print. 4. **Codes by URI.** A classification reference names its code by the URI its publisher gives it, as IFCX names a node's class by its bSDD URI (Part II, 11, planned for 0.2). **Written, 30 October 2026:** point 4, in [Part II, 11](https://openeik.org/spec/0.2/language#11), rule 2, proposed for 0.2: a reference's `uri`, which a writer SHOULD give where the publisher gives one. 87. **Sections with rounded corners, and sections of any outline.** Part II, 5.2 gives a member's section one of ten shapes, each drawn from its sizes, and reads `radius` only for a `T`'s and a `2L`'s root fillets: it says nothing of a `rectangle`'s `radius`, which the schema takes, nor of an `RHS`'s, and no shape takes an outline of its own. Timber is often neither: wane-edged timber, logs hewn to a roughly rectangular section with rounded corners, such as 200 × 250 with corners of radius 50, so that the courses of a log wall bear flat on each other; D-logs, and round logs hewn flat where they bear; glulam with chamfered edges; and special profiles of timber and of sheet metal. A writer that cannot say such a section stands two members in for one, a hollow section round a solid core, and gets its quantities and its IFC wrong, or rounds nothing. Raised 27 October 2026 by a timber section with rounded corners that the reference implementation stored and drew square, and by the steward's question whether a section of any outline is part of the standard. The reference implementation took a `rectangle`'s `radius` and did not read it. Since 27 October 2026 (main `d12a2c54`, live the same day) it reads it: the section is the rectangle with its four corners rounded, drawn in 3D, plans and sections, its area `width × depth − (4 − π) × radius²` and its second moments exact, and its IFC an IfcRoundedRectangleProfileDef; a `radius` over half the smaller side is refused in a command, and a project that holds one already opens and replays as it did, drawn with its corners rounded to that half. It has no section of an outline of its own. Reference: `rectangleRadius`, `roundedRectangleArea` and `roundedRectangleInertia` in `src/core/geometry/roundedRectangle.ts`; `refuseRectangleRadius` in `src/core/elements/sectionRules.ts`; `ifcProfileDef` in `src/core/io/ifcProfiles.ts`. The choice: (A) `radius` on a `rectangle` rounds its four corners, as IFC4's IfcRoundedRectangleProfileDef does; (B) a new shape `custom`, whose `outline` is a closed contour with voids, its arcs written by a corner's radius, by a point an arc passes through, or by both, as IFC4's IfcArbitraryClosedProfileDef and IfcArbitraryProfileDefWithVoids hold an outline in an IfcIndexedPolyCurve of straight and arc segments; or both. **Decided, 27 October 2026, as proposed:** both, into 0.1 (the steward, Erik Goverde, in the thread "Stomra local coding (307)": first "Also check with openeik of arbitrary section is part of the standard (it should be)", then, to "yes or no on the OpenEik proposal for rounded and arbitrary sections", "ALL THESE ARE YES"). 1. **A rounded rectangle.** A `rectangle`'s `radius` rounds its four corners, each a quarter circle tangent to its two sides; absent or 0, the corners are square. It is at most half the smaller of `width` and `depth`: a command that writes more is refused, a validator reports it, and a reader that reads such a model takes the corners as rounded to that half. An `RHS`'s `radius` keeps the meaning it has: its outer corners, its inner ones rounded to it less the wall. 2. **An outline.** A shape `custom` with `outline: {points, voids?}`, each void `{points}`. A contour is a list of entries in mm in the section's own plane, `x` across and `y` up, closed by its last side and not repeating its first point: `[x, y]` a corner, `[x, y, r]` a corner rounded by an arc of radius `r` tangent to its two straight sides, and `{"through": [x, y]}` a point the side between its neighbours passes through, an arc of the circle through the three. Both kinds of arc, since each is what an author knows of it: a rounded corner its radius, a hewn log's arc a point on it. Wane-edged timber 200 × 250 r 50 is `[[0, 0, 50], [200, 0, 50], [200, 250, 50], [0, 250, 50]]`; a round log hewn flat on its underside, `[[-120, 0], [120, 0], {"through": [0, 240]}]`. 3. **What is refused.** A contour of fewer than three entries or fewer than two corners, or with two `through` entries one after the other; entries less than 0.1 mm apart, the first and the last too; a `through` entry on the line between its neighbours; a corner radius on a corner that does not turn, or beside an arc, or that does not fit its sides; a contour that crosses or touches itself; a void outside the outline, or crossing, touching or holding another; a `width` or `depth` other than the outline's bounding box's, within 0.1 mm; an `outline` on another shape, or a `custom` section without one. 4. **Where it sits, and what it weighs.** The middle of the outline's bounding box is the section's middle, on the member's reference line, so the outline's points may start anywhere; the area, centroid and second moments are the region's, arcs exact, voids out; volume and weight follow from them, and plans and sections cut the region with the type's material and hatch. 5. **IFC.** An IfcRoundedRectangleProfileDef for a rounded rectangle; for an outline an IfcArbitraryClosedProfileDef, or an IfcArbitraryProfileDefWithVoids, each contour an IfcIndexedPolyCurve of IfcLineIndex and IfcArcIndex segments, its points less the middle of the bounding box, placed by the cardinal point 5 as Part VIII, 1.4 says. **Written, 27 October 2026:** [Part II, 5.2](https://openeik.org/spec/0.2/language#5.2), rule 5, an `RHS`'s and a `rectangle`'s `radius`, and rules 7 to 10: the rounded rectangle, the outline and its entries, what its contours must hold, and where it sits and what it weighs. [Part IV, 6.2](https://openeik.org/spec/0.2/compiler#6.2), rule 4: a tapered rectangle's corners stay square; [6.5](https://openeik.org/spec/0.2/compiler#6.5), rule 6: a `custom` section's centroid offset. [Part VIII, 1.4](https://openeik.org/spec/0.2/bridges#1.4): the IFC4 profiles. The type schema takes `custom` and `outline`: `tools/generate-schemas.mjs` adds them from the specification while the reference implementation has no `custom` section, as it adds `generic`. `@openeik/tools` checks both shapes (`section-size`, `section-outline`), compiles their bodies, the outline in convex cells, and prints both profiles; the conformance suite has cases of both. The reference implementation's refusal of a larger radius only in a command is section 2, row 38. **Built, 28 October 2026:** the reference implementation has a `custom` section since its work 751 (`main` `35bef7f5`): it reads, draws and measures an outline as rules 8 to 10 say, refuses one that breaks rule 9 in a command that writes it, and prints the profiles of Part VIII, 1.4 with the segments and points `ifcOfModel` writes. The type schema takes `custom` and `outline` from it since: `tools/generate-schemas.mjs` no longer adds them, and adds only the rule that a `custom` section carries an outline and no other shape does. 88. **Imported property sets, printed back.** An element or a type imported from IFC carries the property sets it was imported with, `ifcSource.properties` in the element and type schemas: by set and by property, each value a text, a number or a truth value. The IFC bridge keeps the GlobalId it was imported with (Part VIII, 1, rule 3), but no rule said whether it prints the property sets, nor how, and `ifcOfModel` printed none. The reference implementation prints an element's under the names they were imported with, a number as an IfcReal. An authoring tool's IFC holds sets and properties IFC4 does not define, such as a set `Pset_QuantityTakeOff`, or a property `TotalArea` in `Pset_RoofCommon`, and values of other types than IFC4's templates give; buildingSMART's rule PSE001 refuses a set named `Pset_` that IFC4 does not define, a property its template lacks and a value of another type, so such a print fails it. Raised 28 October 2026 by the reference implementation, when it compared its IFC print with the bridge's on its examples (its work 750, item 3), which follows whatever rule is written. The choice: print nothing of them, and lose them in a round trip; print them as they were imported, and fail PSE001; or print a set IFC4 defines typed by its template, and every other property under a name that does not start with `Pset_`. **Decided, 28 October 2026, as proposed** (the steward: "merge and deploy all", then "merge 88 89", merging the merge request that wrote it; confirmed "88 behåll" on 29 October 2026): 1. A bridge SHOULD print a record's `ifcSource.properties` with the element or the type it prints. 2. A property set IFC4 defines, and a property its template defines, is written as the template types it: the measure type it names, an enumeration as an IfcPropertyEnumeratedValue of its enumeration, a bounded value as an IfcPropertyBoundedValue, and so on. 3. A set IFC4 does not define, and a property an IFC4 set's template lacks, are not written under a name that starts with `Pset_`: the set's name without `Pset_`, by a plain and deterministic rule that says what happens where that name is taken by a set the bridge writes itself. 4. A value that cannot be typed as the template says is written in the set without `Pset_` instead, and the fidelity report says so. **Written, 28 October 2026:** [Part VIII, 1](https://openeik.org/spec/0.2/bridges#1), rule 5, a SHOULD, and [1.5](https://openeik.org/spec/0.2/bridges#1.5): where an element's and a type's sets go (the object it was imported as, a type's own HasPropertySets); a set IFC4 defines whose template applies to the object, as PSE001 holds it, by class, predefined type and whether the set is driven by types or by occurrences; each property typed as its template types it, a bounded value's number its set point and a list value of the one value, a number in this specification's units and written in the print's, which declares them; everything else in the set's name without `Pset_`, or `Imported_` and the set's whole name where that name is empty, starts with `Pset` in any case, starts with `OpenEik_` or `Imported_`, is a set the bridge writes itself on the object, or is the name another of the record's sets takes; an imported set of the name of one the bridge writes itself joins it, the bridge's own values kept; and the report. [Part II, 6](https://openeik.org/spec/0.2/language#6): what `ifcSource` holds, and its numbers in this specification's units, a length in millimetres and an angle in degrees, any other measure in its SI unit. The proposal said nothing of a set IFC4 defines but does not apply to the object's class, which PSE001 refuses as it refuses a set IFC4 does not define: section 1.5, rules 2 and 4, write it without `Pset_` too. Nor did it say in what units a record holds a number: section 1.5, rule 3, and Part II, 6 say it. `@openeik/tools` prints them so (`src/ifc-properties.js`), with IFC4's templates from buildingSMART's table of its validation service (`src/ifc4-psets.js`, MIT License, in the package's NOTICE); the reference implementation's bridge is listed in [Conformance, 3](https://openeik.org/spec/0.2/conformance#3). **Amended, 29 October 2026:** the units of an imported record's numbers. The reference implementation held the numbers of records it had imported before this question in the units of the file it imported them from, and asked the steward whether to convert them by a script or to mark the records whose numbers are in this specification's units (its work 750, step 9). The steward, in the thread "Stomra - Large models": "on 750 carry a marker 5 in stomras cloud" (its "5" answers another question of that work, on fonts). `ifcSource.units`, one value, `"specification"`: present, every number of the record's `properties` is in this specification's units; absent, the record does not say which units, and a bridge types no number of a measure with a unit, which it writes in the set without `Pset_`, as it was imported; a number without a unit, a text, a truth value and an enumerated value are typed as before; no reader converts. Written in [Part II, 6](https://openeik.org/spec/0.2/language#6) and [Part VIII, 1.5](https://openeik.org/spec/0.2/bridges#1.5), rules 3 and 4, and in the element and type schemas. 89. **A steel frame for a door or window family.** A type's `openingFamily.material`, the material of its frame, was `wood`, `aluminium` or `aluClad`, and a steel frame, common in commercial and industrial buildings, had no value. Raised 28 October 2026 by a report to the reference implementation, whose work 749 adds `steel`, gives a door's leaf a material of its own (`leafMaterial`, the frame's where it is absent) and plans the profiles of a frame and its mullions. Should these join 0.1, or wait for 0.2? **Decided, 28 October 2026** (the steward, "b"): `steel` joins `openingFamily.material` in 0.1. A leaf's material and the profiles of a frame and its mullions wait for 0.2, with the frame of [Part IV, 4.3.1](https://openeik.org/spec/0.2/compiler#4.3.1) (open question 71), which they shape; until then they are an application's members (Part I, 11.2; section 2, row 20). **Written, 28 October 2026:** [Part II, 5](https://openeik.org/spec/0.2/language#5), its table of payloads: an `openingFamily`'s `material` and its four values. The type schema takes `steel` from the reference implementation, which writes it since its work 749 (`main` `c7d816f2`); `tools/generate-schemas.mjs` leaves its `leafMaterial` out (`LATER`). **Written, 30 October 2026:** the leaf's material, for 0.2, as [Part IV, 4.3.1](https://openeik.org/spec/0.2/compiler#4.3.1), rule 14, with the proposal `frames`: a door family's `leafMaterial`, `wood`, `aluminium` or `steel`, its leaves' material where it is not the frame's, the frame's where absent, changing no body; on a family of another kind a validator warns (`leaf-material`); its schema `schemas/proposed/frames/leaf-material.schema.json`, as the reference implementation writes it. The profiles of a frame and its mullions are not written: the reference implementation has none yet, and their form is question 97's. 90. **A layer's grain, and an element's main direction.** A compound slab, wall, roof, ceiling or foundation is its type's layers (Part II, 5.1): function, material, thickness, pattern, core. Nothing says which way a layer's fibres run. For cross-laminated timber (CLT), and for any layer stiffer one way than the other (LVL with cross veneers, a glulam deck, a profiled sheet), the stiffness, the strength, the deflection, the vibration and the fire resistance depend on it. A structural tool that reads a CLT type today must guess: Femra (its work 081) takes the lamellas as alternating from outer layers along the element's main direction unless a layer's name says otherwise, which is wrong for the common layups with two outer layers along each face (seven layers, "L7s-2") and for walls whose outer layers run horizontally. Nor is the direction the grain is relative to defined: a slab's `panels.direction` (Part II, 6.3, the panel division) is the only direction a slab has, and the text gives it no unit and no meaning; the reference implementation reads it as degrees in plan from x, the way the panels' widths add up, the panels spanning square to it, and takes 0 where it is absent. A wall has no direction of its own but its baseline. Femra carries the layup meanwhile in its extension member `femra:clt` (Part I, 11.2), which other tools do not read; and the reference implementation drops a type's unknown members in its own commands (Part V, 1, note), so such a member does not survive a type passing through them. Raised 28 October 2026 by Femra's work 081, CLT read from and proposed to a building. The choice: (A) leave the grain to applications' extensions, each structural tool keeping its own; (B) a layer member for the grain and a main direction on the element, small and in the core; (C) a full layup record of its own, a product with its layers and declared values, which belongs with the products and catalogues of a later version. **Decided, 28 October 2026, as proposed:** (B), for 0.2 (the steward: "88 ja", this question's number on its merge request before questions 87 to 89 of the same days took those numbers). 1. **A layer's grain.** A layer of a `slab`, `wall`, `roof`, `ceiling` or `foundation` type MAY carry `grain`: `"along"` where its fibres, or a sheet's strong direction, run along the element's main direction (rule 2), `"across"` where they run square to it in the layer's plane. A layer without `grain` states none: isotropic, or not said. No other angle in 0.2. 2. **An element's main direction**, the direction its `"along"` layers run: 1. **A slab, a ceiling or a foundation:** its `panels.direction`, defined: degrees, counter-clockwise in plan from the model's x axis, the way the panels' widths add up from `start`; the panels, and the element's main direction, run square to it. Without `direction`, 0. A slab whose layers state a grain and that has no `panels` MAY carry `mainDirection`, degrees in plan from x, the way its along layers run; where it has both, they MUST agree (`mainDirection` is `direction + 90` modulo 180), or a validator reports it. 2. **A wall:** `mainDirection`, `"vertical"` (the default) or `"horizontal"`, along its baseline. 3. **A roof:** in its plane, along the fall line of its slope-defining edge, unless it carries `mainDirection` (degrees in plan, projected on its plane). 3. **The order of the layers** is Part II, 5.1, rule 6's (horizontal types top first, walls exterior first), so a reader knows which face each layer is on, and so where a layup is not symmetric. 4. **What it does not cover.** The lamellas' width, edge gluing, a product's declared values and its ETA are product data, left to applications' extensions or a later product record. A layer's strength class is already its material record's `strengthClass` (Part II, 4.1), so a CLT type with C24 along and C14 across names two materials. 5. **Readers of 0.1** keep `grain` and `mainDirection` as members they do not know (Part I, 10). The grain changes no body, so a compiler derives the same bodies, and the IFC4 print is unchanged until the IFC side is pinned. A CLT floor type of five 40 mm lamellas, C24 along and C14 across, top first, has the layers `{"function": "structure", "material": "CLT C24", "thickness": 40, "grain": "along"}`, then `"CLT C14"` `"across"`, `"CLT C24"` `"along"`, `"CLT C14"` `"across"`, `"CLT C24"` `"along"`; a floor of it with panels 2.4 m wide laid side by side along y, spanning along x, has `"panels": {"width": 2400, "direction": 90}`, its main direction 0°. An L7s-2 layup, which no rule of alternation gives, is along, along, across, along, across, along, along. A wall over a wide opening whose outer layers run horizontally, so that it spans the opening as a beam, has `"mainDirection": "horizontal"`. The reasons: every structural tool that reads CLT needs the grain, and without it each guesses its own way, so two tools give two answers from one building; CLT is a common structural system for floors and walls, in Sweden among the first, and the reference implementation already offers CLT walls and floors in its library as one core layer each, the layup and the span direction left to the project, which this lets a model say; the panel division a slab already has is the natural carrier of its main direction, since CLT panels are made and laid along it, and defining `direction` settles a member the text leaves open; two optional members, and no change for a model without them. The cost: a validator rule for a slab with both `panels` and `mainDirection`, and a roof's rule, which needs its slope edge. **Written, 28 October 2026:** proposed for 0.2. [Part II, 5.1.1](https://openeik.org/spec/0.2/language#5.1.1), rules 1 to 8, behind the proposal `grain`: a layer's `grain`, `"along"` or `"across"`; a slab's, a ceiling's or a foundation's main direction square to its panels' `direction`, or its `mainDirection` where it has no panels, the two agreeing modulo 180 within 0.01° where it has both (`main-direction`), and none where it has neither; a wall's `"vertical"` or `"horizontal"`; a roof's fall line on each face, or its `mainDirection` projected onto it; `mainDirection` on no other category (`main-direction`); the order of the layers; what is product data; and that no body and no IFC4 print changes. [Part II, 6.3](https://openeik.org/spec/0.2/language#6.3): what `panels` means, its `width`, `direction`, `start` and `prefix` as the reference implementation reads them, into 0.1, since every 0.1 record that carries `direction` already means it so and the main direction rests on it; Part II, 5.1 points to 5.1.1. `schemas/proposed/grain/` holds the proposal's index and the members' schemas, kept out of the schemas of 0.1 as the proposal electrical keeps a view's `display.lighting` out. `@openeik/tools` checks them with the proposal (`grain`), its `mainDirectionOf` gives an element's main direction, and the conformance suite of the proposal (`conformance/proposed/grain/`) has 19 cases. The reference implementation writes neither member yet. 91. **Parts on any element.** A body an application gives (Part IV, 1.1.1, proposed for 0.2) may name the `part` of its element it is, and 1.1.1 named a door's or a window's parts alone: `frame`, `sash`, `glass`, `leaf`, `panel`, `casing` and `handle`. The schema of a result's bodies takes any name, and the bridge of `@openeik/tools` wrote an element's parts, whatever its category, as an IfcMaterialConstituentSet, a constituent and an IfcShapeAspect for each, though Part VIII, 1's note named only a door's and a window's. The reference implementation tags the bodies of other elements with parts too, and writes a single IfcMaterial for each in its own print: on its seven examples, a railing's `post`, `rail` and `baluster` (4 railings), the chords, struts, collars and heel posts of trusses written as beams (78), the `part-0` to `part-2` of an imported house's rafters, its framing family's parts (117), a rod's `shaft` (4) and a plate's `plate` (321). Where an element's bodies name one part, the bridge's set has one constituent, which adds nothing over a plain material. Raised 29 October 2026 by the reference implementation's IFC print compared with the bridge's on its seven examples (its work 727, step 4). The choice: keep `part` to doors and windows, and the reference implementation stops tagging other elements' bodies; or let any element's bodies name parts, and a bridge writes them as constituents where they are more than one. **Decided, 29 October 2026, as recommended** (the steward: "I övrigt dina rekommendationer förutom fråga 83 som du får repetera"): 1. An application's given body MAY tag `part` on the body of any element, not only a door's or a window's. 2. The bridge writes an IfcMaterialConstituentSet, with one constituent and one IfcShapeAspect per part, only where an element's bodies name two or more distinct parts. 3. Where they name one part or none, the element keeps the material it has without parts: its type's, or a plain IfcMaterial. 4. Doors and windows with the proposal `frames` have several parts, and are unchanged. The sets of one constituent the bridge wrote for plates (`plate`), rods (`shaft`) and the imported house's rafters (`part-0`) become plain materials. **Written, 29 October 2026:** [Part IV, 1.1.1](https://openeik.org/spec/0.2/compiler#1.1.1): `part` on the body of any element, by a name of the producer's, and an element's parts the distinct names its bodies give, of which one adds nothing to it; [Part VIII, 1](https://openeik.org/spec/0.2/bridges#1), its note on given bodies: an element's parts, and a type's representation's, as constituents and shape aspects where they are two or more, and its type's material where they are fewer. The schema of a result's bodies, `schemas/proposed/derived/bodies.schema.json`, says so of its tag `part`. `ifcOfModel` writes them so (`partsOf` in `src/ifc.js`), and its tests hold both cases, an element's and a type's. 92. **A railing's height in IFC.** IFC4 gives a railing a standard property for its height, `Pset_RailingCommon.Height`. The reference implementation writes it on each IfcRailing, its type's `railing.height` as an IfcPositiveLengthMeasure (`railingIfcProperties` in `src/core/io/railingIfc.ts`); the bridge of `@openeik/tools` wrote none, and Part VIII had no rule for a building element's standard properties but those an element was imported with (section 1, rule 5). Raised 29 October 2026 by the reference implementation's IFC print compared with the bridge's on its seven examples (its work 727, step 4). The choice: a rule in Part VIII, 1, which every bridge follows; or none, and the reference implementation drops the property. **Decided, 29 October 2026, as recommended** (the steward: "I övrigt dina rekommendationer förutom fråga 83 som du får repetera"): 1. An IfcRailing occurrence carries `Pset_RailingCommon.Height`: the railing's height as Part II gives it, as an IfcPositiveLengthMeasure in the print's units. 2. It holds to buildingSMART's rule PSE001: IFC4's template applies the set to IfcRailing occurrences, and types `Height` as an IfcPositiveLengthMeasure. 3. Where a bridge also prints the sets the railing was imported with, an imported `Pset_RailingCommon` joins the bridge's own (Part VIII, 1.5, rule 5). **Written, 29 October 2026:** [Part VIII, 1](https://openeik.org/spec/0.2/bridges#1), rule 6, a SHOULD, and a note; [1.5](https://openeik.org/spec/0.2/bridges#1.5), rule 5, which names the set among the bridge's own. The railing's height is its type's `railing.height`, to which its top rail carries it ([Part II, 12.2](https://openeik.org/spec/0.2/language#12.2); [Part IV, 11.2](https://openeik.org/spec/0.2/compiler#11.2), rule 5), and that is what the reference implementation writes. A railing's own `height`, which Part II, 6.2 says it takes "from type and payload", is not read for it: no rule of Part II makes it equal its type's `railing.height` (section 5.3 names no railing type among the types that set their elements' sizes). `ifcOfModel` writes the height so, and its tests hold the set to IFC4's template as PSE001 does; a print with a railing on a slab's edge passes IfcOpenShell 0.8.5's validation and buildingSMART's rules (release 1.0.2), PSE001 among them, with no issue. 93. **An application's own property sets.** The reference implementation writes property sets of its own on the objects it prints, data the model does not hold: `Stomra_IdentityAndParameters`, `Stomra_Railing`, `Stomra_Framing` and `Stomra_Electrical`. `ifcOfModel` took none, so a class the reference implementation moves to the bridge (its work 727) would lose them, unless it wrote them into the print afterwards, by a writer of its own. Raised 29 October 2026 by the reference implementation's IFC print compared with the bridge's on its seven examples (its work 727, step 4). The choice: an application adds its sets to the bridge's print afterwards; or the bridge takes them, as it takes the bodies an application gives, and writes them by rules that keep IFC's names and the bridge's own clear and the print's bytes the same. **Decided, 29 October 2026, as recommended** (the steward: "I övrigt dina rekommendationer förutom fråga 83 som du får repetera"): 1. `ifcOfModel(model, {sets})` takes the property sets an application wants on the objects it prints, data the model does not hold, as it takes `bodies`: keyed `elements/` and `types/`, each value `{: {: text | number | truth value}}`. 2. Each set is written on the object the print writes for that record, each value untyped by what it is: an IfcLabel (an IfcText over 255 characters), an IfcReal or an IfcBoolean. 3. A set may not be named with a prefix IFC or the bridge reserves: `Pset_`, `Qto_`, `Pset` in any case, `OpenEik_` and `Imported_`. Such a set is left out, and the fidelity report says so. A set of the name of one the bridge writes itself on that object is left out and reported too, not merged. An application names its sets with a prefix of its own, as the reference implementation's are. 4. The print is deterministic: the same bytes whatever the order of the input's members. Sets and properties go in the code-unit order of their names, and each set's GlobalId comes from a key of its record and its name. 5. A key that names no printed object is reported, not an error. Without the option, every print is unchanged. **Written, 29 October 2026:** [Part VIII, 1](https://openeik.org/spec/0.2/bridges#1), rule 7: a bridge MAY take an application's own sets, writes each value untyped by what it is, and MUST NOT write a set under a name that starts with `Pset` in any case, `Qto_`, `OpenEik_` or `Imported_`, nor under, or into, a set it writes itself on the object; an application SHOULD name its sets with a prefix of its own. Its note on `ifcOfModel(model, {sets})`: an element's sets on its product, a room's on its space, a type's as the own sets of each IFC type written for it, after the bridge's own and the imported ones; the keys of their GlobalIds, `app-pset::`, and a type's `app-pset:type::`, since one type may be written as several IFC types; and what is left out. `@openeik/tools`: the option `sets` (`applicationSets` and `reservedSetName` in `src/ifc-properties.js`), in the package's type declarations, with tests. 94. **IFC's electrical standard properties.** The reference implementation's IFC print writes three of IFC4's standard properties on electrical devices that the bridge of `@openeik/tools` did not: `Pset_ElectricalDeviceCommon.RatedVoltage`, 230 V on a device whose type has one phase and 400 V on one whose type has three; `Pset_ElectricalDeviceCommon.HasProtectiveEarth`, TRUE on an outlet whose `connector` is `type F`; and `Pset_OutletTypeCommon.IsPluggableOutlet`, TRUE on an outlet of the kind `outlet` whose type gives its sockets. Part XIII, 10 said only that the standard property sets are filled where IFC has them, and gave no rule for any of the three. A device's record carries no voltage: only its circuit has one (Part XIII, 3.1), and 230 V and 400 V are a country's values. Raised 29 October 2026 by the reference implementation's IFC print compared with the bridge's on its seven examples (its work 727, step 4). The choice: rows for the three in Part XIII, 10, each from a member of the records; or the reference implementation drops them. **Decided, 29 October 2026, as recommended** (the steward: "I övrigt dina rekommendationer förutom fråga 83 som du får repetera"): the three join Part XIII, 10 as rows. The voltage is taken from the circuit's `voltage`, and never assumed from a device's `phases`. **Written, 29 October 2026:** [Part XIII, 10](https://openeik.org/spec/0.2/electrical#10), a table of a device's standard properties, each with the member it is taken from and the object it goes on: 1. **RatedVoltage** is the `voltage` of the circuit that the device's `electrical.circuitId` names, the circuit that feeds it; a board's or a meter cabinet's names its feed. It is a bounded value, its upper bound, in volts, as the rated current is written. A device names one circuit at most, so none is on several. A device on no circuit, or on a circuit that gives no `voltage`, has none. 2. **HasProtectiveEarth** is its type's `earth`, proposed with this question (below). 3. **IsPluggableOutlet** is TRUE, an IfcLogical, where a plug fits the outlet: the kinds `outlet`, `dataOutlet` and `tvOutlet`, each with its sockets (Part XIII, 2.2). A ceiling outlet, where a light is connected, is plugged in some countries and wired in others, and is given none. 4. **Pset_OutletTypeCommon** goes on the outlet's IFC type, in its HasPropertySets: both its values are its type's. Its NumberOfSockets, which the bridge wrote on each outlet before, goes with it, for every kind of outlet whose type gives `sockets`, a data outlet's among them: `sockets` is an outlet's number of sockets (Part XIII, 2.2), and IFC4 gives the set to every IfcOutlet. The reference implementation writes NumberOfSockets for the kind `outlet` alone. 5. **A standard set** is written only on a class IFC4 applies it to, as buildingSMART's rule PSE001 holds it: Pset_ElectricalDeviceCommon on IfcDistributionElement and its subclasses, so not on a device of the kind `other` written as another class, nor on a device written as an IfcBuildingElementProxy. The table also names RatedCurrent, IP_Code and TotalWattage, which the bridge wrote already, unchanged. `@openeik/tools` prints them so (`src/ifc-electrical.js`). A print of `test/fixtures/electrical` with an earthed outlet type, 230 V on its circuit G1, and a data, a TV and a ceiling outlet gives no issue with buildingSMART's rules (release 1.0.2). **Proposed with it, 29 October 2026, for the steward to confirm:** a type's `electrical.earth`, `true` or `false`, whether the device has a protective earth: an earthing contact for a plug, or a terminal for a protective conductor. Absent, it is not said. Part XIII had no member that says it, and HasProtectiveEarth needs one. `connector` is a plain value whose values OpenEik does not list (Part XIII, 2.2), so no rule can read an earth from it. The reference implementation's own values show why: it reads TRUE from `type F` alone, while its `perilex` and `IEC 60309` outlets, which at mains voltage have an earthing contact too, get none. A cable's `earth` says whether the cable has a protective conductor, not whether the device it feeds has a contact or a terminal for one. Written in [Part XIII, 2.2](https://openeik.org/spec/0.2/electrical#2.2), its table and a note, and in `schemas/proposed/electrical/types/electrical.schema.json`, each marked as proposed; the electrical conformance suite has two cases of it. The reference implementation writes no `earth` yet, and the bridge writes HasProtectiveEarth only where a type gives it. **Decided, 30 October 2026** (the steward, in the openEik.org thread: "allt ja enligt din rekommendation"; section 4): a type's `electrical.earth`, as proposed. Part XIII, 2.2, its note and section 10's table, and the schema no longer call it proposed for him to confirm; it is proposed for 0.2 with the rest of Part XIII. 95. **Reading IFC into OpenEik.** Many buildings a project would start from exist as IFC, exported from an authoring tool. The bridge prints a model as IFC (Part VIII, 1), and no rule read IFC the other way: the reference implementation links an IFC file as a reference model, meshes to see and to measure against, and writes no record of it (Part VIII, 3). What should read IFC into records, how far, and how often? Raised 29 October 2026 in the reference implementation's thread on large models. The choice: (A) keep IFC a linked reference model, as the reference implementation does; (B) a converter that recognises each element as it reads, with a language model where a rule gives out, and keeps reading each delivery of the file, revision against revision; (C) a deterministic converter, with no language model in it, that starts a project from a file once, keeps what the file says of each object and its shape as the file draws it, and leaves recognising the elements to an assistant that reviews and upgrades the project afterwards. **Decided, 29 October 2026:** (C) (the steward, relayed from the thread "Stomra - Large models": "ok lets do it!"). 1. **Deterministic.** The same file gives the same records and the same bodies, byte for byte; no language model and no judgement of the reader's own is in it. 2. **Once.** A reader starts a project from a file. It is no live link, and it tracks no revisions between deliveries of the file. 3. **Reviewed afterwards.** An assistant, or a person, reviews what was read and upgrades it, rewriting an element in its category's own members where it recognises it. **Written, 29 October 2026:** proposed for 0.2. [Part VIII, 2](https://openeik.org/spec/0.2/bridges#2), behind the proposal `ifc-read`: what a reader writes (the project, a level for each storey, an element of the category its class maps to, the reverse of the bridge's classes, else `generic`, and a type for each IFC type); what it keeps (each object's GlobalId, class, predefined type and user-defined type in `ifcSource`, its property sets in this specification's units by the file's IfcUnitAssignment, its material by name); shapes (a product's shape a body given in the derived layer, Part IV, 1.1.1, never a record's own geometry, its record carrying `shape: "given"` and placed by members that say nothing of its shape; what a reader meshes itself, what it leaves to a mesher, and an object whose shape it cannot read kept without a body and named in the report; and how a compiler, a validator and a bridge read such an element); determinism (ids from GlobalIds, a stated order, no clock); the fidelity report; and recognising elements, class by class, as later rules. It adds two members of records, `shape` on an element and `predefinedType` and `objectType` in `ifcSource`, and no file: `schemas/proposed/ifc-read/` holds the proposal's index and their schemas. `@openeik/tools` reads IFC4 and IFC2X3 so (`eikOfIfc`), and applies the proposal in its compiler, its validator and its bridge (`proposals: ["ifc-read"]`). The decision did not say what a reader writes where a record of Part II cannot say an element without recognising it: Part VIII, 2.3 keeps the shape given, and the category's members a placement. 97. **The profiles of a door's or a window's frame and its mullions.** Question 89 leaves for 0.2, with the frame of [Part IV, 4.3.1](https://openeik.org/spec/0.2/compiler#4.3.1), a leaf's material, now its rule 14, and the profiles of a frame and its mullions, which shape the frame. Rules 3 and 4 draw each frame member, mullion and transom as a box, `frameWidth` (or `mullionWidth`) by `frameDepth`; a steel or an aluminium frame is a profile with chambers and rebates, a product's. The reference implementation has no profile yet: its members are boxes, and it names a profile system only as a plan of its work 749 ("No frame profile yet (a KKR, a named system): members are boxes of frameWidth × frameDepth"). So no profile can be written from it. Raised 30 October 2026 by the 0.2 plan's stream A. The choice: (A) an optional profile on the family, for its frame, its mullions and its sashes each, as an outline of the form of a `custom` section (Part II, 5.2) in the member's own section plane, swept along each member, the box of rules 3 and 4 its bounding box; (B) a named system only, a product's name, the bodies staying boxes, and the true section a supplier's declared geometry (Part II, 12.1); (C) neither in 0.2: the boxes stay, and a profile waits for a later version. **Recommended:** (A), written when the reference implementation builds it, as this specification follows the code: the body stays a class-A rule, a profile changes it within its box, and a supplier who does not share its section declares the envelope instead. Until then 4.3.1 keeps its boxes, which (C) says too. **Written, 30 October 2026:** decided that day as recommended, (A) (the steward: "allt ja enligt din rekommendation"), and proposed for 0.2, [Part IV, 4.3.1](https://openeik.org/spec/0.2/compiler#4.3.1), rule 15, with the proposal `frames`: an `openingFamily`'s `frameProfile`, `mullionProfile` and `sashProfile` and a `windowFamily`'s `frameProfile` and `mullionProfile`, each an outline of the form of a `custom` section's (Part II, 5.2, rules 8 and 9), its bounding box the width by the depth of the members it shapes, within 0.1 mm, none on a frame that follows its wall (`frames-profile`); the frame the ring of rule 11 round the outline it stands on, each member its profile carried along it and mitred at the corners, a door's jambs square on its bottom; a mullion and a transom as wide as `mullionWidth` the mullion profile from end to end, square, others and those of a shaped opening their boxes; a sash the ring round its light, mitred, but in a shaped opening. Every region in the wall's plane stays the boxes', and a profile shapes no leaf. Its schema is `schemas/proposed/frames/profile.schema.json`. It is written ahead of the reference implementation, which has no profile yet and follows. 98. **The derived layer's layout and a result's form.** Question 11 decided on 11 October 2026 to fix both in 0.2 (Part IV, 1.1), and gave no form. Part IV, 1.1 suggests `.eik/derived//.json` holding `{sources, producer, rule, result}`; Part IV, 1.1.1, proposed, gives a result's bodies in six kinds and keys results handed between tools `elements/` and `types/`, and leaves to 0.2 "whether it writes these, and where a type's result lies in `.eik/derived/`". `derivedLayer` of `@openeik/tools` writes one file per element at `/`, its sources keyed `/`, `referrers/` and `categories/`, its result the compiler's own bodies (Part IV, 8), quantities, line, railing, shaft openings and declared geometry; the reference implementation has no derived layer (section 2, row 8), and hands bodies only (`eikBodyResults`). And the 0.2 plan's decision D10 asks whether a version should carry an application's bodies, which rule 3 of 1.1 forbids. Raised 30 October 2026 by the 0.2 plan's stream A, which could not write the layout without these. The choices: (a) the layout: by category, as 0.1 suggests, or keyed as sources are, `.eik/derived/elements/.json` and `.eik/derived/types/.json`; (b) a result: bodies alone, in 1.1.1's kinds, or with quantities and lines, and the compiler's own forms beside them or not; (c) the source keys: `/` alone, or with `referrers/` and `categories/`; (d) several producers in one folder: one result per record, whichever wrote it last, or one per producer; (e) D10: derived results stay out of versions, or a version carries them. **Recommended:** (a) keyed as sources, an id written as a path segment (Part III, 2), so that a type's result has its place and a result's path says its key; (b) `{sources, producer, rule, result}`, its result `{bodies, quantities?, line?}`, bodies in 1.1.1's kinds only, so that what one tool writes another reads; (c) the three key forms, which make a result stale when an opening is added to its wall or a shaft to its slab; (d) one result per record, naming its producer and rule, which a reader that wants its own rules' result compares and derives again where they differ; (e) out of versions, as rule 3 says: every body a print needs gets a rule instead. **Written, 30 October 2026:** decided that day as recommended, (a) to (e) (the steward: "allt ja enligt din rekommendation"), and proposed for 0.2 with the proposal `derived`, [Part IV, 1.1.2](https://openeik.org/spec/0.2/compiler#1.1.2): rule 1, an element's result at `.eik/derived/elements/.json` and a type's at `.eik/derived/types/.json`, its id a path segment, its path less `.eik/derived/` and `.json` its key; rule 2, `{sources, producer, rule, result}`, its result `{bodies, quantities?, line?}`, the bodies in 1.1.1's kinds alone, and nothing else; rule 3, the sources `/`, `levels` and `project`, `referrers/` and `categories/`, each with its hash or `null`, its own record among them; rule 4, current while each holds; rule 5, one result per record, a writer's in place of another's, a reader that wants its own rules' result comparing producer and rule; rule 6, the 0.2 plan's D10, never in a version, a host printing a version by this specification's rules and every body a print needs getting a rule in its time. Part IV, 1.1 and 1.1.1 point to it; `schemas/proposed/derived/bodies.schema.json` is the whole result's schema, and the proposal's index names both paths. `derivedLayer` of `@openeik/tools` writes the layout and the form, the compiler's bodies in 1.1.1's kinds (`derivedBodies`), and `readDerived` reads a folder's layer (`derived-path`, `derived-form`, `derived-stale`). 99. **What a component's class-A frame and shank are where the records do not say.** Question 73, decided on 26 October 2026, makes every component's frame a class-A rule "as the reference places it", and a box, a plate, a weld's fillet and each bolt's shank, "a cylinder of its diameter along z", class-A bodies, a bolt's head, washers and nut staying reference behaviour, being sized from a table no record holds. Two things the reference's code does cannot be written from the records. (a) **The shank's ends.** The reference runs a hex bolt's shank from under its head's washer, whose thickness its table of ISO bolts gives, for the group's `length`, else for a length the same table picks; an anchor's and a rod's run between ends worked out from that table too (`assemblyPieces` and `rodSpan` in `src/core/elements/bolts.ts`). (b) **`axes` on a component of a family without a shape of its own.** Part II, 6.3 says `axes` is a component's own frame, taking the place of its orientation; the reference places a plate, a bolt group and a weld by it, and a box (a timber section, a void form) by its profile, its `axes` not read (`componentSolids` in `src/core/elements/components.ts`), its validator saying "Axes belong to a plate, a bolt group or a weld". So the 0.2 plan's stream A did not write question 73's rules (its R13). Raised 30 October 2026. The choice for (a): (A) the shank within the grip, from z = 0 to `grip`, which every bolt has whatever a table says, and which is what the members it passes through are drilled for; (B) from z = 0 for the group's `length`, only where the group gives one, and no class-A shank without it; (C) the reference's shank, with its table of washers, heads, nuts and lengths written into this specification. For (b): (A) `axes` is every component's frame, as Part II, 6.3 says, and the reference changes for a box; (B) `axes` belongs to a plate, a bolt group and a weld, a validator warns of it on another component, and Part II, 6.3 says so. **Recommended:** (a) (A): a class-A body is one any tool derives from the records alone, and the grip is what a clash or a hole check needs; the head, the washers, the nut and the shank past the grip stay the reference's, as decided. (b) (A): a timber section along a brace, or a void form on a sloped face, needs a frame of its own as a plate does, and the text says so already. **Written, 30 October 2026:** decided that day as recommended, (A) for both (the steward: "allt ja enligt din rekommendation"), and proposed for 0.2 with the proposal `components`, together with question 73's rules, as [Part IV, 7.6](https://openeik.org/spec/0.2/compiler#7.6): rule 1, a component's frame and its bodies by its family, and a validator's warning of one without a frame (`component-frame`); rule 2, its frame, `axes` for every component whatever its family, else its profile in plan, flipped to the right; rule 3, a plate on a column, on its centre at its top plus the plate's offset; rule 4, `componentInverted` and `upright`; rule 5, a cast-in item's frame by `insertAt`, its point, its ways, its tilt and its row, its `profile`, `levelId` and `offset` its writer's copy; rule 6, a timber section's box; rule 7, a plate's outline less its holes, a weld's fillet, each bolt's shank from z = 0 to `grip`, and a cast-in item's block and bar; rule 8, what stays reference behaviour, the head, washers and nut and a shank past its grip among it. Part II, 6.3, Part IV, 7.2 and Part VIII, 1's note on components point to it. A cast-in item's block and bar, which question 73 named neither a rule nor left to reference behaviour as it left a lattice tie and a conduit, are written as rules: a box and a round bar, from the records alone. `compileModel` of `@openeik/tools` derives the bodies with the proposal (`compile-components.js`), `ifcOfModel` writes them by rule, and a validator warns `component-frame`. The reference implementation changes for (b): it reads `axes` on a timber section. 104. **A wall's body at its corners and tees.** [Part IV, 4.1](https://openeik.org/spec/0.2/compiler#4.1) shapes a wall's layers "at their ends by joins", which [Part IV, 2](https://openeik.org/spec/0.2/compiler#2) puts in class B and [7.1](https://openeik.org/spec/0.2/compiler#7.1) leaves to reference behaviour, so a compiler of 0.1 ends a wall square. [Part IV, 7.4.2](https://openeik.org/spec/0.2/compiler#7.4.2), proposed for 0.2 with the proposal `framingLayout`, states the reference implementation's corners and tees exactly, and the line each joined end stops on, for what a framed layer reads of them; [7.5](https://openeik.org/spec/0.2/compiler#7.5), rule 1 ends a wall's plan on those lines to bound rooms. Neither changes a wall's body. The reference implementation ends every layer's body on them. A wall without a `wallOutline` is cut into bands at the heights where its end's line changes, and in each band every point of a layer within 0.01 mm of the wall's end moves along the wall onto the line, as far as 7.5, rule 1 lets a wall's plan move; the band is then cut on the line. A wall with a `wallOutline` stops on one line over its whole height, its main corner's or its T's. At a T, the host's layers between its face on the branch's side and its core face give way between the branch's two faces, from the branch's base up by the branch's `height`; a host with a `wallOutline` gives no way. `@openeik/tools` finds the joins of 7.4.2 for framing and rooms, and still ends every wall square, so that "walls that meet overlap or leave gaps at their corners and tees", as its compiler's note and its bridge's fidelity report (`wall joins`) say. Raised 30 October 2026, for 0.3, by the 0.2 plan's decision D13: the reference implementation's work 727 lists wall joins among the bodies that stay its own. The choice: (A) joins stay reference behaviour, and a bridge takes an application's bodies where walls meet; (B) 7.4.2 becomes class A for which ends meet and where they stop, and a wall's body stays square; (C) a wall's layers end on 7.4.2's lines as the reference ends them, and a host gives way at a T. **Recommended, for 0.3:** (C), in Part IV, 4.1, with wall corner and T joins in class A (Part IV, 2): 1. **The joins.** Section 7.4.2 becomes a section of its own, which 4.1, 7.4 and 7.5 read alike, and 7.1 its note. No record changes: `joinEnds` still keeps an end free. 2. **A joined end.** Each layer's body, each piece of it between openings (4.3) apart, ends on its end's lines as 7.5, rule 1 ends a wall's plan: cut into bands where the line changes, its points at the end moved along the wall to the line, and the band cut on it. An end with no corner and no T, and an end kept free, stays square. A wall drawn by its outline ends, where the outline reaches the wall's end, on its main corner's line (7.4.2, rule 5) or its T's. 3. **A T's host.** Each layer of the host between its face on the branch's side and its core face (7.4.2, rule 7) loses the prism between the branch's two faces, from the branch's base up to its top (sections 5.1 and 5.3). A piece of 1 mm² or less in plan is none. The reference's host gives way only up to the branch's base plus its `height`, which an attached branch's top may pass or fall short of, and not at all where it is drawn by its outline, which leaves the branch's layers inside it; the rule does neither, the reference changes, and so does 7.4.3, rule 8, which takes the same height for a framed layer. With the rule, `ifcOfModel` derives every wall's body. Reference: `joinedWallSolids` and `teeCutSolids` in `src/core/elements/wallJoinSolids.ts`; `wallEndLines`, `wallJoinCoordinate`, `teeBranches` and `coreFaces` in `src/core/elements/wallJoins.ts`; `profileSolids` in `src/core/geometry/profileGeometry.ts`. In `@openeik/tools`: `wallJoins` in `packages/openeik/src/compile-framing-joins.js`. 105. **Fittings between pipe and duct runs.** [Part IV, 12](https://openeik.org/spec/0.2/compiler#12) makes a run's body, its own bends included, a class-A rule, and leaves to reference behaviour (class B, [Part IV, 2](https://openeik.org/spec/0.2/compiler#2)) "the fittings found between runs". The reference implementation finds them on every read, pipes and ducts together, whatever their systems. Two ends meet where one lies within the larger of 5 mm and half its own run's `mep.size` of the other: a reduction where their sizes differ, else a bend where the runs turn by more than 1°, else a joint. An end that meets no end of another run is a branch on it where it lies within the larger of 5 mm and half either run's size of one of that run's inner points, or of a piece of it, its foot strictly between 2 % and 98 % of the way along. A run's own corner of 1° or more is a bend too, made of its type's standard bends (`pipe.bends`, `duct.bends`): one within 2.5° of the turn, else two that add up to within 2.5° of it, the first found in the list. A fitting has no body; the reference lists, counts and checks them, and writes none in IFC. Its pairs follow the order of elements: the run first in the list holds an end-to-end fitting and gives it its system and its bends; two ends that meet but round to different whole millimetres can make two fittings; three ends at one point make three. `@openeik/tools` derives none, and neither print joins a run to another. Raised 30 October 2026, for 0.3, by the 0.2 plan's decision D13 (the reference implementation's work 727, its table of bodies that stay its own). The choice: (A) fittings stay reference behaviour; (B) they are found by rule, as data without a body, for schedules, checks and IFC; (C) they are found by rule, with bodies sized from a table of products. **Recommended, for 0.3:** (B), in Part IV, 12: 1. **What meets.** Pipes with pipes and ducts with ducts, of one system (Part II, 6.9), by their points at their heights (12.1, rule 1). With t the larger of 5 mm and half the larger of the two runs' `mep.size`, two ends meet where they lie within t of each other, and an end lies on another run where it meets none of that run's ends and lies within t of its points joined straight. 2. **Its kind.** Two ends that meet make a reduction where their sections differ (a size, a rectangle's height, a round against a rectangle), else a bend where the runs turn by 1° or more, else a joint; an end on another run makes a branch; three ends or more that meet, or an end on two runs, make one junction. A run's own corner of 1° or more is a bend; its body stays 12.2's. 3. **A bend's standard bends**, from the type of the run whose id comes first in code-unit order: the single angle nearest the turn within 2.5°, else the nearest pair within 2.5°, of equal pairs the one with the larger first angle. 4. **Its record:** its kind; its place, the meeting end of the run whose id comes first, or a branch's end; its runs by id, a branch's host first; its system, sizes and turn; listed by their first run's id, then along that run. 5. **No body.** A fitting's body is its product's (class C), or declared geometry (Part II, 12.1); a run's volume and length stay its own (12.4). Part VIII, 1.1 then writes each as an IfcPipeFitting or an IfcDuctFitting, BEND, TRANSITION, CONNECTOR or JUNCTION, with a port for each run it joins, connected to a port of that run. The reference changes where it reads the order of elements, mixes categories and systems, compares a rectangular duct by its width alone, and misses a branch near a piece's end. Reference: `mepFittings`, `bendsFor`, `mepChecks` and `mepLists` in `src/core/elements/mep.ts`; a run's ports in `exportIfc` in `src/core/io/ifcExport.ts`. 106. **A bar's shape.** A rebar element's `bars` (Part II, 6.3) holds a national shape code, `shape` (open question 4); the `dims` that code orders it by, `a` to `g`, `x` and `y` in mm and `v`, `u`, `s` and `t` in degrees; its `diameter`; and `origin`, `xAxis`, `yAxis`, and `count` bars `spacing` apart along `along`. The note on [Part II, 6.1](https://openeik.org/spec/0.2/language#6.1) and [Part IV, 7.2](https://openeik.org/spec/0.2/compiler#7.2) leave how bars bend to reference behaviour: no record says what a code's dimensions mean, so no rule gives a bar a body or a length. The reference implementation takes `shape` from the 29 letters of a Swedish bending sheet. Each letter is a function from the dimensions, and the diameter where its figure needs it, to the bar's legs: a polyline of outer dimensions in its plane, x along `xAxis` and y along `yAxis` made square to it. A dimension the record leaves out takes the letter's default. Nine letters are laid out only roughly, and five take their cut length from the sheet's formula. The body is a tube along the legs, its corners bent to a mandrel of 4 diameters up to 16 mm and 7 above (EN 1992-1-1, 8.3), the radius shrinking where a leg is too short; the outer dimensions are drawn as the centreline. The cut length is the legs less 2 (r + d) tan(θ/2) − (r + d/2) θ at each bend, r half the mandrel. Its IFC is an IfcReinforcingBar of that length, its predefined type by its letter. `@openeik/tools` writes each bar's first leg, `dims.a` along `xAxis`, as a rod, approximated. Raised 30 October 2026, for 0.3, by the 0.2 plan's decision D13 (the reference implementation's work 727, its table of bodies that stay its own). The choice: (A) a bar's shape stays reference behaviour: an application maps the codes it knows; (B) a list of shape codes in the standard, which open question 4 refused; (C) the bar's own geometry in its record, its centreline and its mandrel, written by whoever knows the code, from which every reader derives its body and its length. **Recommended, for 0.3:** (C), two members of `bars` and class-A rules in Part IV: 1. **Its legs.** `bars.legs`: two points or more, `[x, y]` or `[x, y, z]` in mm, its centreline as straight legs, each inner point where two legs' centrelines meet; in the frame whose origin is `origin`, x `xAxis` made a unit vector, y `yAxis` made square to x and a unit vector, and z x × y. A hairpin's turn of 180° is two right angles with a leg of `mandrel + diameter` between them. 2. **Its bends.** `bars.mandrel`, the mandrel's diameter in mm, which `legs` requires. Each inner point is an arc of the centreline of radius R = `mandrel`/2 + `diameter`/2, tangent to both legs. A leg shorter than its bends take of it, R tan(θ/2) at each bent end, makes no bar, and a validator says so. 3. **Its body** is a circle of `diameter` swept along that centreline, and the set `count` such bars, the i-th, from 0, moved i × `spacing` along `along` made a unit vector. **Its cut length** is the legs' lengths less 2 R tan(θ/2) − R θ at each bend. 4. **Its code.** `shape` and `dims` stay what the bar is ordered and scheduled by, national values. A writer that knows the code writes `legs` and `mandrel` from it; a reader derives nothing from the code. Without `legs`, the body stays reference behaviour. A bar bent to a curve (a spiral, an arc), and what a bar is for, which the reference reads from its letter, wait for members of their own. The rule adopts no dimension from a default, no radius that shrinks, and no outer dimension drawn as the centreline, which stands each bend half a diameter outside it; the reference writes `legs` and `mandrel` from its letters. Part VIII, 1 then writes the body as a swept disk, the cut length as BarLength, and the code and dimensions as BendingShapeCode and BendingParameters on its type. Reference: `shapes`, `shapeDims`, `mandrel` and `cutLength` in `src/core/elements/rebarShapes.ts`; `barPolylines`, `barSolids` and `validateBars` in `src/core/elements/bars.ts`; `reinforcementIfc` in `src/core/elements/reinforcementIfc.ts`. 107. **Terrain and grading.** Of the site, only the ground is class A: [Part II, 6.3](https://openeik.org/spec/0.2/language#6.3) makes a terrain's ground the Delaunay triangulation of its points in plan, clipped to its outline, and leaves undefined which ground is on top where terrains overlap. Nothing says what a grading element's `slope`, `fall`, `order`, `ring` and `retained` do. The reference implementation keeps the triangles whose middle lies inside the outline, rather than clipping them, takes points that round to one whole millimetre in plan as one, and puts the terrain later in the list of elements on top. Each grading element is a pad, applied by its `order`, 0 where absent, and of one order in the order of elements. A pad's plane is its level's elevation plus its `offset` at its outline's first point, or, where `fall.at` is `high`, at its point least far along `fall.toward`, falling `fall.permille` ‰ along `toward`; it is level with a `ring`. Inside its outline a pad is its plane. Outside, at a distance d from the outline, e the plane's height at its nearest point: with a ring, e − d/ratio up to its `width`, then e and d from the ring's edge; where `retained`, the height so far; else the height so far held between e − d/slope and e + d/slope, a batter of 1:`slope`, 1:2 where absent. No pad's ring or batter changes a point inside another pad's outline. Roads and parking then grade it too. The reference samples the graded ground on a grid of 200 mm or more, of about 200 000 nodes, and takes fill and cut from each cell's mean of its corners' graded height less the ground's; it digs pits by the project's `excavation`, and counts topsoil and backfill. Its IFC writes the graded ground from that grid as one IfcGeographicElement TERRAIN, on the terrain whose id comes first. `@openeik/tools` derives no ground, and its bridge writes none. Raised 30 October 2026, for 0.3, by the 0.2 plan's decision D13 (the reference implementation's work 727, its table of bodies that stay its own). The choice: (A) the graded ground stays reference behaviour; (B) the ground and the pads become rules, and cut and fill stay the application's; (C) the ground, the pads, and cut and fill become rules, and excavation, topsoil and roads wait. **Recommended, for 0.3:** (C), class-A rules in Part IV, and the meaning of `grading` in Part II, 6.3: 1. **The ground** is Part II, 6.3's, clipped exactly. Points within 0.01 mm of each other in plan are one, the first in the list kept; where terrains overlap, the one whose id comes first in code-unit order is the ground there; a validator warns of both. 2. **The pads,** each grading element of three points or more, are taken by `order`, lowest first, and of one order by id in code-unit order. 3. **A pad** is the reference's above: its plane, ring, batter and retaining wall. Of several equal points, the first in its outline is its origin and the first along its outline its nearest; `toward` is made a unit vector. 4. **The graded ground** at a point is the ground there, then each pad in turn, but that no pad's ring or batter changes a point inside another pad's outline. 5. **Cut and fill** are the volumes, in m³, where the graded ground lies under the ground and where it lies over it, each taken separately at every point. A compiler draws the graded ground in triangles, and measures cut and fill, within tolerances that cases from the reference's sites fix, as Part IV, 12.5 fixes a run's. The rule adopts neither the order of elements, nor whole-millimetre rounding, nor triangles kept by their middles, nor a grid whose cells net cut against fill and whose nodes let a batter move another pad's flat by up to 1 mm; the reference changes. Pits, topsoil, backfill and roads wait for rules of their own; Part VIII, 1 writes the graded ground as the reference does. Reference: `tin` and `outlineDistance` in `src/core/site/surface.ts`; `groundSurface`, `padHeightAt`, `padPlane`, `applyPad` and `buildSite` in `src/core/site/siteModel.ts`; `gradingElementSchema` and `DEFAULT_BATTER` in `src/core/site/siteElements.ts`; `gradeToRoads` in `src/core/site/siteRoads.ts`; `ifcProducts` in `src/core/io/ifcScope.ts`. 110. **A member between two points.** A beam is set out on its underside, from its level and offset at its start, over a run in plan of 10 mm or more, rising by its `endRise` (Part II, 6.1, rule 2; Part IV, 6.2), and a column stands plumb on its base (Part IV, 6.1). Neither records a brace, a strut or a tie that runs steeply or plumb, nor a truss's member in any direction: an analysis application that writes OpenEik from finite element models (Femra) writes its braces as sloping beams, and has nothing for a member that is plumb or nearly so but not a column; and the reference implementation's columns do not lean. The steward decided on 17 October 2026 that 0.2 has a member between two points in space, without a record's shape (`CHANGELOG.md`, the plan for 0.2). Raised as D6 by the 0.2 plan, 29 October 2026. The choice: (A) beams for every linear member, and columns that lean: two records, each stretched to what it was not set out for; (B) one rule for linear members in any direction: a line of two points in space, each a plan point, a level and an offset, so that a vertical or a steep member is defined, and a category `member` for what is neither a beam nor a column (a brace, a strut, a tie; IfcMember), sharing Part IV, 6's reference line, axis, roll, taper and joins; beams and columns keep their records, and a beam's `endRise` is the same line written another way. **Recommended:** (B). **Decided, 30 October 2026, as recommended:** (B), for 0.2 (the steward, on the openEik.org thread: "allt ja enligt din rekommendation"). The analysis application, its first writer and reader, asked four things of the rule: (1) its start and its end are points in space, in mm, z from a level as elsewhere, on the reference line through the middle of the section's box, Part IV, 6.5, rule 2's line, so that the axis rule (6.5, rule 5) holds unchanged; (2) its roll is measured from a beam's zero, the section's x across, the left normal of the plan direction, and a plumb member's zero is written, a column's (its depth along plan y before its turn) would do; (3) its record says nothing of its ends: joints, releases and supports stay where they are, its own `femra:supports` on the element, and its extension members `femra:taper` and `femra:section` carry over to a member as they do to a beam; (4) old members keep their meaning: a beam with a rise and a column are read as before, it writes `member` for braces, struts, truss members and anything leaning that is not a column, with the proposal `member`, and one element is never both a beam and a member. **Written, 30 October 2026:** proposed for 0.2. [Part II, 6.2.1](https://openeik.org/spec/0.2/language#6.2.1), rules 1 to 8, behind the proposal `member`: the category, in `structure`; its type's `section`, and no other payload; its line, its profile's two points at its `levelId` and `offset` and at its `end`'s, `{levelId, offset}`, on its reference line and 10 mm apart or more (`member-length`); plumb where its plan points lie within 10⁻⁶ mm, a writer writing them equal, and a validator warning of points under 1 mm apart that are not (`member-plumb`); its `height` its section's depth; `roll`, `taper` and `joins`, and none of `endRise`, `turn`, `base` and `connection`; nothing of its ends; one element for one piece. [Part IV, 6.7](https://openeik.org/spec/0.2/compiler#6.7), rules 1 to 9: its line; its frame, a beam's `n` and the up square to the line where it is not plumb, the model's x and `t × x` where it is, so that a plumb member running up is a column's section before its turn; its roll, right-handed about its line; its body, the middle of its section's box on its line; a taper centred on the line; its axis; its joins, a mitre between any two of a beam, a column and a member; what it measures; and a column's and an untapered beam's lines as a member's, of the same body and axis. Part IV, 6.2, rule 5 now says which way a roll turns, right-handed about the line, as the reference implementation and `@openeik/tools` turn it. [Part VIII, 1.9](https://openeik.org/spec/0.2/bridges#1.9), rule 1: an IfcMember, NOTDEFINED, its section an IfcMaterialProfileSet on its IfcMemberType. Part I, 4 and Part III, 4.4, rule 2 point to it. `schemas/proposed/member/` holds the proposal's index and the category's two schemas. `@openeik/tools` checks, files, builds and prints members with the proposal (`member`), and the conformance suite of the proposal (`conformance/proposed/member/`) has 23 cases. The four asks are met: (1) by Part II, 6.2.1, rule 3 and Part IV, 6.7, rules 1, 4 and 6; (2) by Part IV, 6.7, rules 2 and 3; (3) by Part II, 6.2.1, rule 7, a record keeping any extension member (Part I, 11.2); (4) by Part II, 6.2.1, rule 8 and Part IV, 6.7, rule 9. A tapered member's sections stand square to its own line, a tapered beam's to its set-out line: the one place where a beam and the member along its reference line differ. The reference implementation has no member yet (Part II, 6.2.1, its note). 111. **A slab on a sloped plane.** A slab's top is level, at its level plus its offset (Part I, 4; Part IV, 4.2). A ramp, a sloped floor or deck, and an analysis model's plate that is neither level nor a roof can only be written as a roof, whose category, IFC class and rules say something else, or approximated in level pieces. The steward decided on 17 October 2026 that 0.2 has slabs on a sloped plane, without a record's shape (`CHANGELOG.md`, the plan for 0.2). Raised as D7 by the 0.2 plan, 29 October 2026. The choice: (A) a sloped slab written as a roof; (B) a slab may carry a plane, given as a roof's slope-defining edge is (an edge of its outline and a slope, or a rise over a run), its layers laid square to the plane over its plan outline and cut plumb at its edges, its top and its openings placed by Part IV, 4.4's plane rules, so that roofs and sloped slabs share one plane rule and one quantity rule; (C) a slab whose outline's points each carry a height. **Recommended:** (B). **Decided, 30 October 2026, as recommended:** (B), for 0.2 (the steward, on the openEik.org thread: "allt ja enligt din rekommendation"). The analysis application, its first writer and reader, asked four things of the rule: (1) a plane may also be stated by its slope in degrees, the direction it falls in plan and its height at the profile's first point, as an equal way of stating it, since a skewed ramp or a triangle has no level edge to slope from, and a reader derives one form from the other; (2) the rule says which face the plane describes, the top or the underside, and that the thickness is measured square to the plane, as a roof's; (3) on a sloped slab, open question 90's `panels.direction` and `mainDirection` are directions in plan projected vertically onto the plane, as a roof's fall line is; (4) a level slab is of slope 0, and nothing changes for it. **Written, 30 October 2026:** proposed for 0.2. [Part II, 6.3.1](https://openeik.org/spec/0.2/language#6.3.1), rules 1 to 7, behind the proposal `slopedSlab`: a slab's `plane`, its gradient as `slope` or as `rise` over `run`, at most 75°, and its direction as `edgeId`, the edge its top rises from into the outline, or as `fall`, the direction it falls in plan, each exactly once; its top at the slab's level plus its offset along that edge, or at its profile's first point; either form one plane, its slope, its fall and its height at the first point; the plane its top face, its thickness square to it; a level slab of slope 0; only a slab carries it (`slab-plane`), and one whose plane slopes hosts no slab edge element in 0.2 (`slab-plane-edge`); and its grain projected onto it. Part II, 5.1.1, rule 2 says so of a sloped slab's main direction. [Part IV, 4.2.1](https://openeik.org/spec/0.2/compiler#4.2.1), rules 1 to 7: its layers between the plane lowered by their depths times √(1 + g_x² + g_y²), over the outline, plumb at its edges; its voids and the shafts through it; its edges trimmed to a wall's face; a pitched roof's quantities, `slopedArea` beside its `area` in plan; the rules that read its top read its plane (an attached column base and wall top, a railing on its outline, a room's ceiling), and the floors a level stands on its level plus its offset; no slab edge element, thickened edge or chamfer's fill on it, and, with the proposal `framingLayout`, no joists and no framed wall bearing on it; a level slab as in 0.1, and a plane that cannot be read giving no body. [Part VIII, 1.9](https://openeik.org/spec/0.2/bridges#1.9), rule 2: an IfcSlab as a level one, its layers' bodies between their planes. `schemas/proposed/slopedSlab/` holds the proposal's index and the member's schema. `@openeik/tools` checks, builds and prints sloped slabs with the proposal (`slopedSlab`), and the conformance suite of the proposal (`conformance/proposed/slopedSlab/`) has 16 cases. The four asks are met: (1) by Part II, 6.3.1, rules 1 to 3, `fall` and the profile's first point; (2) by rule 4: the top, the thickness square to the plane; (3) by Part II, 5.1.1, rule 2 and 6.3.1, rule 7; (4) by Part II, 6.3.1, rule 5 and Part IV, 4.2.1, rule 7. Left for a later version: a slab edge element, a thickened edge and a chamfer's fill along a sloped slab's edge, and a sloped slab's joists, which rule 6 keeps off it in 0.2 rather than build them by rules made for level slabs. The reference implementation has no sloped slab yet (Part II, 6.3.1, its note). 115. **The reference implementation's members outside the specification.** The reference implementation writes members, categories, a value and a reference that this specification describes nowhere (section 2, row 20; `LATER` in `tools/generate-schemas.mjs`): at the 0.2 plan's count, 27 member paths, the categories `person` and `provision`, the value `clt` of a material's and a layer's `pattern`, and the reference that a bolt group's `bolts.through` holds. In 0.1 the members are its own written without a prefix, which Part I, 11.2, rule 2 does not allow, and the categories and the value are what rule 6 leaves to versions of this specification; another tool keeps them and warns (Part I, 10), and does not know what they mean when it reads, draws, checks or prints the building. Raised 30 October 2026 by the 0.2 plan (its decision D8, item R26). **Decided, 30 October 2026, as recommended** (the steward: "allt ja enligt din rekommendation"): one rule decides each. What another tool needs to read, draw, check or print the building joins 0.2. What only the reference implementation's own interface reads moves under its registered prefix, `stomra` (Part I, 11.1; `registry/extensions.json`), as an extension member. The two categories follow the 0.2 plan's decision D9, decided the same day: `provision` becomes a category of the standard, and `person` a `generic` element whose type stands for a person (Part II, 6.6), with no category of its own. The list, one line for each member path, category, value and reference: | What | Decision | Why | |---|---|---| | element `notches` | 0.2: Part IV, 4.6, rules 12 to 14 | it cuts down a slab edge element's upstand and facing, and the fill its host casts with them: a tool that derives, quantifies, draws or prints the element's body needs it | | element `castWith` | 0.2: Part II, 14.1, and a reference (Part II, 7) | a section of two elements cast in one pour draws no line between them: a tool that draws the section needs it | | element `person` | `stomra:person` | a person's free-height limit, which only the reference implementation's interface reads (its inspector and its 3D view); a person is a `generic` element (D9) | | element `provision` | 0.2, with the category `provision` (D9) | a provision for a void and its answer: written by its own change | | type `person` | `stomra:person` | the figure the reference implementation draws a person by, a file of its own; the person's height is the type's own `height` | | type `terminal.tagSize` | 0.2: Part II, 14.6 | whether a terminal's tag gives its size: a tool that draws a plan's tags needs it | | type `layers[].drawing` | 0.2: Part II, 14.2 | the detail family a layer's cut is drawn with in a drawing of its type's build-up: a tool that draws that drawing needs it | | view `display.colours` | `stomra:colours`, in `display` | the reference implementation's colour mode, as its interface shows a view in colour, grey or black and white | | view `display.electrical` | 0.2: Part II, 14.3, rule 1 | which electrical devices a plan draws: a tool that draws or prints the plan needs it | | view `calloutShape` | `stomra:calloutShape` | the mark of the reference implementation's detail callout, which its drawing standards set (the project's `standards`, an application value, Part II, 9.2) | | view `calloutLabelOffset` | `stomra:calloutLabelOffset` | where that mark's label stands, moved by hand in its interface | | view `breakLines` | `stomra:breakLines` | the dash-dot break lines on that callout's crop, a look of the same drawing standard as the mark's | | view `calloutCornerRadius` | `stomra:calloutCornerRadius` | the rounding of that mark's rounded form | | view `assembly.pitch` | 0.2: Part II, 14.3, rule 4 | the pitch a roof type's build-up is drawn at: a tool that draws the drawing needs it | | view `display.levelLabels` | 0.2: Part II, 14.3, rule 2 | whether a section's level lines carry their heads: a tool that draws or prints the section needs it | | view `display.sideMarks` | 0.2: Part II, 14.3, rule 3 | whether a drawing of a build-up marks its sides: a tool that draws it needs it | | view `lineWeights` | 0.2: Part II, 14.3, rule 5 | whether a view is drawn with its line weights or in thin lines, which the recommendation named for 0.2: a tool that shows the view needs it. The reference implementation reads it on screen only, and prints the line weights whatever it says | | view `camera` | 0.2: Part II, 14.3, rule 6 | a 3D view's perspective camera: a tool that shows or renders the view needs it | | detail item `cloud` | 0.2: Part II, 14.4, rule 1 | a revision cloud and its tag, which a drawing prints | | detail item `schedule.headings` | 0.2: Part II, 14.4, rule 2 | a schedule's column headings, which a drawing prints | | detail item `legend.title` | 0.2: Part II, 14.4, rule 3 | a legend's heading, which a drawing prints | | detail item `buildUp` | 0.2: Part II, 14.4, rule 4 | a build-up text worked out from a type: a tool that draws the view writes it | | detail item `follows` | 0.2: Part II, 14.4, rules 5 and 6 | the instance of a group a 2D item moves and turns with: a command processor that moves the instance (`copy.move`, Part V) needs it | | detail item `cutBy` | 0.2: Part II, 14.4, rule 7 | the instances of groups whose floors a region is cut by: a tool that draws the region needs it | | detail item `notDimension` | 0.2: Part II, 14.4, rule 8 | a text that measures nothing: a tool that checks a drawing's dimensions needs it | | detail family `dimensions` | `stomra:dimensions` | the dimensions the reference implementation's family editor shows a family's bindings by and makes them with; the bindings are the geometry | | detail family `insertion` | 0.2: Part II, 14.5 | the point a placed copy hangs on: a tool that draws a placed copy needs it | | category `person` | no category: a `generic` element whose type stands for a person (D9) | scale figures, which a `generic` element and its declared geometry say | | category `provision` | 0.2 (D9) | a void a run asks of the part it crosses, and its answer: written by its own change | | value `clt` of a material's and a layer's `pattern` | 0.2: Part II, 4, rule 4 | the hatch of cross-laminated timber: a tool that draws a cut needs it | | reference `bolts.through` | 0.2: Part II, 7 | the elements a bolt group passes through and drills: a tool that cuts their holes, checks the joint or prints it follows it | The 27 member paths are those `LATER` held on 30 October 2026, reviewed against the reference implementation at `bcfd44c7`: 19 join 0.2, `provision` among them, and 8 move under the prefix. What only the reference implementation's interface reads is not the standard's to define, and a prefix keeps it the reference implementation's, so that no later version takes its name; what another tool needs is the standard's, so that two tools that read one building draw, check and print it alike. **Written, 30 October 2026:** proposed for 0.2, behind the proposal `adopted`. [Part II, 14](https://openeik.org/spec/0.2/language#14): `castWith` (14.1), a layer's `drawing` (14.2), a view's `display.electrical`, `display.levelLabels`, `display.sideMarks`, `assembly.pitch`, `lineWeights` and `camera` (14.3), a detail item's `cloud`, `schedule.headings`, `legend.title`, `buildUp`, `follows`, with how a command that moves an instance moves what follows it, `cutBy` and `notDimension` (14.4), a detail family's `insertion` (14.5) and a terminal type's `tagSize` (14.6); [Part II, 4](https://openeik.org/spec/0.2/language#4), rule 4, the pattern `clt`; [Part II, 7](https://openeik.org/spec/0.2/language#7), `bolts.through` and `castWith` as references, `bolts.through` to resolve; [Part IV, 4.6](https://openeik.org/spec/0.2/compiler#4.6), rules 12 to 14, a slab edge element's `notches`, its bodies stretch by stretch and its host's fill. [Part I, 11.5](https://openeik.org/spec/0.2/foundations#11.5): the eight members under the prefix, with what the reference implementation renames, and what a reader of 0.2 does with an old unprefixed one: it keeps it as a member it does not know, and a validator warns of it by the name 0.2 gives it (`member-unprefixed`). `tools/generate-schemas.mjs` keeps `LATER` for what no text describes, the members the proposals for 0.2 describe in `PROPOSED`, and the reference implementation's own in `OWN`, and writes `schemas/proposed/adopted/` from the reference implementation's own schemas; the schemas were regenerated from the reference implementation at `de6f0d04`, its main of 30 October 2026. `@openeik/tools` applies the proposal in its validator, its compiler (the notches, against the reference implementation's own bodies of a probe, `packages/openeik/test/fixtures/notched-edges.json`, exactly), its bridge and its command processor (`proposals: ["adopted"]`), and the conformance suite of the proposal (`conformance/proposed/adopted/`) has 34 cases. The categories `provision` and `person` are written with decision D9 (section 4): `provision` as the proposal `provision` ([Part II, 6.10](https://openeik.org/spec/0.2/language#6.10)), which the generator lists in `PROPOSED`, and a person as a `generic` element (Part II, 6.6, rule 9), the generator keeping the category `person` out of the schemas (`OWN`). The reference implementation added more members of its own after `bcfd44c7`: question 116. 116. **The reference implementation's members for an estimate.** After question 115's list was made, the reference implementation added members of its own for an estimate (its works 758 and 768, on its main since 29 October 2026, `de6f0d04`), which it writes without a prefix: an element's `tenderPart`, the tender part it is bought in; its `action`, what is done to it where its `status` says too little; and its `littera`, its own type mark over its type's; a type's `littera`, the mark its elements are called by on the drawings, and its `costCodes`, the codes cost books price it by, `{system, code, edition?, measure?, size?, proposed?, note?}`, at most one for each system and size; and the `costCodes` of each of a room's finishes (`floor`, `skirting`, `wall`, `ceiling`, `other`), on a room and on a room type. A code is an identifier only: the reference implementation holds no price and no cost book. `tools/generate-schemas.mjs` keeps them out of the schemas (`LATER`). Raised 30 October 2026, with question 115's list. The choice, by question 115's rule: (A) into 0.2: an element's and a type's `littera`, which a drawing prints, an element's `tenderPart` and `action`, which an estimate reads, and the cost codes as classification references (Part II, 11, proposed for 0.2), which they are shaped as, a reference's `measure` and `size` added there for a code that prices one quantity or one size; (B) all under the prefix `stomra`, as the reference implementation's own; (C) `littera` into 0.2, and the rest under the prefix. **Recommended:** (A). A type mark is printed on drawings and schedules, and an estimate is read by tools other than the one that wrote it, the user's own assistant among them; a cost code names a code of a system the standard does not list, which Part II, 11 is for, so that one shape serves classification and pricing. `proposed` and `note`, which only the reference implementation's interface reads, would be its own, under its prefix. ## 4. The 0.2 cut's decisions, 30 October 2026 On 30 October 2026 the steward accepted every recommendation of the 0.2 plan's table of decisions, D1 to D13, and of the open items put to him with it, in the openEik.org thread: "allt ja enligt din rekommendation". The same day, in the Femra thread (relayed), he wrote: "bestäm du hur 0.2 ska skäras bäst". The 0.2 plan is the inventory and work plan for 0.2 of 29 October 2026, an unpublished planning document. Each decision below says what was decided and where it is written; the cut is the change that makes 0.2's text normative (the plan's 1.3). 1. **D1, what reaching 0.2 freezes.** 0.1 is tagged `v0.1.0` at the last commit before the cut, and 0.2 `v0.2.0` at the cut, both in the private repository. A writer of 0.2 writes `openeik/0.2` (Part I, 9.2). The public launch later publishes the frozen versions, and what an outside review finds goes into errata (Part I, 9.5) or 0.3. A reader of 0.2 reads every model written so far, `openeik/0.1-draft`, by the frozen 0.1 (Part I, 9.5, rule 5; 9.6, rule 3). Written by the cut. 2. **D2, `schemaVersion`.** Deprecated in 0.2 (Part I, 9.6): the format, in `eik.json` and in the single-file form (D3), is the one version a model gives. A reader of 0.2 ignores `schemaVersion` where a format is given; 1.0 removes it. Written by the cut, in Part I, 9.3. 3. **D3, the single-file form's format** (question 20, its open part on the format). The single-file form carries the members of `eik.json`, `format` and `units`, at its top, so that a file says its version as a folder does; its media type keeps no parameter. Written by the cut, in Part III, 11. 4. **D4, what Parts XIII to XVIII bind.** They are rules of 0.2 for every class they bind: a reader of 0.2 reads circuits, sheets, owners, assets and review files as records. The behaviours that need more than a folder go to classes: the *drawing validator* and the *drawing issuer* (Part XIV, 19.2), the *host* and the *authoring tool* (Part XVIII, 9); and a version store keeps assets (Part XV, 11). Profiles are for 1.0 and after (`GOVERNANCE.md`, stage 0). Written by the cut, in Conformance. 5. **D5, what holds the tag.** Everything decided for 0.2 holds it, with the first part of question 83 (83.1) and questions 91 to 94. The second part of question 83 (83.2, the framing laid out from walls, roofs and floors) and question 95 (reading IFC) go into the first version they are finished for, and do not hold 0.2. Written by the cut, in the changelog. 6. **D8, the reference implementation's members outside this specification** (section 2, row 20). One rule decides each: what another tool needs to read, draw, check or print the building joins 0.2; what only the reference implementation's own interface reads moves under its registered prefix (Part I, 11.1; `registry/extensions.json`). A list for the steward names each member path, category, value and reference with its answer. Written as question 115, with the generator's list of members described later (`LATER` in `tools/generate-schemas.mjs`). The category `provision` and the category `person` are D9's. 7. **D9, a provision for a void, a suggestion's form, and scale figures** (question 85, point 4; asked by the reference implementation's work 670, steps 6.1 and 6.2). `provision` becomes a category of this specification: a void that a run asks of an element it crosses, which records its asker, its host and the answer of its host's owner, cut, with what the cut made, or declined, with a sentence; IFC's IfcBuildingElementProxy of the predefined type PROVISIONFORVOID. A suggestion is an envelope in the mode `propose` (Part XVII, 6.3), which makes a proposal file (Part VI, 8.7) or a host's proposal, discussed as an item of a review (Part XVIII, 2), with no form of its own. The reference implementation's category `person`, a scale figure, is a `generic` element whose type stands for a person (Part II, 6.6), with declared geometry, and no category of its own. Written on 30 October 2026: [Part II, 6.10](https://openeik.org/spec/0.2/language#6.10) and [Part VIII, 1.10](https://openeik.org/spec/0.2/bridges#1.10), proposed for 0.2 as the proposal `provision`, and a provision's owner in Part III, 4.4, rule 2; a suggestion in [Part XVI, 5, rule 5](https://openeik.org/spec/0.2/ownership#5), with a pointer in Part XVII, 6.3; a person in [Part II, 6.6, rule 9](https://openeik.org/spec/0.2/language#6.6). The generator (`tools/generate-schemas.mjs`) lists the category `provision` and an element's `provision` under the proposal (`PROPOSED.provision`), and the category `person` and the reference implementation's `person` members among its own (`OWN`), since D8 was written (question 115); the proposal's schemas are written by hand (`schemas/proposed/provision/`). 8. **D10, derived results and versions.** A version carries no body an application derived: Part IV, 1.1, rule 3 stands, and derived data is never a record nor in a version's tree. Every body a print needs gets a rule, so that every host and tool prints the same body from a version; 0.2 fixes the derived layer's layout and a result's form as a cache keyed by its records' hashes. Written with question 98. 9. **D12, the version of `@openeik/tools`.** It follows this specification's major and minor version: `0.2.0-draft.N` from the first change of 0.2 on `main`, `0.2.0` at the tag. Its `proposals` option then names only proposals for the next version. Written by the cut. 10. **D13, the bodies the reference implementation still derives by its own code** (its work 727, the table of bodies that stay its own). Each is raised as a numbered question with a class-A rule written from the reference implementation, for 0.3; none holds 0.2. Raised on 30 October 2026 as questions 104 (a wall's body at its corners and tees; Part IV, 7.4.2 states them for a framed layer), 105 (fittings between pipe and duct runs), 106 (a bar's shape) and 107 (terrain and grading). 11. **S, the sheets of 0.1.** In 0.1 a sheet is an application record (Part II, 9.1). A sheet of 0.1 that has the members Part XIV's sheet record requires ([Part XIV, 2.1](https://openeik.org/spec/0.2/drawings#2.1): its number, its name, its revision, its paper's width and height, and its viewports) migrates to a sheet record of Part XIV; any other is kept as an application record, and the migration reports it as a finding. Written by the cut, with the migration (Part I, 9.6, rule 4). 12. **F, the formats of single files.** The format ids of files that name a format of their own, such as `openeik-owners/0.1`, the `openeik-drawing-*` formats, `openeik-envelope/0.1`, and the predicate types that end in `/v0.1`, are file formats that version on their own: 0.2 keeps each while it keeps that file's form. Written on 30 October 2026, as [Part I, 9.7](https://openeik.org/spec/0.2/foundations#9.7). D6 and D7, a member between two points and a slab on a sloped plane, were decided in the same words, and are questions 110 and 111, written as [Part II, 6.2.1](https://openeik.org/spec/0.2/language#6.2.1) and [6.3.1](https://openeik.org/spec/0.2/language#6.3.1) (the proposals `member` and `slopedSlab`). D11, the reference implementation's own asset store, is the reference implementation's (its work 750, step 5), not this specification's. The open items decided with the table: - **A device's protective earth** (Part XIII, 2.2; question 94): `electrical.earth`, proposed for the steward to confirm, is decided. - **A framing family's beam's lines** (Part IV, 6.5.1; question 10): written as the proposal `framingLines` and folded into the proposal `framing`, which builds the parts; the fold is confirmed. - **A roof that comes down through the floor bounds rooms** (Part IV, 7.5; question 72): written for 0.2 for the steward to confirm, it is decided. - **The names of a truss layout's members** (Part IV, 7.4.13 and 7.4.16): the rules use English names, and the reference implementation changes its Swedish ones.