`), as Part VIII, 1 keys a framing member given to it; its material `Timber` and its rule's material, `Timber C24`. ### 7.4.12 What is not laid out yet 1. **A face no set frames.** A truss layout frames its roof's eaves (section 7.4.13) and its hip ends (section 7.4.16). A sloped face that is neither, such as a valley's or a second hip end at one end of the ridge, is framed by no truss, which is said (`framing-layout-note`): the reference implementation lays no set out under it either. A layout of one fall, or one whose `hips.frame` is false, frames no hip end, and says its hip ends. 2. **Materialised members** (`framing-layout-materialised`). A wall whose members are materialised as elements, which name it in their `frameHost.wallId` (Part II, 10), is not laid out: its members are those elements. Nor are the members of a roof whose trusses are materialised, which name it in their `frameHost.roofId`: the layout is still laid out, and the walls and floors that read it (7.4.14, 7.4.15) read it as it is. 3. **What a later rule may read.** A rule's `relyOn`, which names the layer whose studs its battens follow, is not read. *Note (informative).* On the reference implementation's garage, guesthouse and villa (its `main` `f2bc53d2`, 29 October 2026), `@openeik/tools` lays out every member the reference does, 299, 75 and 482, each with its id, name, section, class, outline and line, its box within 10⁻⁶ mm and its volume within a relative 10⁻⁸, and its print writes each with the GlobalId, class, name and tag of the reference's own print. On a probe of 22 walls and 715 members that takes each rule a way it can go (`packages/openeik/test/fixtures/framing-layout.json`), it agrees with it exactly, but for one top plate of a gable under its roof whose top lies on the roof's face: the reference's clip counts a cap on that face and gives the plate 1.6 % more volume than its outline carried across its layer holds; the rule's volume is the body's. The reference also reads a rule's `top` where it gives none as no object, and fails; these rules take it as `auto`. Two orders are the reference's own and may differ from these rules' where two things tie: walls that end against a wall at one x (the reference, in the order of its walls by base), and floors found of one underside and coverage (the reference, in the order of its elements). Reference: `deriveWallFraming`, `resolveFrameTop`, `bottomPlateCutsFor`, `splitByGaps`, `framingRuleSchema` and `validateFramingRule` in `src/core/elements/wallFraming.ts`; `frameEnvelope`, `frameCorners`, `frameTees`, `wallFramingFor` and `framingSolids` in `src/core/elements/wallFramingGeometry.ts`; `bearingFloor` in `src/core/elements/bearingFloor.ts`; `joinPartner`, `teeHost`, `teeBranches` and `wallJoinCoordinate` in `src/core/elements/wallJoins.ts`; `wallTopClips` and `extendsExteriorLayers` in `src/core/elements/wallTop.ts`; `pocketSide` in `src/core/elements/openings.ts`; `framingIfcClass` in `src/core/elements/framingIfc.ts`; `derivedFraming` in `src/core/io/ifcFraming.ts`. In `@openeik/tools`: `framingLayouts` and `layoutLayer` in `packages/openeik/src/compile-framing-layout.js`, `wallJoins` in `packages/openeik/src/compile-framing-joins.js`, called by `compileModel` in `compile.js`. ### 7.4.13 A roof's truss layout These rules lay out the trusses of a roof's `trussLayout` (Part II, 6.3): each truss its family's parts, built as section 6.6 builds a beam's, on a line across the roof's span between the walls or beams it bears on; and a roof opening's trimmers, headers and dormer rafters, a ridge beam and its posts, and an anchor pair where each truss rests. Its hip ends are framed by section 7.4.16. In these rules lengths are in mm, and points in plan. 1. **A truss layout, its rule and its family.** A roof with a `roof` payload, no barrel vault, and a `trussLayout` is laid out. Its rule is read with these values for what it leaves out: `layoutRule` fixedDistance, `spacing` 1200, `count` 2, `justification` beginning, `bearingReference` coreFace, `ends` insideGables, `endOffset` 0, `openingFraming` with `trimmerPlies` and `headerPlies` 2, `hips` as section 7.4.16, rule 1 reads it, and a `ridgeBeam`'s `topOffset` 0 and no `posts`. Its family is the `framing` of the type its `familyTypeId` names, which MUST be a beam type, and is a **truss family**: one that declares the parameters `Pitch`, `HeelHeight`, `OverhangLeft` and `OverhangRight` of the scope `instance`. The family's parameters' values (`value`) give w, its `Width` (45 where it has none), and its `ChordDepth` (170), `BottomDepth` (0), `RidgeGap` (0), `BottomPitch` (0) and `Notch` (0); a family with a `FurringMin` is a **furring family**. A layout that a rule of this section cannot lay out is a finding (`framing-layout-roof`): the roof has no layout, and the walls it would bear on are laid out without its trusses. A validator warns of a layout whose family type is no beam type with a truss family, which it can tell from the records alone (`framing-layout-roof`). 2. **Its faces, its eaves and its frame.** The roof's faces are those of section 4.4: a plane for each slope-defining edge, of two within 10⁻⁷ the first; each face the roof's domain, its outline pushed out by each edge's overhang (4.4, rule 3), where its plane is the lowest; a face of 0.01 mm² or less is none. An edge that `roof.edges` gives no rule defines no slope and has no overhang. A face is sloped where its gradient is more than 10⁻⁹; a roof with no sloped face is not laid out. Two sloped faces face each other where their edges run at least 179° apart (their directions' product less than −cos 1°); of such pairs, the eaves are the pair whose edges are together the longest, the first in the order of the outline where two are as long, and the left eave is the face of the pair's edge that comes first. Without such a pair the layout falls one way, its left eave the sloped face of the longest edge, the first of equals. The layout's frame: **across**, the left eave's edge's normal into the outline; **along**, square to it, the one of the two that points along +x, or along +y where across is square to x within 10⁻⁹; its origin the outline's first point; τ(p) = (p − origin)·across and r(p) = (p − origin)·along. Of the other sloped faces, those whose edges run across the span, within 5° of across (|u × across| ≤ sin 5°), are **hip ends**, framed by section 7.4.16, and the others are not framed, which is said (7.4.12, rule 1). 3. **Its bearings.** Where `bearingWallIds` gives them, each side is the walls or beams it names in order, one or a list, each with two points or more and running along the eaves, its first two points' direction within 5° of along; the middles of the two sides' first bearings lie at least 500 apart in τ, and the side of the lesser τ is the left. Else each side is found: of the walls at least 1 mm long that run along the eaves and **come up to the roof** (attached to it, `top.attach.hostId`, or whose top, at its base plus its height, the highest of its top by sections 5.1 and 5.3, lies at most 1500 under the least of the roof's faces lowered by its thickness at the wall's middle), whose middle's τ lies less than 500 outside the eaves' τ, and whose run in r overlaps the domain's by at least the lesser of 1000 and 0.3 of the domain's run: those whose middle lies on the side's half of the span (under or over the middle of the eaves' τ), and of them those that overlap at least half the domain's run where there are any; the nearest to the side's eave, by |τ − τ_eave| / 50 rounded to a whole number, then the higher base, then the greater overlap, then the first by id in code units. The eaves' τ: the left eave's edge's first point's, and the right's, or the domain's greatest where the layout falls one way. A side with no bearing is a finding. 4. **A bearing's plane and its faces.** A wall bears on the one of its framed layers that has a bearing plane (7.4.4, rules 2 and 3) when it is laid out with no truss on it: a core layer, else any, the thickest, the first of equals. Its **bearing elevation** is its base plus that plane's height, its faces that layer's two faces (y0 and y1), and its extent along the wall that plane's (its envelope's least and greatest x). A beam bears on its top, its base plus its `height`, across its whole `width`, and along its whole length. A wall with no such layer bears on its lowest top (sections 5.1 and 5.3), across its core band (from its first core layer's outer face to its last core layer's inner face, else its whole thickness), along its whole length, which is said. With `bearingReference` finishFace a wall's faces are its outer faces, 0 and its thickness T. A bearing's **reference face** is the one of its two faces, taken at the middle of its extent, nearer the outside: on the left the lesser τ, on the right the greater; and its **run** the least and greatest r of its extent's two ends at the middle of its faces. A side of several bearings bears at the highest of their elevations, its reference face the first's, and its run from the least of theirs to the greatest; a truss at a place bears on the first of them whose run holds the place within 1 mm, else on the one whose run's nearer end is the nearest. The layout's **bearing plane** E is the higher of its two sides'; but a layout that falls one way and whose family has no `member` part of the role `bottomChord` bears at its left side's. Sides more than 1 mm apart in elevation, and a bearing more than 5 mm out of line with its side's first, are said. 5. **Its range and its trusses' places.** The bearings' run is where both sides' runs overlap, at least 1 mm (else a finding); the roof's run the least and greatest r of its domain. The range is the bearings' run held within the roof's run, closed at its gables; where that leaves less room than w + 2·`endOffset` (within 10⁻⁶), the bearings' run closed at its gables, which is said. **The gables** of a run are the walls that are no bearings, at least 1 mm long, running across the span within 5°, whose τ overlaps the span between the two reference faces by at least half of it, whose first point's r lies within half their thickness plus 150 of the run's start (a gable at the start) or else of its end (at the end), and that stand on the trusses' storey: base at most E + 500 and top, their base plus their height, at least E − 1500 (a wall whose top cannot be resolved stands). With `ends` insideGables the range starts no sooner than a start gable's inner face, r + T/2, and ends no later than an end gable's, r − T/2. The first place is the range's start plus `endOffset` + w/2, the last its end less `endOffset` + w/2; a last more than 10⁻⁶ before the first is a finding. With `layoutRule` positions, each of `positions`, sorted by `at`, is a truss at the range's start plus its `at`, of the mark its `mark` gives; a layout that lists none is a finding, and one that stands more than 1 mm outside the range less w/2 is said. Otherwise, with t = last − first and c the spacing: no truss where t is less than −10⁻⁶; one at the middle where t is less than w; else - `maximumSpacing`: n = max(1, ⌈t / c − 10⁻⁹⌉), and n + 1 places evenly from the first to the last; - `fixedNumber`: `count` places evenly from the first to the last, which is a finding where they are less than w apart; - `fixedDistance`, with n = ⌊t / c + 10⁻⁹⌋: from the `beginning`, the places first + k·c for k from 0 to n, the last of them moved to the last place where it lies within w of it, else the last place added after it (and added where n is 0); from the `end`, the same mirrored, last − k·c in order, the first of them moved to the first place where it lies within w of it, else the first place added before it; from the `center`, with r = t − n·c, the places first + r/2 + k·c, and the first and the last places added at the ends where r/2 is more than w, else the first and the last of them moved there (where n is 0, the first and the last places). The trusses so placed are numbered T1, T2 … in order, but where a position gives a `mark`; each is keyed by its index from 0. At a hip end, the range, its places and its girder are as section 7.4.16, rule 3 says. 6. **Each truss's line.** A truss at a place lies on the line from the point origin + along·place across the roof, along across. Its left and right ends, at τ_L and τ_R, are where that line meets its two bearings' reference faces, each the line through the face along its bearing's direction; its **span** is τ_R − τ_L, at least 1000 (else a finding), and its points a and b, at τ_L and τ_R, run from its left bearing to its right one, each to 0.001. 7. **Its heel and its parameters.** The chords' top is the face of the roof's **chord layer**: the layer of its type that `chordLayer` names, which MUST be one, else the first layer as thick as `ChordDepth` within 0.5 where the family is no furring family, else none; `chordLayer` underside names none. Its face is the underside of the layer over it, or the roof's top for its first layer, and without a chord layer the roof's underside; each of the roof's faces lowered by that depth, square to it (4.4, rule 4), the least of them. A truss's heel is `heelHeight`, else that face's height at its a less E; a heel under 0 is a finding, and so, in a furring family, is a heel less `BottomDepth` that is more than 0.5 under its `FurringMin`. It gives its family the parameters `Pitch`, the left eave's edge's slope; `HeelHeight`, its heel; and `OverhangLeft` and `OverhangRight`, `overhang`, else τ_L less the least τ and the greatest τ less τ_R where its line lies in the roof's domain, each at least 0; each to 0.001. Pitches more than 0.05° apart are said; with a heel given, a top that stands more than 1 mm into or under the face, and a face that lies more than 1 mm off the heel at the right bearing, are said. 8. **Its parts.** A truss's parts are its family's, built by section 6.6, rules 2 to 9, with the parameters of rule 7 as the element's, with two changes for roof openings (rule 10): - a one-sided truss keeps only the top chords of its side: a `member` part of the role `topChord` is the left's where its axis rises (t_z more than 10⁻⁹) and the right's where it falls; - a **band** taken out of a side's top chords, from and to horizontal distances from that side's bearing line, is taken out of each of their pieces after its notches: with A(d) the point d along and `HeelHeight` + tan(`Pitch`)·d up (on the right, `Length` − d along) and the direction up the slope (cos `Pitch`, sin `Pitch`), mirrored on the right, what lies down the slope of the line square to it through A(`from`) is kept, where the band gives `from`, and what lies up the slope of the line through A(`to`), where it gives `to`, each a piece where it has three points or more and more than 10⁻⁶ mm². A top chord that its bands take all of has no piece, which is no fault. A family that cannot be built is a finding. `Length` is the span τ_R − τ_L for its seats (rule 9), the span to 0.001 for its members' sections and lengths (rule 13), and the length of its line from a to b for its bodies (rule 14). 9. **Its seats.** On each side, where it bears on a framed wall or a beam, its seat is the least height over the bearing plane of its pieces, its plates' too, where each is clipped to between that bearing's two faces (each τ less τ_L, x0 and x1, in the plane), counting a clipped piece of 1 mm² or more, plus E less its side's elevation (rule 4), to 0.001. It has none where no piece spans the faces, or the bearing is no framed wall nor beam. 10. **Its roof openings.** A roof opening (`roof.windows`) lies on the face of its edge `edgeId`: on an eave face, else it is not framed, which is said. Its outline is the rectangle `width` across the slope and `length` along it, its plan length `length`/√(1 + tan² σ), σ its edge's slope, about its `center`, along its edge's direction and normal; its run, from a0 to a1, and its τ are its corners' least and greatest. Openings are framed in a layout whose family's `trussStyle` is rafters; in any other, they are said. For each opening, in order: - **its trimmers**, `trimmerPlies` k from 0 on each side, a truss of its side only (rule 8) at a0 − w/2 − k·w (keyed `:a`) and at a1 + w/2 + k·w (`:b`), in that order, after the layout's trusses, numbered V1, V2 … across the openings, with their own indices on from the layout's; - **the trusses it cuts**: each of the layout's trusses (not a trimmer) whose width overlaps, by more than 10⁻⁶, a trimmers' band, a0 − `trimmerPlies`·w to a0 or a1 to a1 + `trimmerPlies`·w, loses its top chords on the opening's side whole (a band with neither end); one that overlaps a0 to a1 loses a band from d_eave − h to d_ridge + h, its `from` only where d_eave is more than 0, each to 0.001, where d_eave and d_ridge are the opening's τ on its eave side and on its ridge side measured inward from that side's bearing line at the truss (τ − τ_L on the left, τ_R − τ on the right), and h is its header's plies by their width by cos `Pitch`, 0 where it has none; - **its header**: `headerPlies` plies of w by `ChordDepth`, else one ply of the section its opening's `header` gives, `{width, depth}`, or none where it gives `none`. A header runs from a0 to a1 along the ridge, on the chords' top face, its plies' width up the slope and its depth square to it: across the ridge side from d_ridge to d_ridge + h, d_ridge measured at a0, but where its far top edge, 1 mm short, lies outside the opening's face at a0 or a1, which is said; and across the eave side from d_eave − h to d_eave, where the opening does not reach its bearing line (d_eave at a0 more than 0). Its corners: at each end, at d along from the bearing line and k into the chord, the point τ_L + d + k sin `Pitch` (τ_R − d − k sin `Pitch` on the right) on its line, at E + heel + tan(`Pitch`)·d − k cos `Pitch`, each to 0.001; keyed `:opening::header:ridge` and `…:header:eave`; - **its dormer rafters**: under the roof whose face over the opening's middle (the middle of its first and third corners) is sloped, of a pitch at least 1° from `Pitch`, its underside the highest there (the first by id of equals), where its gradient lies within 5° of across (else said): for each truss it cuts, in order, a rafter at the truss's place (to 0.001), from its ridge-side d_ridge to where its line leaves that roof's domain on the opening's side, where that is 100 or more, `dormerRafterDepth` deep (else `ChordDepth`) and w wide, its top on that roof's underside and its plumb depth that depth over the cosine of its pitch, its length along its slope; keyed `:opening::dormerRafter:`. 11. **A ridge beam.** A layout whose family's `trussStyle` is rafters lays its `ridgeBeam`; another says it does not. Its width is its `width`, else `RidgeGap`, and one less than 45 is said, and none laid; a width more than 1 mm from `RidgeGap` is said. At a place along the ridge, its top is E + heel + tan(`Pitch`)·((τ_R − τ_L)/2 − width/2) less `topOffset`, its underside its `depth` lower, and its middle at (τ_L + τ_R)/2. It runs from the range's start to its end, but where a gable stands there (rule 5): from that gable's framed layer's outer face, its core layer that carries `framing`, else its first that does, where that face is the outer one (else from between its faces, said), in which it then bears; or from the gable's line where it has no framed layer (said). Its corners at each end are its top and underside at its middle ± width/2. Each of `posts`, a distance from the range's start, is a post width by width at its middle, from the base of the left side's first bearing up to the beam's underside there, where it lies within the beam's run (else said); keyed `:ridge:post:`. Where it bears in a gable, its **bearing** there is its middle's x along the gable at the gable's first point's place, its width, its underside and top over the gable's base, and the y of the framed layer's outer face (7.4.14, rule 6). The beam is keyed `:ridge`. 12. **Its connections.** Each truss, on each side where it rests, has an anchor pair on that side's bearing at its point a or b, at E, of two brackets, keyed `:anchor:`. A truss **rests** on a side unless it is one-sided to the other side, or a band that gives no `from` (one that takes its tail) is taken out of that side; a hip truss and a jack as section 7.4.16, rule 9 says, which gives them hangers too. 13. **Each member: its name, its section and its class.** A truss is keyed `:truss:` and named `Truss` and its mark, as `Truss T3`; a hip set's trusses and a girder's plies as section 7.4.16, rule 10 names them. Each of its parts that has a piece is a **member**, keyed `:`, named by the truss's name, its role in words and the part's id, as `Truss T1 · top chord topL` (a `profile` part by its id alone, a plate as a nail plate), of the IFC class and predefined type section 6.6 and Part VIII, 1.6 give a family's part by its role, its material its family type's timber, and a nail plate's steel. Its section is its width by the greatest depth of its pieces: a part's pieces, ordered by their least extent along its axis, are grouped where each starts within 1 mm of the reach of those before it, and each group's depth is its extent square to the axis; a plate's is its pieces' height in the plane. Its length is the sum of its groups' extents along the axis. The headers, dormer rafters, ridge beam and posts are members too, named `header`, `rafter`, `ridge beam` and `ridge post` and their key after its first `:`, as `header opening:W1:header:ridge` and `ridge post ridge:post:0`, of the classes of section 6.6's table: a header an IfcMember USERDEFINED HEADER, a dormer rafter an IfcMember RAFTER, a ridge beam an IfcBeam BEAM RIDGEBEAM and a post an IfcColumn COLUMN; their sections a ply's width by its depth, the beam's width by its depth and a post's width by width. Sections are each to 0.1, as `45 × 220`. 14. **Each member's body.** A truss's pieces are placed as a beam's (section 6.6, rule 10) on its line from a to b, level, its set-out line at E: each piece is its polygon carried across its width, a plate's on its member's faces (6.6, rule 9). A header, a dormer rafter, the ridge beam and a post is the closed body of its eight corners, its start's four and then its far end's in the same order: its six faces the end faces and the four sides between them, its volume by the divergence theorem over each face's triangles from its first corner. 15. **In IFC.** A bridge writes each truss as an IfcElementAssembly of the predefined type TRUSS, its object type `Truss`, under its roof by an IfcRelAggregates, its GlobalId from `truss:`, its name its name and its tag its key, with no body of its own, and its members under it, each as section 7.4.11 writes a wall's, keyed `framing:` and typed by class, predefined type and section, its material `Timber` and its family type's material, a nail plate's steel. It writes the headers, dormer rafters, ridge beam and posts under the roof the same way. Each anchor pair is an IfcMechanicalFastener in its roof's storey, its GlobalId from `fastener:`, its name `Truss clip pair`, its object type `TRUSSCLIP` and its predefined type USERDEFINED, with no body: the rules give its place, not its shape. An IfcRelConnectsWithRealizingElements of the type `TRUSS_TO_PLATE`, keyed `connects:`, connects its truss's assembly to its wall or beam, where both are written. These are class-A rules, held to the tolerances of section 10: each member's body within 0.1 mm of the rules', and its volume within a relative 10⁻⁶; trusses, members, their ids, names, sections and classes exactly. *Note (informative).* On the reference implementation's examples with truss layouts (its `main` `f2bc53d2`, 29 October 2026): its garage, second version, whose 11 collar trusses with nail plates bear on a wall and a beam in line on each side; and its villa's frame, whose three roofs carry 24 rafter pairs and trimmers round a roof window and a dormer's opening under a ridge beam on two posts, 8 rafter pairs on a ridge beam, and 6 fink trusses. `@openeik/tools` lays out every truss the reference does, 11 and 38, with its mark, line, span, parameters, bearings and seats; every member, 66 and 108, with its id, name, section, class, box and volume exactly; and every anchor pair, 22 and 65. On a probe of five roofs that takes each rule a way it can go (`packages/openeik/test/fixtures/framing-roofs.json`: fink, collar, rafter, one-fall and king post trusses, each layout rule, bearings named and found, a wall and a beam in line, finish faces, a heel and an overhang given, the bearings' ends, a chord layer, a ridge beam with a post, a roof window and a dormer's opening under a dormer roof, and seats), it agrees with it exactly: 43 trusses, 209 members and 82 anchor pairs. Its print writes each truss, member and anchor pair with the GlobalId, class and tag of the reference's own print, and its name as the reference's with its Swedish words put into the rules' English (below). They differ where the text decides: - **Names.** The reference names a truss, a ridge beam, a ridge post and an anchor pair with its trade's Swedish words (`Takstol T3`, `nockbalk`, `nockstolpe`, `Takstolsvinkel, par (truss clip pair)`), while it names every member's role in English. By the steward's decision of 30 October 2026 these rules name them in English, `Truss T3`, `ridge beam`, `ridge post` and `Truss clip pair`, and the reference changes (open questions, section 2). Until it does, `@openeik/tools`' tests compare each name with the reference's, its Swedish words put into these English words one for one (`packages/openeik/test/support/reference-names.mjs`), so that the comparison stays exact. It names a `profile` part of a truss by its id twice (`Takstol T1 · seat seat`); rule 13 names it by its id once, as section 6.6 does. - **An anchor pair's body.** The reference gives each a box 60 × 60 × 40 mm at its point, which stands for no part's shape; rule 15 writes it with none. - **A nail plate's material.** The reference writes a truss's nail plates of its family type's timber; rule 15 writes them of steel, as Part VIII, 1.6 does a family's. - **Ties.** Where two walls are found alike for a side, or two gables or two dormer roofs stand alike, the reference takes the first in the order of its elements, which section 9 of Part III gives no meaning; these rules take the first by id. Reference: `deriveTrussLayout`, `trussPositions`, `trussChordLayer`, `wallBearing`, `trussElement`, `trussSolids` and `bearsOn` in `src/core/elements/trussLayout.ts`; `trussLayoutSchema` in `src/core/elements/trussLayoutRule.ts`; `layoutRange` in `src/core/elements/trussLayoutRange.ts`; `bearingFrame` in `src/core/elements/bearingFrame.ts`; `lineInside` and `seatOver` in `src/core/elements/trussHips.ts`; `framingProfiles` (its `interruptions` and `side`) in `src/core/elements/framing.ts`; `roofFaces` and `roofWindowPolygon` in `src/core/elements/roofs.ts`; `openingHeaderSection` in `src/core/elements/roofOpeningHeader.ts`; `trussMembers` in `src/core/elements/trussReport.ts`; `boxSolid` in `src/core/geometry/memberBox.ts`; `derivedFraming` in `src/core/io/ifcFraming.ts`. In `@openeik/tools`: `trussLayoutOf` and `trussMembers` in `packages/openeik/src/compile-framing-roofs.js`, with `familyParts` in `packages/openeik/src/compile-framing.js`, called by `framingLayouts` in `packages/openeik/src/compile-framing-layout.js`. ### 7.4.13.1 What a truss layout's members bear on *Part of 0.4. OpenEik 0.3 had it as the proposal `bearsOn` (open questions, 130): a model of 0.3, read by 0.3's rules (Part I, 9.6, rule 3), is read by it only where a caller asks for it (decision D12).* Each member these rules derive names what it bears on, as the rule that laid it out found it, so that a reader follows a load to its support with no rule of its own. A compiler of a model of 0.3 that does not ask for the proposal gives a derived member no `bearsOn`. 1. **Its form.** `bearsOn` is `{start, end}`, each a list of the ids of the elements, or of the members a layout derives, that the member bears on at that end: its start the end its line begins at, its end the other. An end that bears on nothing the rule finds has an empty list. A member that bears between its ends too names those as `along`. 2. **A truss.** A truss bears at its start on the wall or beam of its left side, and at its end on that of its right side, as rule 3 finds them (`bearings`). Its parts bear on each other, within the truss, and carry no `bearsOn`: the truss names its bearings. 3. **A roof opening's members.** A header (rule 10) bears at each end on the trimmer beside the opening there, the trimmer truss whose place lies nearest the header's end. A dormer rafter (rule 10) names no bearings that the rule finds: both lists are empty. 4. **A ridge beam and its posts.** A ridge beam (rule 11) bears at each end on the gable wall it is seated in, an end without one on nothing, and between its ends on its posts (rule 12), named in `along`. A ridge post bears on nothing the rule finds: it stands on its storey, which no element names. Reference: none in the reference implementation, whose truss layout finds the same bearings (`wallBearing`, `bearsOn` in `src/core/elements/trussLayout.ts`) and does not give them to its members. In `@openeik/tools`: `trussLayoutOf`, `trussMembers` and `framingLayouts`, asked for with `compileModel(model, {proposals: ["bearsOn"]})` on a model of 0.3. ### 7.4.14 The walls a truss layout bears on A framed wall that a truss layout bears on is laid out by sections 7.4.1 to 7.4.11, with these rules besides. 1. **The trusses on a wall.** Each truss of each roof's layout (7.4.13), the roofs in the order of their ids and each roof's trusses in their order, whose bearing on a side is the wall, the first side that is, and that rests on that side (7.4.13, rule 12, and 7.4.16, rule 9), stands on the wall as a **truss line**: at x = (its a, or its b on the right, less the wall's first point)·u along it, as wide as its family's `Width`, its bottom its family's `BottomDepth` over the bearing plane, and with its seat on that side (7.4.13, rule 9). Each ridge beam that bears in the wall (7.4.13, rule 11) bears on it too. A layout that is a finding bears on none. 2. **Studs under trusses.** Where the rule's `alignToTrusses` is true, after the studs set by hand (7.4.6, rule 3), each truss line within the frame (from its least x + w/2 to its greatest − w/2, within 10⁻⁶) takes the grid's places within w + 50 of it out of the grid, and sets a place at its x, keyed `t-`. 3. **The heel zone the trusses hold.** Over a level plate or under a floor (7.4.4, rule 6), a truss line that has no seat over the bearing plane (rule 5) holds the heel zone over its width: each heel plate is cut at it, into its pieces more than w long, keyed `.`, k from 0, wherever the layer has a truss line; and no heel post stands where it would overlap one. 4. **Bottom chords across battens.** In a batten layer on which a floor bears (7.4.8, rule 1), each truss line with a bottom crosses the layer: a hole over its width about its x, from the floor's top up by its bottom, which cuts the rows and which the end battens start over. 5. **A seat.** The truss lines whose seats are more than 1 mm over the bearing plane rest on the heel plate. Where the least of their seats is at least the heel plate's width plus w, the heel plate lies level, its top at the bearing plane plus that seat and with no drop across, continuous under them, whatever the heel zone's height; its heel members are cut by the layer's mitres alone (7.4.10, rule 2). Seats more than 1 mm apart are said. Where the least seat is less, it is said, and the trusses are taken to stand on the plane (rule 3). 6. **A ridge beam in a gable.** For each ridge beam bearing in the wall, x0 to x1 its width about its x, held within the frame (none where that is under 10⁻⁶), in each framed layer whose inner face lies past the beam's end, y1 more than its y plus 10⁻⁶: where the layer holds its end (its outer face y0 at or before it), its **post** stands from the layer's bottom at x0 and x1, the higher, raised to the top of each sole plate, second sole plate and header over x0 to x1 whose top lies at or under the beam's underside, up to the beam's underside: x1 − x0 wide and as deep as the layer, across all of it, keyed `beam-`, where that is at least w high (else said); and its members lose what lies in the rectangle from x0 to x1 and from the post's foot up to the beam's top, as section 7.4.8, rule 4 cuts them. Where the layer does not hold its end, its members lose what lies from x0 to x1 and from the beam's underside up to its top. 7. **A rafter's notch.** A wall attached `level` to a layer of a roof (`top.attach.face` names a layer) that has a truss layout reads the face raised by its family's `Notch`, at least 0, as well as by its `offset`: for its envelope (7.4.3, rule 2), its members' bodies (7.4.10) and its top as rule 3 of 7.4.13 reads it. These are class-A rules, held to the tolerances of section 10. *Note (informative).* On the reference implementation's garage, second version, and its villa's frame, `@openeik/tools` lays out every member of every wall the reference does, 294 and 660, with its id, name, section and class; all agree exactly in box and volume but for nine top plates of the villa frame's gables, under their roof's face. The reference's clip gives five of them more volume than their outlines carried across their layer hold, by up to 1.4 %, as section 7.4's note says of one plate of its probe; three agree within a relative 3·10⁻⁶, and a sliver of 0.13 mm³ within 2·10⁻⁵ mm³; and four of their boxes differ by up to 9·10⁻⁶ mm, where a plate's top lies on that face and the line where the two meet is ill-conditioned. On the probe of 7.4.13's note, its 465 wall members agree exactly, and on the probe of 7.4.16's note, whose walls carry hip trusses and jacks, its 826. An end batten starts over a hole across its foot (7.4.8, rule 1), as the reference's does: a door's or a window's box there too, which no wall of 7.4's examples or probe had. Reference: `deriveWallFraming` (its `trusses`, `beams`, `applyBeamBearings` and `deriveHeelMembers`) in `src/core/elements/wallFraming.ts`; `trussLinesOnWall` and `beamBearingsOnWall` in `src/core/elements/trussLayout.ts`; `rafterNotch` and `wallTopClips` in `src/core/elements/wallTop.ts`. In `@openeik/tools`: `layoutLayer` in `packages/openeik/src/compile-framing-layout.js`, given its trusses by `trussLinesOnWall` and `beamBearingsOnWall` in `packages/openeik/src/compile-framing-roofs.js`. ### 7.4.15 A floor's joists These rules lay out a floor's joists from the joist rule of its type's layer (Part II, 5.1, a layer's `joists`): joists across the span between its bearing walls, trimmers beside its holes, headers across the edges the joists end at, rim joists on its bearing walls, and blocking in its end bays, each a rectangle in plan carried through the joist layer. In these rules lengths are in mm. 1. **A joist layer and its rule.** A slab whose type is a slab type with a layer that carries `joists` is laid out, by its first such layer. Its rule is read with these values for what it leaves out: `material` C24, `spacing` 600, `direction` auto, `rim` 45 wide (`null`: none), `trimmerPlies` and `headerPlies` 2, and `blocking` with `endBays` true and `spacing` 600. A rule without a member's `width` is not read (`framing-layout-joists`). A joist is w, the member's `width`, wide, and d, its `depth` else the layer's thickness and at most that, deep; the layer's top lies under the slab's top, its level's elevation plus its `offset`, by the layers before it, and its underside d under that: z0 and z1, each to 0.001. A validator warns of a rule on a layer of a type that is not a slab type, or whose member is deeper than its layer (`framing-layout-joists`). 2. **The posts through it.** A column whose base and top (its level's elevation plus its `offset`, and that plus its `height`) reach more than 1 mm into the layer from below and above (top more than z0 + 1, base less than z1 − 1) is a post: a square of its `width` about its first point. So is a ridge post of a truss layout (7.4.13, rule 11) that does: the box of its corners in plan. A post is kept where its box overlaps the box of the floor's outline (its `profile`). Columns are taken in the order of their ids, then the ridge posts, the roofs in the order of their ids. 3. **Its bearing walls.** The framed walls, in the order of their ids, a point of whose baseline lies within 1000 of the outline's box, each with a framed layer that, laid out with no truss on it, ends under this floor (its bearing floor, 7.4.4, rule 4): the first such layer. A bearing wall gives its layer's faces, y0 and y1, and its own faces, 0 and T, as lines in plan. 4. **The joists' direction.** With `direction` auto, the normal (−u_y, u_x) of a bearing wall across which the outline is least wide (the greatest less the least of its points' products with it), of equals the one that points the most along +x, then along +y. Without a bearing wall, x where the outline's box is no wider in x than in y, else y, which is said. With a number θ, (cos θ, sin θ). The joists run along d, the direction; across them runs û = (−d_y, d_x), and a point p of the plan lies at u = p·û, v = p·d. 5. **Its holes.** Each of the slab's `voids`, and each shaft whose base lies under z1 − 1 and whose top over z0 + 1 (4.2, rule 8), is a hole: its box in (u, v), held within the outline's box, where it is at least 1 mm each way. Holes whose boxes touch or overlap, within 1 mm, are one, until none do. A hole whose corners, 1 mm in, do not all lie in the outline is not framed, which is said. Holes are ordered by their least u, then v, and keyed `h_`, each rounded to the millimetre. A hole wider in u than the spacing less w is framed; another that a joist overlaps is said. 6. **Its edges.** The outline, and each framed hole's box, its corners wound as the outline's, are rings. Each edge of a ring at least 1 mm long runs along the joists (less than 1 mm in u), at u its middle's, over its v; or across them (less than 1 mm in v), at v its middle's, over its u; or neither, and is not framed, which is said. An edge's inward side is the one the floor lies on, as the ring is wound; an outline's edge is a **hull** edge where no point of the outline lies more than 1/ℓ outside its line, ℓ its length. An edge is numbered by its place in the outline, from 0, or keyed `.` in a hole's ring. 7. **Where a joist ends.** An edge across the joists lies **on a bearing wall** where, of the bearing walls in order, the first has its layer's two faces and its own two faces so that, with v_in the layer's face nearer the floor's inside and v_out the other, and v_w the wall's own face nearer the inside: the edge lies no more than 60 inward past v_w, and no more than |v_out − v_in| + 60 outward of v_in; and the wall's baseline, widened by 300 at each end, overlaps the edge by at least 1 mm in u. A joist's end at an across edge (its v within 1 mm of it, the edge facing it, and its u within the edge's u, within 10⁻⁶) on a bearing wall is v_out less the rim's width, towards the joist; at another across edge it ends short of it by `headerPlies`·w; elsewhere at the floor's edge. 8. **Its members.** Its **joists' places** are: on each edge along the joists, a joist w/2 inward of a hull edge (keyed `e.0`), else `trimmerPlies` trimmers (`trimmer`), (k + ½)·w inward of it, keyed `e.`; and the grid, from the least u of the outline plus w/2 + spacing, every spacing, while it lies more than 10⁻⁶ under its greatest u less w/2, each keyed by its count from 1, but where it lies within w of a place on an edge; in order of u, each within 1 mm of the one before it dropped. Each place is a joist over each interval of the floor along its line (where the line lies inside the outline and outside the framed holes), from where it ends at the interval's one end to where it ends at the other (rule 7), where that is at least w; keyed `.` where its line has more than one interval. On each across edge on a bearing wall, where the rule has a rim, a **rim joist** of the rim's width on the outer face's inner side, along the edge, keyed by the edge; on each other across edge, `headerPlies` **headers** w wide, the first against the edge, inward, keyed `.`. Where `blocking.endBays` is true and the floor has two joists' places or more, **blocking** in its first bay and its last (the first two places and the last two; one bay where there are two): for each interval of one joist and each of the other, from where they overlap plus the blocking's spacing, every spacing, while less than where they end less w, a row w wide about it, from one joist's side to the other's, keyed `..`. A member is a rectangle in (u, v) at least 1 mm each way. 9. **Posts cut its members.** Each post, in order, as its box in (u, v), cuts each member it overlaps by more than 10⁻⁶ into its parts before it and after it along the member's length (v where the member is at least as long in v as it is wide in u, else u), each kept where it is at least 1 mm each way; a member cut in more than one part is keyed `.`, k from 0. 10. **Each member: its name, its section and its class.** A member's id is `:::`; its name its role's name and its key, `joist 3`, `rim joist 1`; its section its width across its length by d, each to 0.001 and then to 0.1, `45 × 220`; its length along it; its material its rule's `material`. Each role's name and its IFC4 class, predefined type and user type: | Role | Name | IFC class | Predefined type | |---|---|---|---| | `joist` | joist | IfcBeam | JOIST | | `trimmer` | trimmer joist | IfcBeam | JOIST | | `rimJoist` | rim joist | IfcBeam | USERDEFINED, RIMBOARD | | `header` | header | IfcBeam | USERDEFINED, HEADER | | `blocking` | blocking | IfcMember | USERDEFINED, BLOCKING | 11. **Its body, and in IFC.** A member's body is the closed body of its eight corners (7.4.13, rule 14): its start's four, at its least along its length, and then its far end's, each at its two sides across, at z1 and then at z0, each plan point to 0.001. A bridge writes each member under its floor by an IfcRelAggregates, as section 7.4.11 writes a wall's. These are class-A rules, held to the tolerances of section 10. *Note (informative).* On the reference implementation's villa frame (its `main` `f2bc53d2`), whose upper floor's 53 joists, trimmers, rim joists, headers and blocking frame a stair's opening in its outline and are cut by the two ridge posts through it, and on the two floors of 7.4.13's probe, 71 members (a column through one, a hole, joists turned 90° without rims or blocking, single plies and a slanted edge), `@openeik/tools` lays out every member the reference does, each with its id, name, section, class, box and volume exactly, and the print writes each with the GlobalId, class, name and tag of the reference's own print. Where two bearing walls span the floor alike, as two opposite walls always do, the reference takes the first in the order of its elements, which section 9 of Part III gives no meaning; rule 4 turns the direction to +x, then +y, which is the reference's on its villa frame. Reference: `joistLayer`, `postsThroughFloor`, `floorFramingFor` and `floorFramingSolids` in `src/core/elements/floorFraming.ts`; `floorFramingRuleSchema` in `src/core/elements/floorFramingRule.ts`; `floorHoles` in `src/core/elements/floorOpenings.ts`; `framingIfcClass` in `src/core/elements/framingIfc.ts`. In `@openeik/tools`: `floorLayoutOf` in `packages/openeik/src/compile-framing-floors.js`, called by `framingLayouts` in `packages/openeik/src/compile-framing-layout.js`. ### 7.4.15.1 What a floor's members bear on *Part of 0.4. OpenEik 0.3 had it as the proposal `bearsOn` (open questions, 130): a model of 0.3, read by 0.3's rules (Part I, 9.6, rule 3), is read by it only where a caller asks for it (decision D12).* Each member of a floor's joists names what it bears on, in the form of 7.4.13.1, rule 1. 1. **A joist and a trimmer.** Each end bears on the bearing wall it runs onto (rule 7), or on the header it ends at, every ply of it; an end at an outline edge that is neither bears on nothing the rule finds. 2. **A rim joist** bears along its bearing wall, which it names at both ends. 3. **A header** bears at each end on the trimmers beside the hole there, every ply of them. 4. **Blocking** bears at each end on the joist beside it. 5. **A member a post cuts** (rule 9) bears on the post at each end the post cut, and keeps at its other end what the member it was cut from bore on. Reference: none in the reference implementation. In `@openeik/tools`: `floorLayoutOf` in `packages/openeik/src/compile-framing-floors.js`, asked for with `compileModel(model, {proposals: ["bearsOn"]})` on a model of 0.3. ### 7.4.16 A truss layout's hip ends These rules frame each hip end of a truss layout (7.4.13, rule 2) as the reference implementation lays out a hipped roof's trusses: a **girder** of plies where the ridge ends, a **hip truss** of plies up each hip line to it, and **jacks** square to the end and to the sides up to them; or, where hips at both ends leave a short ridge, one **girder along the ridge**, which half trusses from both eaves hang on. Hip trusses and jacks are trusses of the layout's **jack family**, a girder along the ridge of its **flat-top family**: families written in the language of Part II, 5.4, which the rules make of the layout's own family where the model holds none (rule 2). In these rules lengths are in mm and points in plan. τ, r, `across`, `along`, the origin, the bearing plane E and w are those of 7.4.13 (rules 1, 2 and 4); P(t, r) is the point origin + along·r + across·t; τ_L(r) and τ_R(r) are where the line across the roof at the place r meets the two sides' reference faces (7.4.13, rule 6); and z(p) is the height over p of the face the chords' top lies on (7.4.13, rule 7). 1. **Its hip ends and its rule.** A layout of two sides frames its hip ends; one whose `hips.frame` is false frames none, and says them (7.4.13, rule 2). Its `hips` is read with these values for what it leaves out: `system` auto, `girderPlies` 2, `hipPlies` 2, `minJack` 400, and `jackSpacing` the layout's `spacing`. Of a hip end's face, g its gradient (the plan direction it rises in, |g| the tangent of its pitch): its **pitch** is atan |g| in degrees, to 0.001; it lies at the **start** of the ridge where g·along is more than 0, else at its **end**; its **apex** a_r is the greatest r of its polygon's points at the start and the least at the end, and a_τ the mean τ of its points whose r lies within 1 of a_r: where its hip lines meet the ridge. Where two hip ends or more lie at one end of the ridge, the one of the longest edge is framed, of equals the first in the order of the faces, which is said. 2. **Its families.** The jack family is the `framing` of the model's type whose id is the layout's family type's id followed by `-jack`, where the model has one with a `framing`, and the flat-top family that of the type whose id is followed by `-flat`: the layout uses such a type, and a validator does not warn of it as of a library record the model does not use (Part III, 13, rule 2). A family the model holds ought to be a truss family (7.4.13, rule 1), and a flat-top family to declare `FlatLength` of the scope `instance` as well; a validator warns of one that is not, which it can tell from the records alone (`framing-layout-roof`), since a compiler leaves out each hip truss and jack, or each girder along the ridge, it cannot build (rules 7 and 8). Where the model holds none, each is made of the layout's family f, as follows. A **rafter family** is one whose `trussStyle` is `rafters` or `collar`. - Its parameters are f's but `Pitch`, `HeelHeight`, `OverhangLeft` and `OverhangRight`, in their order; then, where f has none of the name, `Width` (45, from 20 to 200) and `ChordDepth` (170, from 45 to 600), and, but in the jack family of a rafter family, `BottomDepth` (170, from 45 to 500) and `WebDepth` (95, from 45 to 300), each of the scope `type`; then `Pitch` (20, from 1 to 75), `HeelHeight` (200, from 0 to 5000), `OverhangLeft` (500, from 0 to 3000), `OverhangRight` (0 in the jack family, 500 in the flat-top family, from 0 to 3000) and, in the flat-top family, `FlatLength` (0, from 0 to 50 000), each of the scope `instance`; each with its `value` and then its `min` and `max`. - It has f's `tail`. The jack family's `trussStyle` is `rafters` where f is a rafter family, else `mono`; the flat-top family has none. - Its parts are the `member` parts of the tables below, each `Width` wide, in their order. A point is its x and its z; a plumb cut at x is the cut from (x, `0`) to (x, `1`); and in the tables B stands for the expression `BottomDepth/2`, C(x) for `HeelHeight-ChordDepth/(2*cos(Pitch))+tan(Pitch)*(x)`, D(x) for `HeelHeight-ChordDepth/(2*cos(Pitch))+tan(Pitch)*(Length-(x))`, K(x) for `HeelHeight-ChordDepth/cos(Pitch)+tan(Pitch)*(x)-BottomDepth`, X1 for `(Length-FlatLength)/2`, X2 for `(Length+FlatLength)/2`, F for `HeelHeight+tan(Pitch)*(Length-FlatLength)/2-ChordDepth/2` and W for `FlatLength-WebDepth-20`, each written out with the text of x, X1 or X2 in its place: C(`Length/2`) is `HeelHeight-ChordDepth/(2*cos(Pitch))+tan(Pitch)*(Length/2)`, X1`/2` is `(Length-FlatLength)/2/2`, and K(`0`)`-45` is K(`0`) followed by `-45`. The jack family of a rafter family has the part `top` alone, with no `cutBy`; any other jack family has these nine: | Part | Role | `a` | `b` | `depth` | `when` | Plumb cuts at | `cutBy` | |---|---|---|---|---|---|---|---| | `bottom` | bottomChord | `0`, B | `Length`, B | `BottomDepth` | | | | | `top` | topChord | `-OverhangLeft-ChordDepth`, C(`-OverhangLeft-ChordDepth`) | `Length+OverhangRight+ChordDepth`, C(`Length+OverhangRight+ChordDepth`) | `ChordDepth` | | `-OverhangLeft`, `Length+OverhangRight` | `bottom` | | `heelL` | heelPost | `WebDepth/2`, B | `WebDepth/2`, C(`WebDepth/2`) | `WebDepth` | K(`0`)`-45` | | `bottom`, `top` | | `post` | web | `Length-WebDepth/2`, B | `Length-WebDepth/2`, C(`Length-WebDepth/2`) | `WebDepth` | K(`Length-WebDepth`)`-45` | | `bottom`, `top` | | `diag` | web | `Length/2`, C(`Length/2`) | `Length-WebDepth`, B | `WebDepth` | `min(Length-1200,3000-Length)` | | `bottom`, `top`, `post` | | `post1` | web | `Length/3`, B | `Length/3`, C(`Length/3`) | `WebDepth` | `Length-3000` | | `bottom`, `top` | | `post2` | web | `2*Length/3`, B | `2*Length/3`, C(`2*Length/3`) | `WebDepth` | `Length-3000` | | `bottom`, `top` | | `diag1` | web | `Length/3`, C(`Length/3`) | `2*Length/3`, B | `WebDepth` | `Length-3000` | | `bottom`, `top`, `post1`, `post2` | | `diag2` | web | `2*Length/3`, C(`2*Length/3`) | `Length-WebDepth`, B | `WebDepth` | `Length-3000` | | `bottom`, `top`, `post2`, `post` | The flat-top family has these fourteen: | Part | Role | `a` | `b` | `depth` | `when` | Plumb cuts at | `cutBy` | |---|---|---|---|---|---|---|---| | `bottom` | bottomChord | `0`, B | `Length`, B | `BottomDepth` | | | | | `topL` | topChord | `-OverhangLeft-ChordDepth`, C(`-OverhangLeft-ChordDepth`) | X1`+ChordDepth`, C(X1`+ChordDepth`) | `ChordDepth` | | `-OverhangLeft`, X1 | `bottom` | | `topR` | topChord | X2`-ChordDepth`, D(X2`-ChordDepth`) | `Length+OverhangRight+ChordDepth`, D(`Length+OverhangRight+ChordDepth`) | `ChordDepth` | | X2, `Length+OverhangRight` | `bottom` | | `topFlat` | topChord | X1, F | X2, F | `ChordDepth` | W | | | | `heelL` | heelPost | `WebDepth/2`, B | `WebDepth/2`, C(`WebDepth/2`) | `WebDepth` | K(`0`)`-45` | | `bottom`, `topL` | | `heelR` | heelPost | `Length-WebDepth/2`, B | `Length-WebDepth/2`, D(`Length-WebDepth/2`) | `WebDepth` | K(`0`)`-45` | | `bottom`, `topR` | | `postL` | web | X1, B | X1, F | `WebDepth` | `min(`W`,`K(X1)`-45)` | | `bottom`, `topFlat`, `topL` | | `postR` | web | X2, B | X2, F | `WebDepth` | `min(`W`,`K(X1)`-45)` | | `bottom`, `topFlat`, `topR` | | `king` | web | `Length/2`, B | `Length/2`, `HeelHeight+tan(Pitch)*`X1 | `WebDepth` | `min(WebDepth+20-FlatLength,`K(X1)`-45)` | | `bottom`, `topL`, `topR` | | `diagL` | web | X1`/2`, C(X1`/2`) | X1`-WebDepth`, B | `WebDepth` | X1`-1500` | | `bottom`, `topL`, `postL`, `king`, `vertL` | | `diagR` | web | `Length-`X1`/2`, D(`Length-`X1`/2`) | X2`+WebDepth`, B | `WebDepth` | X1`-1500` | | `bottom`, `topR`, `postR`, `king`, `vertR` | | `vertL` | web | X1`/2`, B | X1`/2`, C(X1`/2`) | `WebDepth` | X1`-3000` | | `bottom`, `topL` | | `vertR` | web | `Length-`X1`/2`, B | `Length-`X1`/2`, D(`Length-`X1`/2`) | `WebDepth` | X1`-3000` | | `bottom`, `topR` | | `diagFlat` | web | X1`+WebDepth`, B | X2`-WebDepth`, F | `WebDepth` | `FlatLength-800` | | `bottom`, `topFlat`, `postL`, `postR` | 3. **The ridge's range and its girders.** At a hip end, rule 5 of 7.4.13 is changed so. The range starts at the start's hip end's apex a_r, and ends at the end's. Where the layout has hip ends at both ends, its family's `trussStyle` is neither `rafters` nor `collar`, and its `hips.system` is `ridgeGirder`, or `auto` and the range is shorter than 2·`spacing`, it has a **girder along the ridge** (rule 8), and no truss is placed by 7.4.13, rule 5. Else, where it has hip ends at both ends and the range is shorter than 2·`girderPlies`·w + 1, the two **share** one girder: the range is narrowed to `girderPlies`·w about its middle, and its one truss stands at its first place. The first place is the range's start plus w/2 where a hip end lies at the start, else plus `endOffset` + w/2, and the last its end less w/2, or less `endOffset` + w/2; with no girder along the ridge, a last place more than 10⁻⁶ before the first is a finding. Where a hip end lies at the start and its girder is not shared, each place but the first that lies less than w − 10⁻⁶ past the first place plus (`girderPlies` − 1)·w is dropped; where one lies at the end and its girder is not shared, each place but the last that lies less than w − 10⁻⁶ before the last place less (`girderPlies` − 1)·w. The truss at the first place, where a hip end lies at the start, and the one at the last, where one lies at the end and the girder is not shared, is a **girder**: `girderPlies` trusses of the layout's family by 7.4.13's rules, its plies, the k-th, from 0, at its place plus k·w where it is the first truss, else less k·w; all of its mark, keyed by its index and, after the first ply, `:ply` (`0`, `0:ply1`). 4. **A hip set's end bearing.** Each hip end gets a **hip set**, laid after the layout's other trusses: with no girder along the ridge, the start's and then the end's; with one, as rule 8 says. With s 1 at the start and −1 at the end, its **girder face** G is the range's start or end (rule 3), or, under a girder along the ridge, its apex a_r; and its **heel** h is the heel of 7.4.13, rule 7 at the first place (at the start) or the last (at the end): the layout's `heelHeight`, else z at the left point of the line across the roof there, less E; under a girder along the ridge, at the middle of the two apexes. Its **bearing line** is a place R along the ridge: with Z(r) = z(P(a_τ, r)), r1 = G − 100s, r2 = G − 1100s and m = (Z(r1) − Z(r2))/1000, R = r1 − s(Z(r1) − (E + h))/m where m is more than 10⁻⁶, else G − 1000s. Then its **end wall**: of the walls and the beams of two points or more, none with a `frameHost` and none a bearing of the layout, each running across the span within 5° (its first two points' direction, at least 1 mm apart) and overlapping the span between the two sides' reference faces (7.4.13, rule 5) in τ by at least half of it, whose first point's r lies within half its thickness (a beam's `width`) plus 1000 of R; each one's bearing found as rule 4 of 7.4.13 finds a side's, with r and τ exchanged (its reference face, by its `bearingReference`, the one of the lesser r at the start and of the greater at the end; its run in τ), where that bearing lies within 300 of E and its reference face, at its first point, within 300 of R in r; the one whose first point's r lies nearest R, the first by id of equals. Where it has one, R is that face's r. A set whose R is not finite, or that leaves less than 500 from R to G (s(G − R) < 500), frames nothing, which is said. 5. **Its hip trusses.** The hip face's edge's two points in the roof's outline (its stored `profile`) are its left corner p_L, of the lesser τ (the edge's first of equals), and its right p_R; its apex point A = P(a_τ, a_r). For each side, its **hip line** runs from its corner p towards A: d = (A − p)/|A − p|, d_τ = d·across and d_r = d·along; it crosses the bearing line at τ = t_0 = τ(p) + (R − r(p))·d_τ/d_r, or τ(p) where |d_r| is 10⁻⁹ or less; and it starts at S, the point of it nearest the corner of the bearing lines, P(τ_L(R), R) on the left and P(τ_R(R), R) on the right. With ν the greater over the two sides of (w/2)|d_r|/|d_τ| (0 where |d_τ| is 10⁻⁹ or less), the **centre jack** is s(G − R) − ν long, and stands where the set has no girder along the ridge and it is at least `minJack`. The half width κ kept clear of the ridge line is `girderPlies`·w/2 under a girder along the ridge, else w/2 where the centre jack stands, else 0. Then, the left side's first: with n = (−d_y, d_x) and b = `hipPlies`·w/2, its **drop** is b·max(|g_s·n|, |g·n|), g_s the gradient of the side's eave face and g the hip face's; its **pitch** atan((z(A) − z(S))/|A − S|) in degrees; and its **heel** z(S) − E less the drop. Each ply, k from 0 to `hipPlies` − 1, runs from a = S + n·(k − (`hipPlies` − 1)/2)·w along d for its **reach**, the least, over its corners a ± n·w/2, of (G − r(corner))/d_r, where the set has no girder along the ridge and |d_r| is more than 10⁻⁹, and of (λ − τ(corner))/d_τ, where κ is more than 0 and |d_τ| more than 10⁻⁹, λ = a_τ − κ on the left and a_τ + κ on the right. A ply whose reach is not more than 300 is not laid. Each other is a **hip truss** (rule 7), keyed `:hip::` (`start:hip:left:0`), of the mark `H<2j+1>` on the left and `H<2j+2>` on the right, j the number of hip sets framed before this one; it bears on the side's bearing that stands at R (the first whose run holds R within 1 mm, 7.4.13, rule 4), else on the end wall, else on nothing. 6. **Its jacks.** A **jack** runs from a point a along a direction d for a length L: its heel z(a) − E, and its pitch atan((z(a + dL/2) − z(a))/(L/2)) in degrees. One shorter than `minJack` is not laid. Each other takes the mark `J`, i counting the layout's jacks from 1 in the order they are taken, and is a truss of rule 7. With J the `jackSpacing`, a set's jacks are, in this order: - its centre jack (rule 5), from P(a_τ, R) along s·along, keyed `:jack:c`; - its **end jacks**, the left side's and then the right's, of each side where t_0, d_τ, d_r, τ_L(R) and τ_R(R) are finite and |d_τ| is at least 10⁻⁹: for k from 1 to 500, at t = a_τ − kJ on the left and a_τ + kJ on the right, each but where |t − a_τ| − w/2 is less than κ, and none more from where its near side, t_n = t − w/2 on the left and t + w/2 on the right, reaches the hip line or the side's corner (t_n at most max(t_0, τ_L(R)) on the left, at least min(t_0, τ_R(R)) on the right): a jack from P(t, R) along s·along, s(r_e − R) long, where r_e = R + (t_n − t_0)·d_r/d_τ − s·b/|d_τ|; keyed `:jack:el` on the left and `er` on the right; - its **side jacks**, at places r along the ridge: without a girder along the ridge, G − s(k + 1)J for k from 0 to 499, in that order, those where s(r − sw/2 − R) is more than 0; under one, its grid's places (rule 8), from the least, where s(r − sw/2 − R) is more than 0 and s(a_r − (r + sw/2)) is at least 0. The left side's and then the right's, of each side where t_0, d_τ and d_r are finite and |d_r| is at least 10⁻⁹, at the k-th place, from 1: with r_n = r − sw/2 and t_h = t_0 + (r_n − R)·d_τ/d_r, a jack from P(τ_L(r), r) along `across`, t_h − b/|d_r| − τ_L(r) long, on the left, and from P(τ_R(r), r) along −`across`, τ_R(r) − t_h − b/|d_r| long, on the right; keyed `:jack:sl` and `sr`. The centre jack and an end jack bear on the end wall where their τ lies within its run, within 1 mm; a side jack on the side's bearing that stands at its place. Jack or hip truss ends with no bearing are said. 7. **A hip truss or a jack as a truss.** Its parameters are its `Pitch` and `HeelHeight`, its `OverhangLeft`, how far its line runs on behind a inside the roof's domain (−t for the least t at which a + d·t lies in it, where that is finite and less than 0, else 0), and `OverhangRight` 0; each to 0.001. Its parts are the jack family's, built by section 6.6, rules 2 to 9, with its length L as `Length`; where they cannot be, it is left out, which is said, and its mark is given to no other. Its id is `:truss:`; its place, the r of the middle of a and b = a + dL, its points a and b and its span L are each to 0.001, at E. It bears on its left side only, on its bearing. Its **seat** there, where its bearing has the two faces of a frame (7.4.13, rule 4), is the least height of its pieces between the two distances along d from a at which its line crosses the faces' lines (7.4.13, rule 9), to 0.001, as its family's plane has it, with no change for the bearing's own elevation; it has none where d·k lies within 10⁻⁹ of 0 for a face, k the face's normal. 8. **A girder along the ridge.** Its two hip sets are laid out first, the start's and then the end's (rules 4 to 7), each with its side jacks at its grid's places. Its **grid** is the middle of the two apexes, M, and M ± kJ for k from 1 to 500, while either lies within 20 000 of the range, from least to greatest. With R_s and R_e the two sets' bearing lines, its line lies at τ_g, the mean of the two hip ends' a_τ, from r_0 = M − ℓ/2 to r_1 = M + ℓ/2, where ℓ = 2ρ + φ, φ = max(0, a_r(end) − a_r(start)) its **flat** and ρ = (a_r(start) − R_s + R_e − a_r(end))/2 its **rise**. Its pitch is the mean of the two hip ends' pitches; where they differ by more than 0.5°, that is said. Its drop δ is `girderPlies`·w/2 times the greatest |g·across| of the two eaves' gradients g, and its flat top φ + 2δ/tan(pitch) (φ where the tangent is 10⁻⁹ or less). It gives the flat-top family `Pitch`, its pitch; `HeelHeight`, z(P(τ_g, r_0)) − E; `OverhangLeft`, how far its line runs on before r_0 inside the domain, and `OverhangRight`, after r_1 (rule 7); and `FlatLength`, the lesser of its flat top and ℓ; each to 0.001. Where the family cannot be built with ℓ as `Length`, the girder is said, and neither it nor its half trusses are laid. Else its `girderPlies` plies, the k-th from 0 on the line at τ_g + (k − (`girderPlies` − 1)/2)·w from r_0 to r_1, each keyed `ridge:`, of the mark of the layout's first listed position, else T1, at the place M, of the span ℓ, bearing on the two sets' end walls, the start's on the left, with no seat. Then its **half trusses**: at each place r of its grid that lies between the two apexes, more than 10 from each (r − w/2 > a_r(start) + 10 and r + w/2 < a_r(end) − 10), the k-th from 1, a jack (rule 6) on the left and one on the right, from the side's reference face to the girder's side face: from P(τ_L(r), r) along `across`, τ_g − `girderPlies`·w/2 − τ_L(r) long, keyed `ridge:jack:l`, and from P(τ_R(r), r) along −`across`, τ_R(r) − τ_g − `girderPlies`·w/2 long, keyed `ridge:jack:r`, each bearing on its side's bearing that stands at r. 9. **Where they rest and hang.** A hip truss and a jack rest on their first side only, where they have a bearing (7.4.13, rule 12): an anchor pair at a. Each also hangs at its far end: a **hanger** of one bracket at b, at E, keyed `:hanger` and named `Hanger, hip truss to girder` for a hip truss, `Hanger, jack to girder` for a centre jack and a half truss, and `Hanger, jack` for any other jack. The layout's connections are its anchor pairs, in the order of its trusses, and then its hangers, in the same order. 10. **Names, members and IFC.** A hip truss is named `Hip truss` and its mark, and `(ply )` after it for a ply after the first; a jack `Jack truss` and its mark; a girder's ply `Truss` and its mark with `(girder)`, `(girder, ply )` after the first, and a girder along the ridge's with `along the ridge` after `girder`: `Truss T1 (girder, along the ridge, ply 2)` (7.4.13, rule 13). Each one's members are its family's parts, by 7.4.13, rules 13 and 14, its jack or flat-top family's for a hip truss, a jack and a girder along the ridge; their material is the layout's family type's. In IFC each is a truss of 7.4.13, rule 15. A hanger is an IfcMechanicalFastener in its roof's storey, its GlobalId from `fastener:`, its name its name, its object type `HANGER` and its predefined type USERDEFINED, with no body; it connects no element, since what it hangs on, a girder's or a hip truss's plies, is no one element. These are class-A rules, held to the tolerances of section 10: each member's body within 0.1 mm of the rules', and its volume within a relative 10⁻⁶; trusses, members, connections, their ids, names, sections and classes exactly. *Note (informative).* None of the reference implementation's examples has a hipped roof with a truss layout (its `main` `f2bc53d2`, 29 October 2026). On a probe of nine hipped roofs over houses of framed walls whose studs stand under the trusses (`packages/openeik/test/fixtures/framing-hips.json`: fink, king post, Howe, collar and rafter families; hips at one end and at both; girders across the ridge, a girder shared by two hip sets on a ridge 100 mm long, and girders along a short ridge and through a pyramid's apex; hip ends of 20° to 75° over eaves of 20° to 35°; one, two and three plies; a jack spacing and a least jack given; the model's own jack family; end walls framed, unframed and a beam, and a hip end with none, its jacks unborne; a heel given and the finish faces; places given, one standing in a girder's plies; a hip end too short to frame; and hip trusses and jacks with no heel, left out), `@openeik/tools` lays out every truss the reference does, 272 (29 common trusses, 23 plies of girders across the ridge and 4 along it, 56 plies of hip trusses and 160 jacks), with its mark, family, line, span, parameters, bearings and seat; every member, 1223 of the roofs and 826 of the walls under them, with its id, name, section, class, box and volume exactly; and every connection, 317 anchor pairs and 216 hangers. Its print writes each truss, member and connection with the GlobalId, class, tag and object type of the reference's own print, and its name as the reference's with its Swedish words put into these rules' English (`Valmstol`, `Kortstol`, `bärande`, `längs nocken` and `lager` as `Hip truss`, `Jack truss`, `girder`, `along the ridge` and `ply`; 7.4.13's note), 2854 objects, and passes IfcOpenShell's validation and buildingSMART's rules with no issue. Where two end walls lie alike, the reference takes the first in the order of its elements, which section 9 of Part III gives no meaning; these rules take the first by id. Reference: `hipEndsOf`, `hipSet`, `ridgeGirder`, `lineInside` and `seatOver` in `src/core/elements/trussHips.ts`; `jackFamily`, `flatTopFamily`, `jackType` and `flatTopType` in `src/core/elements/trussFamilies.ts`; `deriveTrussLayout` (its hip ends, its range at a hip, its girders and its `endWall`), `bearsOn` and `trussName` in `src/core/elements/trussLayout.ts`; `derivedFraming` in `src/core/io/ifcFraming.ts`; `exportIfc` (its fasteners) in `src/core/io/ifcExport.ts`. In `@openeik/tools`: `hipEndsOf`, `hipSet`, `ridgeGirder`, `jackFamily`, `flatTopFamily`, `hipFamilies` and `trussName` in `packages/openeik/src/compile-framing-hips.js`, called by `trussLayoutOf` in `packages/openeik/src/compile-framing-roofs.js`. ### 7.5 A room's boundary, ceiling and quantities *Part of 0.2. OpenEik 0.1 had it as the proposal `rooms`: in a model of 0.1, read by 0.1's rules (Part I, 9.6, rule 3), room boundaries are reference behaviour, as section 7.2 says. The section adds no file and no member: the members are those of a room's `room`, a wall's and a column's `roomBounding`, a room separator's profile and the project's `rooms` (Part II, 2, 6.1 and 6.3).* By the steward's decision of 26 October 2026, and of 30 October 2026 for a roof that comes down through the floor (open questions, 72), the boundary of a room placed by a point, found from the walls, columns, room separators and roofs round it, the ceiling of every room and its quantities are these rules, as the reference implementation finds them. A room drawn by hand (Part II, 6.1, rule 4) keeps its outline, and takes its ceiling and its quantities from them. A room's **level** is its `levelId`, and its **floor** that level's elevation plus its `offset`. Its **point** is its profile's one point; for a room drawn by hand, its outline's centroid where that lies in the outline, else the middle of the first of its diagonals, from a point to the next but one, that does, else its first point. 1. **What bounds rooms.** On a room's level, each wall and each column whose `status` is not `demolished`, and whose `roomBounding` is `true`, or which gives none and is no wall whose `offset` is 1900 mm or more, bounds rooms with its **plan**: - a wall's: the convex hull, in plan, of its layers' bodies (section 4.1) as its joins end them, its points at each end within 1 mm of the furthest along it moved 15 mm further out along it, so that a joint up to 30 mm wide between two walls in line closes. Each layer's band is taken from the wall's base to its top (section 5.1), between the heights at which the line its ends stop on changes. Each point at an end moves along the wall to the line section 7.4.2 joins that end on at its height: at a corner, its mitre (7.4.2, rule 8) over the heights its corner covers (rules 3 and 4), and its partner's outer face above and below them; at a T, the host's core face on its side (rule 7). It moves only where that takes it no further than half the wall's length, or all of it where the corner fits only with room for its mitre (rule 6), and no further than four times the wall's thickness and 1 mm; the band is then cut on the line, keeping the side of the wall's middle, or of its other end where the corner fits only so. An end with no corner and no T, and an end section 7.4.2 keeps free (`joinEnds`), stays square. A wall with a `wallOutline` runs from its outline's least x to its greatest, an end that reaches the wall's end stopping on its main join's line (7.4.2, rule 5), and every end kept within it; - a column's: the convex hull of its body in plan (section 6.1), its section's outline, or a square of its `width`, centred on its point and turned by its `turn`. An arc of the outline is the rule; a compiler MAY draw it in chords that come within 0.01 mm of it. Each room separator on the level bounds rooms with a **line** from each of its points to the next, where they are at least 1 mm apart, lengthened by 1 mm at each end. **A roof that comes down through the floor**, a loft's, bounds rooms too. A roof with a `roof`, but for a barrel vault, has a face for each of its planes that is the lowest of them over some of its extent (its outline, each edge moved out by its overhang, each corner where the moved edges' lines meet; section 4.4, rules 2 and 3): the part of its extent where that plane is the lowest, of more than 0.01 mm². Its underside over a face is that plane lowered by the roof's thickness measured square to it (4.4, rule 4; a thickness is its type's layers' total, else its `height`). Where that underside lies under the level's elevation plus 10 mm at a corner of a face and over it at another, of any of its faces, the part of each face where it lies at that height or under, of more than 1 mm², is a plan. And then the edges of the floors the level stands on bound rooms as lines, each at least 1 mm long and lengthened by 1 mm at each end: the edges of the union of the outlines of the slabs and foundations of the level whose top lies less than 1000 mm under its elevation and less than 300 mm over it, and of those of other levels whose top lies within 50 mm of it, and the edges of their `voids`; a demolished one, and a round footing, is no floor. 2. **The faces.** The plans and the lines cut the plane into faces: the parts of the plane outside every plan and off every line, each in one piece. A face that is bounded, and whose outer ring encloses more than 100 mm², is a room's face. Its **boundary** is its outer ring and its holes, the outer rings of the groups of plans and lines that touch one another, lie inside it and touch none of those round it. A line that ends inside a face is part of its boundary, which runs along it on each side; a line that touches no plan and no other line divides nothing and is part of no boundary. The boundary's points are where the plans' edges and the lines meet, found to the model resolution of 0.01 mm (section 10). 3. **A room placed by a point** has the boundary of the face that holds its point inside it, off every ring of the face's boundary. Where none does, as where the point lies on a ring or in a plan, it has the boundary of the first face that so holds the point moved 1 mm along +x, along −x, along +y or along −y, in that order. Where no face holds it, it has no boundary, and a validator SHOULD warn of it (`rooms-enclosed`). 4. **One room to a face.** Where the points of two rooms or more lie in one face, the room whose id comes first in code-unit order (Part III, 9) keeps it, and each of the others has no boundary; a validator SHOULD warn of each of them (`rooms-shared`). A room drawn by hand has its outline as its boundary, without holes, whatever faces it lies in. 5. **The ceiling** is a surface over the room's boundary, from which its height, its walls' areas and its volume are measured: - where its `room.height` is given, the level plane that far over its floor; - else, at each point, the lowest of the planes over the room that are there: the underside of each slab and each ceiling whose outline, as recorded, holds the room's point, and none of whose `voids` does, level at its top less its thickness (section 4.2, rule 1), where that is more than 100 mm over the floor, there everywhere; and, of each roof with a `roof` whose extent (rule 1) holds the room's point, or leaves three points or more of the room's boundary's outer ring cut on the inner side of each of the extent's edges' lines in turn (the part of the room under it, where the extent is convex), the underside, there over its extent alone: of a pitched roof, its face's planes lowered as rule 1 lowers them, and of a roof none of whose edges defines a slope, its top less its thickness. A roof's underside is taken where it is more than 100 mm over the floor at the room's point, if the extent holds the point, or at a corner or at the centroid of that cut part of the room; - where neither is, the level plane of the lowest level 1800 mm or more over the floor, else the room's element's `height` over its floor (the room height, Part II, 6.2); - where only roofs' undersides are, that same plane is the ceiling over the part of the room that no roof's extent holds. A slab, a ceiling or a roof whose `status` is `demolished` is none. A thickness is its type's layers' total, else the element's `height` (4.2, rule 1). A barrel vault (`roof.vault`), whose faces are reference behaviour, is no ceiling by rule: a room whose point its extent holds, or whose boundary it cuts as above, has no ceiling by these rules, and a compiler says so. 6. **The quantities**, under the names of IFC4's `Qto_SpaceBaseQuantities`. Each stretch of a room's boundary lies against the plan that holds the point 0.05 mm out of the stretch's middle, square to it and away from the room, else the point 1 mm out, else 3 mm out; of the plans that hold the point, a wall's before a column's before a roof's, and of two walls' the one whose id comes first in code-unit order. A stretch along a line lies against that line, a room separator's before a floor's edge. Any other stretch lies against nothing. The room's **walls** are its stretches that lie against walls and columns. - `NetFloorArea`: the area of its boundary's outer ring less its holes'. - `GrossPerimeter`: the length of its boundary, its outer ring and its holes. - `NetPerimeter`: the length of its walls, less, unless the project's `rooms.doorsFromSkirting` is `false`, the width along them of each door in them. - `GrossWallArea`: the area of its walls up to its ceiling: along each stretch, the ceiling's height over the floor, where the ceiling is above it. - `NetWallArea`: `GrossWallArea` less, for each door and each window in its walls whose area is at least the project's `rooms.openingMinArea` (m²; 0 where it gives none), that area times its width along them over its `width`, at most its whole area; and never less than 0. A door or a window is in the room's walls where its host is a wall one of the room's walls lies against, its opening (section 4.3, from its host's base plus its `offset`, `height` high) begins under the ceiling's highest point over the room and ends over its floor, and its span along its host, from `along` to `along + width`, overlaps by 1 mm or more the stretches against its host, each measured along its host's baseline: that overlap is its width along them. Its area is its type's `outline`'s, else its `width` times its `height`. - `NetCeilingArea`: the area of the ceiling's surface over the room's boundary, a sloped plane's measured on its slope. - `NetVolume`: the volume from the room's floor up to its ceiling over its boundary, where the ceiling is above the floor. - `Height`: `NetVolume` over `NetFloorArea`, the room's mean height. National area rules stay the application's (Part II, 8). 7. **The volume.** A room's body, for a bridge or a view, is its volume: over its boundary, from its floor up to its ceiling where the ceiling is above it, as a prism for each part of the boundary that lies under one set of the ceiling's planes. It is no body of the model's (Part II, 6.2: a room has none): it cuts nothing, and a clash check does not read it. These are class-A rules, held to the tolerances of section 10. *Note (informative).* These rules are the reference implementation's room finder, stated on class-A bodies and the joins of section 7.4.2, but where this specification decided otherwise. Its body kernel takes each wall and each column as the convex hull of its bodies as built, joins included, and each room separator and each floor's edge as a strip 0.2 mm wide. From the records, `@openeik/tools` agrees with it exactly on 32 of the 39 rooms of `packages/openeik/test/fixtures/rooms.json`, on each boundary, area, perimeter, ceiling, height, wall, skirting, opening, ceiling area and volume: 12 of a probe of 14 (a free-standing column, a room on a separator's line, two rooms in one face, a room open on one side, a 20 mm joint, a wall that bounds no room and a high one, a room round the outer corner of two joined walls, a corner whose wall stops 125 mm short, a gable wall drawn by its outline, a gable roof over a room, a room drawn by hand beyond its eaves and a loft under a roof that comes down through its floor), and 20 of the 25 rooms of its one example with rooms (its work 727, 29 October 2026). Each of the other seven lies beside a room separator or a floor's edge, which these rules draw as a line, as open question 72 decided: its area is larger by 0.1 mm along each such stretch, its perimeter by 0.2 mm at each end of one, and what rests on its walls by as little. With the reference's strips in place of the lines, the faces of rule 2 give every room of the example to 10⁻⁹ m². These rules leave the reference implementation to change where this specification decided otherwise, and where the reference contradicts itself: a room separator, and a floor's edge, as a line; two rooms in one face given to the one whose id comes first, where it gives the face to the one first in its list of elements; the element's `height` as the last ceiling, where it takes 2500 mm (open question 72); a room's ceiling area and volume under a roof whose extent is not convex measured over the extent as it is, where it cuts the room by the extent's edges as if it were convex, as it does not when it measures the room's walls; a door's or a window's opening from its host's base, as section 4.3 places it, where it measures from its host's level; a room's floor at its level plus its `offset`, as Part I, 4 places an element, where it takes its level alone; and a barrel vault no ceiling and no bound of a room, where it takes the facets of its own vault. None of these made a difference on the rooms compared. Reference: `roomsOf`, `roomBodies`, `roofBodies`, `levelFloors`, `pastEnds`, `traceUnion` and `enclosedRegions` in `src/core/elements/rooms.ts`; `joinedWallSolids` in `src/core/elements/wallJoinSolids.ts` and `profileSolids` in `src/core/geometry/profileGeometry.ts`, on the joins of `src/core/elements/wallJoins.ts`; `ceilingPlanes`, `roomEdges`, `roomQuantities` and `roomVolume` in `src/core/elements/roomQuantities.ts`; `spaceTriangles` in `src/core/io/ifcSpaces.ts`. In `@openeik/tools`: `roomContext`, `wallPlan`, `roofShape`, `levelBounds`, `planFaces`, `faceAt`, `roomsOf`, `ceilingOf` and `measureRoom` in `packages/openeik/src/compile-rooms.js`, on `wallJoins` in `compile-framing-joins.js`, built by `compileRooms` in `compile.js`. ### 7.6 A component's frame and its bodies *Part of 0.2. OpenEik 0.1 had it as the proposal `components` (Part II, 5): in a model of 0.1, read by 0.1's rules (Part I, 9.6, rule 3), what `componentInverted`, `axes`, `upright`, `plate`, `bolts`, `weld` and `insertAt` do to a component's body is reference behaviour, as Part II, 6.3 says. The section adds no file and no member.* By the steward's decisions of 26 October 2026 (open questions, 73), which completes his decision of 17 October 2026, and of 30 October 2026 (open questions, 99), a component's frame, and its bodies that are boxes and prisms, are class-A rules, as the reference implementation places and builds them but where question 99 decided otherwise. 1. **Its frame and its bodies.** A component (Part II, 6.2) stands in a frame: rules 2 to 4 give it, or, for a cast-in item placed by `insertAt`, rule 5 gives each of its items one. A point (u, v, w) of a frame is its origin moved u along its x, v along its y and w along its z. Its bodies are rule 6's and rule 7's, by its type's family (Part II, 5): a timber section's (`timberSection`), a plate's (`plate`), a weld's (`weld`, with the element's `weld`), a bolt group's (`bolt`, with the element's `bolts` and its type's `component.bolt`), and a cast-in item's block or bar (its type's `insert.shape`, `block` or `bar`). Rule 8 says what stays reference behaviour. A component that has no frame, as rules 2 to 5 say, has no body, and a validator SHOULD warn of it (`component-frame`). 2. **Its frame.** Its origin is its insertion point, its profile's first point, at its level's elevation plus its `offset`. Where it gives `axes`, they are its frame, whatever its family: its x is `axes.x` made a unit vector, its y is `axes.y` made square to x and a unit vector, and its z is x × y, or y × x where it is `flipped` (Part II, 6.3); `axes` whose x is zero, or whose y runs along x, give no frame. Without `axes`, its x runs in plan from its profile's first point towards its second, its y is the left normal of x in plan, or its right normal where it is `flipped`, and its z is up; a profile whose two points are one gives no frame (Part II, 6.1, rule 8). 3. **A plate on a column.** A plate whose `hostId` names a column stands on it: its origin is the column's centre, the column's profile's first point, at the column's top (5.2, rule 4) plus the plate's own `offset`. Its axes are rule 2's, from its own profile or its `axes`. A column without a level, a centre or a height gives it no frame. 4. **Hung down and stood up.** A component without `axes` whose `componentInverted` is `true` hangs its box (rule 6) or its plate (rule 7) down from its origin, from w = −`height` to w = 0, where it otherwise stands from w = 0 to w = `height`. A plate without `axes` whose `upright` is `true` stands on its edge: a point (u, v) of its outline lies u along its frame's x and v up, and its thickness runs along its frame's y, centred on its origin, from −`height`/2 to `height`/2, whatever its `componentInverted` says. Neither member changes a weld, a bolt group, a cast-in item or a component with `axes`, and `upright` changes a component of no other family. 5. **A cast-in item's frame.** A cast-in item, a component whose type has an `insert`, placed by `insertAt` stands in the wall its `hostId` names, whose profile is two points, P0 and P1: u = (P1 − P0)/L along the wall, L = |P1 − P0|, n the left normal of u, T the wall's thickness (4.1), H its `height`, and its base at its level's elevation plus its `offset`. - **Its point** lies `along` from P0 along u, `up` from the wall's base and `across` in from its exterior face: P0 + u·along + n·(T/2 − across), at the base plus `up`. `along` is 0 where it gives none, L on the face `end`; `up` 0, H on the face `top`; and `across` 0 on the face `exterior`, T on `interior` and T/2 on the others. - **Its ways.** The way into the wall from its face, d, is −n from `exterior`, n from `interior`, down from `top`, up from `bottom`, u from `start` and −u from `end`. Its length's way, x, is u on `exterior`, `interior`, `top` and `bottom`, and up on `start` and `end`; where its `turn` is 90, x is up on `exterior` and `interior`, and n on the others. Its third way is y = d × x. - **Its body** runs in along a = d·cos(tilt) + x·sin(tilt), `tilt` in degrees, 0 where it gives none: a point (u′, v′) at a depth δ lies at its point + u′·x + v′·y + δ·a, so that a body that leans keeps its end in its face. - **Its items.** It has `count` items, 1 where it gives none, the k-th, from 0, `k`·`spacing` further along the wall, or up it where its `direction` is `up`, `spacing` 0 where it gives none. Its `profile`, `levelId` and `offset` are its writer's copy, which a reader ignores where `insertAt` is given (open questions, 73). A cast-in item whose `hostId` names no wall whose profile is two distinct points has no frame, and one that `insertAt` does not place has no body. 6. **A timber section** is a box in its frame: u from −`width`/2 to `width`/2, v from −`depth`/2 to `depth`/2, and w from 0 to `height` (rule 4), its `width` and `height` the element's and its `depth` its type's `component.depth`. 7. **A plate, a weld, a bolt group, and a cast-in item's block and bar.** - **A plate** is its outline less its holes, `height` thick. Its outline is its own `plate.outline`, points (u, v) in its frame, else its type's `width` by its `component.depth`, centred on its origin; its holes are its type's `component.holes` and its own `plate.holes`, each a circle of its `diameter` centred at (x, y), or, where its `length` is more than its diameter, a slot that long overall along `angle` degrees from u, its ends half circles (Part II, 5); its thickness runs from w = 0 to w = `height` (rule 4). - **A weld** is a fillet: the triangle (v, w) = (0, 0), (leg, 0), (0, leg), leg = `weld.throat`·√2, carried along u from 0 to its `width` (Part II, 6.3). - **A bolt group** is each bolt's shank within its grip: at each of its `positions` (u, v), a cylinder of its bolt's `diameter` along w, from w = 0, the face its head, or an anchor's nut, bears on, to w = `grip` (open questions, 99). - **A cast-in item's block** is, at each item, the box from u′ = −`width`/2 to `width`/2 and v′ = −`height`/2 to `height`/2, its type's, run in from δ = 0 to δ = `insert.depth` (rule 5); **its bar**, the round bar from δ = 0 to `insert.depth` along a, its `insert.diameter` round, else its type's `width`. A compiler MAY draw a hole's circle and a slot's ends in straight pieces, as it draws a pipe's circle (12.3, rule 5): the circle is the rule, and a component's volume is its bodies', its holes' circles exact. 8. **What stays reference behaviour** (class C): a bolt's head, washers and nut, an anchor's plate and the nut at its foot, and a shank past its grip, sized from a table of ISO bolts no record holds; the holes a bolt group drills in what its `through` names, a plate among them (7.2); an angle bracket's and a joist hanger's legs and nail holes; a cast-in item's lattice tie, its conduit and its bends, the cut its recess former makes in its wall, and the bar and the edge detail its product asks for at each item; a void form's and an edge detail's bodies; and the shapes of the families `toilet` and `basin`, deprecated in 0.2 (Part II, 5). A compiler says which of them a component has, and a supplier who needs one of them exact declares it (Part II, 12.1). These are class-A rules, held to the tolerances of section 10. A component's IFC class is its type's (Part VIII, 1, its note on components): a plate an IfcPlate, a bolt group an IfcMechanicalFastener, a weld an IfcFastener WELD, and any other an IfcBuildingElementProxy. *Note (informative).* Question 99 decided the two places where the reference implementation does what the records do not say. (a) It runs a hex bolt's shank from under its head's washer for the group's `length`, else for a length its table of ISO bolts picks, and an anchor's and a rod's between ends the same table gives (`assemblyPieces` and `rodSpan` in `src/core/elements/bolts.ts`); rule 7 takes the shank within the grip, which every bolt has whatever a table says, and which is what the parts it passes through are drilled for. (b) It places a box, a timber section, by its profile and does not read its `axes`, and its validator says "Axes belong to a plate, a bolt group or a weld"; rule 2 gives every component its `axes`, as Part II, 6.3 says, and the reference implementation changes for a box. Question 73 left a cast-in item's lattice tie and conduit to reference behaviour and made its frame a rule; its block, a box, and its bar, a round bar, are rule 7's, built from its records alone. Reference: `partFrame` in `src/core/elements/partFrames.ts`; `componentSolids`, `plateFrame` and `plateOutline` in `src/core/elements/components.ts`; `holeLoop` in `src/core/geometry/holedCells.ts`; `placedPlate` and `plateBaseZ` in `src/core/elements/plates.ts`; `weldSolids` in `src/core/elements/welds.ts`; `boltFrame` and `boltGroupSolids` in `src/core/elements/bolts.ts`; `insertPoint` in `src/core/elements/inserts.ts`; `insertPlacements` and `insertSolids` in `src/core/geometry/insertSolids.ts`. In `@openeik/tools`: `componentFrame`, `castInItems` and `componentBodies` in `packages/openeik/src/compile-components.js`, called by `compileComponentBody` in `compile.js`. ## 8. Body kinds (informative) The reference compiler produces six kinds of body. The plan proposes them as the normative kinds N1–N6 of a later version. | Kind | Reference representation | |---|---| | N1. A vertical prism of a plan polygon | `profile`, `bottom`, `top` | | N2. A convex polyhedron, or a set of convex cells | `vertices`, `faces`, `cells` | | N3. A layer between two planes (pitched roofs) | prisms clipped by half-spaces | | N4. A member swept along a line, square to it | `vertices`, `faces`, with an `axis` | | N5. An exact cylinder or a rod | `round` (centre, radius); `rod` (two points, diameter) | | N6. An opaque mesh with a stand-in box | `shape` (indexed mesh), with a `proxy` body for sections and quantities | A pipe's or a duct's body (section 12) is a closed mesh of `vertices` and `faces`; the reference implementation also cuts it into convex cells between its rings (N2), so that a section shows a bend as a bend. Reference: the `Solid` type in `src/core/geometry/geometry.ts`. ## 9. Quantities (informative) The reference implementation reports, per element, a volume in m³ with its basis ("per-element solids; openings deducted; matching endpoint wall mitres included; other inter-element overlaps not deducted"), the volume of each layer, a wall's gross, opening and net area per side on its centreline, and a roof's sloped area, perimeter, eaves, verges and ridge. 0.1 does not standardise quantities; the plan proposes typed values `{value, unit, basis, rule, version}`. For `examples/one-storey-house` the reference compiler gives: | Element | Quantity | Value | By hand | |---|---|---|---| | `slab-ground` | volume | 33.8355 m³ | 10.3 m × 7.3 m × 0.45 m | | `slab-ground` | layer `concrete` | 7.519 m³ | 75.19 m² × 0.1 m | | `wall-south` | gross area, one side | 27.0359 m² | 10 m × 2.70359 m: the roof's underside over the centreline lies at 2700 + 350 − 300/cos 30° = 2703.59 mm | | `wall-south` | openings | 3.9 m² | 1.0 × 2.1 + 1.5 × 1.2 | | `wall-west` (gable) | gross area, one side | 25.9977 m² | 7 m × 2.70359 m + ½ × 7 m × 3.5 m × tan 30° | | `roof-main` | sloped area | 95.4706 m² | (10 + 2 × 0.3) m × (7 + 2 × 0.4) m / cos 30° | | `roof-main` | ridge | 10.6 m | 10 m plus two 0.3 m gable overhangs | These values are informative; they are what a conformance vector for this folder would check. ## 10. Tolerances and conformance (proposed) The plan proposes that a compiler conforms when, on published vectors, each element's bodies lie within a Hausdorff distance of 0.1 mm of the reference, volumes and areas within a relative error of 10⁻⁶, and counts are exact, with a model resolution of 0.01 mm. This specification publishes no vectors yet; until it does, the class-A rules above are the requirement and the table in section 9 is an example. Pipes and ducts, whose faceting is the reference implementation's and not the rule's, have a tolerance of their own (12.5). ## 11. A supplier's parts This section says what a supplier's parts (Part II, 12) ask of a compiler: declared geometry (Part II, 12.1) and railings for product systems (Part II, 12.2). ### 11.1 Declared geometry A type or an element may carry a supplier's declared geometry at a declared level of detail, with the aspects it is authoritative for (Part II, 12.1). A compiler treats it so: 1. **It derives nothing beyond what a record declares itself authoritative for.** From an envelope it MAY derive the space the part takes (its bounds, its volume as space taken, sections and plans through it), and nothing about what is inside: not its materials, its parts, a count of parts or a cut list. 2. **For a declared aspect, the declaration wins** over the compiler's own rule: a declared envelope replaces the body derived from the type's payload where a body stands for the space taken (clashes, sections, exports); declared positions replace a reference layout (the posts of a railing). 3. **For an aspect that is not declared**, the compiler derives as it does for any record of the category, and says which results come from the declaration and which from its own rules. 4. **It MUST NOT derive fabrication data from declared geometry.** When a declaration is authoritative for `fabrication`, a compiler or a bridge passes that data on as the supplier gave it, and does not work it out again. 5. **Nothing it derives is stored** (section 1): the declaration is a record's own content, and the results a compiler works out from it are derived like any others. 6. A bridge that exports a declared envelope as a product's body SHOULD say so in its fidelity report (Part VIII, 1), with the declaration's level. Reference: `declaredSolids` in `src/core/geometry/declaredBodies.ts` (rules 2 and 3: a declared envelope, or declared parts, drawn in place of the derived body for 3D, sections, quantities and IFC). *Note (informative).* Whether the sizes a type sets (Part II, 5.3) must agree with its declared envelope was deferred to 0.2 by the steward on 15 October 2026 (open questions, 17). In 0.1 nothing requires it: the sizes size the record and the body this part derives from it, and rule 2 puts the envelope in that body's place where a body stands for the space taken. A declaration on a type of a category that Part II, 12.1 gives no frame for is placed nowhere, and a compiler derives nothing from it. Part II, 12.1.1 gives in 0.2 what the steward decided on 21 October 2026: the sizes stay nominal, and a stair's type and a wall's type get a frame, in which a compiler places their declarations. ### 11.2 Railing lines and posts The line of a railing on the outline of a slab or a shaft, and its given posts, are class-A rules. The line of a railing on a stair stays reference behaviour (class C): it follows the stair's derived flights. 1. **The run.** The edges `railing.edges` names are taken in their order round the host's outline, as one run (Part II, 12.2). The run's points are the outline's points from the start of its first edge to the end of its last; when it names every edge, the line is closed. 2. **The walking side** is the inside of a slab's outline, and the outside of a shaft's (the floor round an opening). 3. **The offset.** Each edge's line is moved towards the walking side by its inset: `railing.insets[]`, else `railing.inset`, else 50 mm (the reference default). A negative inset moves it off the edge, as side mounting needs. When every edge of the run has the same inset, each corner moves along its bisector by the inset divided by the cosine of half the turn at the corner, but never by more than 4 times the inset. When the edges' insets are not all the same, every corner of the run is where the moved lines of its two edges cross, or halfway between their ends where those lines are parallel or cross farther than four times the larger inset from the corner (Part II, 12.2). 4. **The base.** The line stands on the host's top: `elev(levelId) + offset` of a slab, or the top of a shaft (section 5.1). 5. **Given posts.** With `railing.posts.at`, a post stands at each listed distance `s` along the line from its first point, measured in plan, and nowhere else. A post is `postWidth` along the line by `postDepth` across it (`post` by `post` without them), centred on the line and square to its segment (at a corner, square to the corner's bisector). It rises from the base, or from `belowBase` below it when `mount` is `side`, to the underside of the top rail, which carries the railing to its `height` above the base. 6. **Without given posts** the layout is reference behaviour. The reference implementation places a post at both ends, at every corner, and evenly between them, no farther apart than `postSpacing`; with `postEndDistance` it stands the first and last posts that far from the ends, and it leaves out the end posts `posts.omit` names. 7. Rails, infill and handrails stay reference behaviour. By the steward's decisions of 21 and 24 October 2026 (Part II, 12.2; open questions, 18), in 0.1 since 24 October 2026, the lines of railings on a wall's top and along a slab edge element are derived so; both are class-A rules, a slab edge element's since its section became one on 26 October 2026 (section 4.6): 8. **On a wall's top.** Let `a`, `b` be the wall's baseline, `L` its length, `u = (b − a)/L`, `n` its left normal and `T` its thickness (4.1), and `d` the railing's `inset`, else `T/2`. A point `x` along the wall, from 0 to `L`, is at `a + u·x + n·(T/2 − d)` in plan. Its height is the wall's top there: where the wall has an elevation outline (an attached top, a profile of its own; section 5.3), the upper edge of that outline, with a point at each of its corners and two at one `x` where the top steps; else the wall's height over its base. The line runs from one end of the baseline to the other. 9. **Along a slab edge element.** With the element's section across its edge, its rectangles and its facing, as section 4.6 places them (its chamfer not counted), its outer face is the least reach of the section from the edge's line, `r_out`, and its top face the part of the section within 0.5 mm of its highest point, from reach `r0` to `r1`. The line runs at the reach `r_out + d` from the edge's line, `d` the railing's `inset`, else `(r0 + r1)/2 − r_out`, along the element between its own ends, square, or on a corner's bisector where the element is mitred (4.6, rule 6), at the height of the element's top, and never below its slab's top. 10. **Walking side** (rule 2): a wall's interior, the right of its baseline; the slab's side of a slab edge element. 11. **Posts** stand by rules 5 and 6; on a wall's top, its corners include every point where the top steps or its slope changes. Reference: `railingLine` and `offsetLine` in `src/core/elements/railings.ts`; `offsetEdges` in `src/core/elements/railingEdges.ts` (different insets); `railingPosts` in `src/core/elements/railingPostLayout.ts`. ### 11.3 Generic elements A generic element (Part II, 6.6) has no shape but its declared geometry. 1. A compiler derives nothing for it beyond placing its declared bodies: its own declaration's, in the `world` frame, and its type's, in the frame of a category placed at a point (Part II, 12.1), at its insertion point, turned to its orientation, on its base. Where both declare an aspect, the element's wins (Part II, 12.1). 2. Its quantities are those of its declared bodies: a volume from its closed bodies, as space taken (11.1, rule 1), with the basis `declared`. 3. It cuts nothing, and no rule joins it to another element. *Note (informative).* The reference implementation has no `generic` category (Open questions, 2). ## 12. Pipes and ducts A pipe or a duct is a run (Part II, 6.2): its points in plan, a height for each, a size and a system. Its body is its outer section swept along the run with each corner rounded into a bend. The body and its quantities are class-A rules; the fittings found between runs (a branch where one run's end lies on another, a reduction or a joint where two runs meet end to end) stay reference behaviour (section 7.2). ### 12.1 The run Given a pipe or a duct with profile points `p_0 … p_(m−1)`, its `mep` payload and its type: 1. **The points.** Point `i` of the run is `P_i = (p_i, elev(levelId) + mep.z[i])`: the heights are measured from the level, and the element's `offset` is not added. A run MUST carry `mep` with one height per profile point; one that does not has no body. Two points on one spot in plan, at two heights, make a vertical piece: the run climbs or drops there. 2. A run MUST have two points or more, not all at one place; else it has no body. 3. **The outer size.** Let `ins` be the run's insulation thickness (Part II, 6.9): its own `mep.insulation.thickness`, else its type's `pipe.insulation` or `duct.insulation`, 0 when it has none and 0 where its own `mep.insulation` gives `none`; where a pipe or its type gives a deprecated `bti`, its `thickness` (Part II, 6.9, rule 4). The run's outer width is `W = mep.size + 2 ins`. A duct whose type's `duct.shape` is `rectangular` has a rectangular section `W` wide and `H = h + 2 ins` high, where `h` is `mep.height`, or `mep.size` without it. Every other run, a pipe or a round duct, is round, `W` across; its `mep.height` is not used. `W` and `H` MUST be positive. 4. Two points in a row less than 1 mm apart, and a turn of more than 179° at a point, are not runs the reference implementation writes (its validator refuses them). A compiler builds them by the rules below and SHOULD say so. ### 12.2 Bends The **rounded path** replaces each corner of the run by a circular arc. For each inner point `P_i`, let `d0` and `d1` be the unit directions of the pieces `P_(i−1) P_i` and `P_i P_(i+1)`, and `θ = arccos(d0 · d1)` the turn there. 1. Where `θ < 10⁻⁴` (the run goes straight on) or `θ > π − 10⁻³` (it turns back), `P_i` stays a corner. 2. Otherwise the corner becomes an arc of radius `r = W`, the outer width, tangent to both pieces. The arc starts at `A = P_i − t d0` and ends at `P_i + t d1`, where `t = r tan(θ/2)`. 3. Where `t` is more than half the shorter of the two pieces, `|P_i − P_(i−1)|` and `|P_(i+1) − P_i|`, it is that half, and the radius shrinks to `r = t / tan(θ/2)`. So two arcs never overlap on one piece. Each corner is measured on the run's own points, not on its neighbours' arcs. 4. The arc is sampled at `k + 1` points, `k = max(2, ⌈θ / (π/12)⌉)`: with `n = unit(d1 − d0 (d0 · d1))` and the centre `c = A + r n`, point `j` is `c − r cos φ_j n + r sin φ_j d0`, where `φ_j = θ j / k`, for `j = 0 … k`. 5. The rounded path is `P_0`; then, for each inner point in order, its arc's `k + 1` points, or the point itself; then `P_(m−1)`. A point within 10⁻⁶ mm of the one before it is dropped (where two arcs each take half of one piece, the second starts where the first ends). A rectangular duct's bend has the radius of its width `W` whether it turns in plan or climbs. ### 12.3 The body The section is carried along the rounded path, one ring at each of its points `q_0 … q_(N−1)`, and the rings are joined into one closed mesh. 1. **The tangent** at `q_0` is the direction of `q_0 q_1`, at `q_(N−1)` that of `q_(N−2) q_(N−1)`; at an inner point it is `unit(unit(q_j − q_(j−1)) + unit(q_(j+1) − q_j))`, or the direction of `q_j q_(j+1)` where that sum vanishes. Each ring lies square to its tangent, with a side vector `s` square to the tangent and `u = unit(t × s)`. 2. **A round run.** Its ring is a circle of radius `W/2` about `q_j`, in the plane of `s` and `u`. Its side vector is carried along the path without twisting: at `q_0`, `s = unit(t × Z)`, or the x axis where the tangent is vertical; at each later point, the last `s` turned about `unit(t_(j−1) × t_j)` by the angle between the two tangents (not at all where they are parallel), then made square to `t_j` again. 3. **A rectangular duct.** Its section stays upright: the rectangle `W` along `s` by `H` along `u`, centred on `q_j`, with its width level. At each point `s = unit(t × Z)`, except that: where the tangent is vertical (`|t × Z| ≤ 10⁻⁶`), `s` is the previous point's (at a run that starts vertical, that of the first point that is not; on a run that is vertical throughout, the x axis); and where `s` would point away from the previous point's (`s · s_prev < −10⁻⁹`), it is reversed. So the section never turns end over end, and turns about the vertical only along a vertical piece that the run leaves in another plan direction than it came in (by 90° from −x to +y, say). 4. **The mesh.** The rings, each of `n` points in order counter-clockwise about the tangent, are joined by a four-sided face between each two rings at each side; the first ring, reversed, and the last close its ends. Every face turns counter-clockwise seen from outside. 5. The body is the section swept along the rounded path. Which points stand on each ring, and how many, is the reference implementation's faceting, not the rule: it draws a circle with `n = 20` points for a duct and `n = 14` for a pipe, point `j` at `q_j + (W/2)(s cos(2πj/n) + u sin(2πj/n))`, and a rectangle's corners at `q_j ∓ (W/2) s ∓ (H/2) u` in the order `(−, −)`, `(+, −)`, `(+, +)`, `(−, +)`. A compiler MAY facet the body otherwise, within section 12.5. The orientation of a rectangle (rule 3) is the rule. ### 12.4 Quantities 1. **The volume** is the section's area, `π W² / 4` for a round run or `W H` for a rectangular one, times the length of the rounded path as sampled (12.2.5): the sum of the distances between its consecutive points. It is the space the run takes, its insulation included; the fittings between runs are not in it. The volume a faceted body holds is less (by about 1.6 % for a circle of 20 points, 3.3 % for one of 14) and is not the quantity. 2. **The length** is measured along the run's own points in 3D, `Σ |P_(i+1) − P_i|`, each bend taken as its corner, as pipe and duct schedules measure it. ### 12.5 Conformance A compiler's body for a run conforms when its volume (12.4.1) is within 0.5 % of the rule's, its length (12.4.2) is the rule's, and each side of its bounding box lies within 2 % of the outer width `W` (and at least 1 mm) of the bounding box of the reference faceting of 12.3.5. Vertex counts need not match. `packages/openeik/test/fixtures/run-bodies.json` holds eighteen runs (straight, bent in plan, climbing, sloped, with short pieces and with insulation, a ventilation main with several bends and a climb) with the volume, length, bounding box and vertex count the rule gives, and the reference implementation's own results; `tools/run-bodies-reference.mjs` writes it from a checkout of the reference implementation. Reference: `runPoints`, `runOuter` (with `runInsulation` in `src/core/elements/mepInsulation.ts`), `bendRadius` (the outer width), `runLength` and `runSolids` in `src/core/elements/mep.ts`; `roundedPath`, `tangents`, `frames`, `tubeRings`, `boxRings`, `ringsToMesh`, `ringCells` and `pathLength` in `src/core/geometry/sweep.ts`. The volume is `runSolids`' `volumeMm3`. *Note (informative).* The reference implementation reads a run with no `mep`, which its validator refuses, with its type's `width` (else 100 mm) for its size and the element's `offset` for every height; and a point with no height of its own at the element's `offset`. These are the application's fallbacks, not the rule (12.1.1). It also gives the body its type's colour and material, hides it in plans, where a run is drawn by its symbol, and cuts it into convex cells between its rings for sections. It works out `θ` in floating point, so at a turn that is a whole multiple of 15° it can take one chord more than `⌈θ / (π/12)⌉` (four for a 45° bend between the directions (1, 0) and (1, 1)), within 12.5. Before `d0774a48` it differed from rule 3 of 12.3: where the tangent was vertical it took the x axis for `s`, and it did not keep `s`'s sense, so a rectangular duct that started or ended climbing, or climbed and came back the way it came, turned its section along the vertical piece. Since then it gives the rule's volume, length, vertex count and bounding box in all eighteen fixtures. *Note (informative).* The reference implementation takes a duct's insulation thickness from its code's entry in a table, its project's (`project.standards.mep.ductInsulation`) or its own, where the entry has one, before the type's `duct.insulation`: a duct whose code is `K25` is drawn 50 mm larger all round by it, and not by rule 3 (open questions, section 2, row 28). It gives no run its own thickness. ### 12.6 Terminals and components in a pipe or a duct A terminal (Part II, 6.9) is its declared geometry, where it or its type has one (Part II, 12.1), placed in the frame of a category placed at a point (section 11.1). Otherwise its body is a box of its type's `terminal.width` across the way it faces, `terminal.depth` along it and `terminal.height` high: centred on its point in plan, turned to the way it faces, from its base, `elev(levelId) + offset`, up. A terminal whose type gives no width, depth or height has no body. A component in a pipe or a duct stands where its run puts it, by the rules below; a duct part that names no duct (Part II, 6.9) is a terminal as this paragraph says. The washbasin of a type 600 mm wide, 450 deep and 200 high, at `[2000, 1000]` facing `[2000, 0]`, its offset 750 on level 0: its box runs from x 1700 to 2300, y 775 to 1225, and z 750 to 950. A component in a pipe or a duct (Part II, 6.9) is its declared geometry, where it or its type has one (Part II, 12.1), placed in the frame of a category placed at a point: its origin at its point, x along its way, z up. Otherwise its body is a box `w` across its way, its type's `terminal.depth` along it and `h` high, centred on its point in plan, from `z − h/2` to `z + h/2`, where `z` is its point's height. In a pipe, `w` and `h` are its type's `terminal.width` and `terminal.height`. In a duct they are its size across (Part II, 6.9): `w = max(terminal.width, W + 20)` and `h = max(terminal.height, H + 20)`, where `W` and `H` are its duct's outer width and height (12.1, rule 3). 1. A component's body is placed from its run and `along`, where Part II, 6.9 puts its point and its way, not from its stored `profile` and `offset`; a component in a duct is sized from its duct and its type, not from its stored `width` and `height` (Part II, 6.9, rule 8). 2. Its run's body runs through it: a component cuts nothing, and the run's length and volume (12.4) are the run's whole. Its volume is the box's. 3. A component whose `hostId` names no element of its run's category, a pipe for a type that mounts on a pipe and a duct for one that mounts on a duct, or whose run has no line or no outer size (12.1, rules 1 to 3), has no body. The valve of Part II, 6.9, 60 mm across, 80 mm along and 70 mm high, 2000 mm along its pipe on a piece that runs +x at 2400 mm: its box runs from x 2960 to 3040, y 970 to 1030 and z 2365 to 2435. The damper of Part II, 6.9, of a type 145 mm across, 200 mm along and 145 mm high, in a duct 400 mm wide and 200 mm high without insulation: `w = max(145, 420) = 420` and `h = max(145, 220) = 220`. 1500 mm along its duct, on a piece that runs +x at 2700 mm, its box runs from x 2400 to 2600, y 4790 to 5210 and z 2590 to 2810. These are closed-form rules, of class A (section 2). The reference implementation draws some terminals in a shape of their own (a WC, a basin, a round ceiling outlet), and keeps the box as the shape's proxy for sections, elevations and collision: the shape is reference behaviour (class C), and the box is the body this section derives (decided on 24 October 2026). Reference: `terminalSolids` in `src/core/elements/mep.ts`, which boxes a terminal of its type's size from its base, turned to its facing, a component centred on its point, and a component in a duct as large across as its stored `width` and `height`; `terminalAt` in `src/core/elements/terminalPlacement.ts`, which places a terminal's point, facing and base; and `placedOnRun` and `componentBody` in `src/core/elements/runComponents.ts` (Stomra 633 and 676). ### 12.7 What is derived (informative) These are derived from pipes, ducts and terminals, and never stored (section 1): - **A heating terminal's water flow**, in l/h, from its power `P` in W and its design difference `ΔT` in K: `q = 3.6 P / (c ΔT)`, with `c` the heat of a litre of water per kelvin, 4.18 kJ/(kg·K) × 0.988 kg/l. 500 W at 10 K is 44 l/h. - **The heat of a system**: its terminals counted, their power and their flow summed. - **The metres of insulation** by code, from the runs' lengths (12.4, rule 2). - **A tag's text**: a template filled in, a room tag's rows (Part II, 13.3 and 13.4), a component's tag (its `mark`, else its type's `code`, and its run's size). - **A schedule of components**, by mark, type, system and size. How each is worked out and shown is the application's. An application that keeps derived results keeps them in its own folder with a result manifest (Part VI, 8), never in a record. Reference: `terminalHeat`, `heatTagText` and `heatList` in `src/core/elements/mepHeat.ts`; `mepLists` and `terminalTag` in `src/core/elements/mep.ts`; `componentList` in `src/core/elements/runComponents.ts`.