> ## Documentation Index > Fetch the complete documentation index at: https://docs.loft.build/llms.txt > Use this file to discover all available pages before exploring further. # The category catalog Every category's parameter rows — what each word accepts, where it may be written, what fills it when unwritten — and its projected datum set: the required interface tools may assume, the refinements and kind-scoped selectors they may branch on, and the resolution rule behind each name. Companion to SPEC-v0.2 §6; vocabulary and semantics are normative there — these pages are the per-category inventory. Each element keyword has a page, grouped by class — what the compiler makes itself (`builtin`), a placed model family (`component`), and a declared frame you measure in or look through (`datum`). The paper side's two classes, `annotation` and `symbol`, are reserved and have no members yet; their rosters are under Future categories below. **builtin** | Page | Example | | ----------------------------------- | --------------------------------------------------------- | | [`wall`](/categories/wall/) | `wall EXT-1 W1 from (grid.A, grid.1) to (grid.B, grid.1)` | | [`opening`](/categories/opening/) | `opening O1 in wall.W1 at 4' width 3'-0" height 7'-0"` | | [`room`](/categories/room/) | `room 210 name "OFFICE" at (grid.A + 5', grid.1 + 5')` | | [`roomline`](/categories/roomline/) | `roomline from (grid.A, grid.1) to (grid.A, grid.3)` | **component** | Page | Example | | ------------------------------- | ------------------------------------------------ | | [`door`](/categories/door/) | `door DBL-9070 D1 in wall.W1 at 4' swing right` | | [`window`](/categories/window/) | `window WIN-3050 N1 in wall.W1 at 6' sill 3'-0"` | **datum** | Page | Example | | ----------------------------- | ------------------------------------------------------------------------- | | [`level`](/categories/level/) | `level L1 elev 0' height 10'-0"` | | [`grid`](/categories/grid/) | `grid A vertical at 0'` | | [`view`](/categories/view/) | `view plan L1-plan of level.L1 scale 1/4" cut 4'-0" name "L1 Floor Plan"` | **GENERATED PAGES — do not edit.** The source of truth is the typed catalog in `/packages/lang/src/schema/categories/` (the thing the compiler enforces — SPEC-v0.2 §11 session 1 landed the projection engine, so the errors.ts / cheat-sheet lifecycle has flipped phases). Rows are edited in the catalog, prose in `intros/.md`; run `pnpm gen:intros` and `pnpm gen:categories`, and CI pins every page to the generator's output. **Legend — parameters.** * **Rung:** `type` (written on the type statement) · `instance` (on the placement) · `bound` (the type fixes it, or delegates it to each placement) · `either` (type or instance, the instance winning per fact). * **Required:** `required` (in every path a datum resolves from — write it, or take the default beside it) · `one of` (pick one of the group; a defaulted member is what the group falls to) · `bound` · `optional` (participates in no datum) · `derived` (a query result, never written). A default is a literal or a computed rule, and carries its **basis** the way a default plane does. **Legend — datums.** * **Shape:** `plane` (codim-1: one position along one normal) · `line` (codim-2: two directions pinned, one free — a line carries a direction the way a plane carries a normal; **not plumb by definition**, though every line shipped so far is, and slots demand orientation, not a plumb keyword). True points (codim-3) are parked for demonstrated demand. * **Status:** `core` (required — every conformant member projects it, tools may assume it blind) · `refinement` (required by a subcategory) · `reserved` (spec-owned name, not yet projected). A status followed by `·` and kind names (`core · swinging`) is a datum that exists for those kinds of its category only. * **Resolution:** `intrinsic` (no selection — one datum, always) · `operational` (selects by the *referenced element's* declaration; follows it when edited) · `geometric` (selects by the *referencing statement's* context; invariant under the referent's edits). The resolution family is the dependency edge — SPEC-v0.2 §6.3. *** ## Declared datum categories (the element-free case) Grids, levels, and (reserved) refplanes don't *project* datums — they **are** datums, declared directly (in carrier terms: a carrier with no recipe). Grids: plane, normal x̂ (vertical) or ŷ (horizontal). Levels: plane, normal ẑ. `refplane` stays reserved for arbitrary normals. ## Carrier interfaces (cross-category) Most geometric categories ride a **carrier** — the reference geometry the element is built along. The carrier is an *interface*, not a wall feature: every category with the same carrier class projects the same carrier datum names with the same resolution semantics, and a reference slot can't tell (and shouldn't care) which category filled it. Wall is just the first implementer. **Carrier classes** (wall's own roadmap, and the membership list): | Class | Carrier geometry | Wall era | Other members (system + future user-defined) | | ----------- | ------------------------------------------------------------------------------------------------------------------------------ | ------------------------ | ------------------------------------------------------------------ | | **segment** | straight line between two stations | today (v0 → v0.2) | beams, railings, pipe runs, columns (plumb segment between levels) | | **curve** | a path — SVG-path-like semantics expected | future wall sub-category | curved beams/railings, pipe routing | | **surface** | a 2D carrier; the solids era (Manifold per PARKINGLOT "Geometry stack" — B-rep needs its own license carve-out decision first) | further out | floors, roofs, façade panels | **The segment/curve carrier core** — what wall's `start`/`end`/`mid` really are: `start` and `end` (operational — declaration order), `mid` (pending §10), plus the carrier trace the category's qualifiers hang off. The interface guarantees **names and resolution semantics; kinds refine per category** — wall's vertical extrusion makes its `start` a plumb line, while a beam's `end` used as an extent presents its transverse plane. Same name, same dependency behavior, category-appropriate kind — exactly the kind-algebra move (SPEC-v0.2 §6.2: slots demand orientation, not spellings). **Curve era continuity:** `start`/`end` stay well-defined on a path; `mid` becomes the arc-length midpoint; direction at a station is the tangent — the "a line carries a direction" kind already accommodates direction that varies along the carrier. `from … to …` is the *segment spelling* of the carrier clause, not the general form; curve syntax arrives as a new spelling of the same slot. **No decision may weld carrier datum names to straightness or to wall-ness.** New categories — system or user-defined — declare their carrier class and inherit the interface core (the scaffolding move from the governance ladder), then add their own datums per the projection rule. **Trace qualifiers on wall line datums:** `wall.W1.end` (declared line) · `wall.W1.end.centerline` (same station, centerline trace) · face traces (`wall.W1.end.foc`) wait on the side-naming story — a teaching error today (D0327). `wall.W1.end.left` is a teaching error — the first-person invariant reserves `left`/`right` for the declaring statement's own frame. ## Default planes — what a bare reference means (SPEC-v0.4 P0.7, decision 65) Per category × situation, language-wide and spec-fixed — never per-project (PARKINGLOT "Measurement references"). The escape hatch is always naming the plane. **Basis** is how each default is governed: `cited` (a published standard, clause named) · `practice` (a loft ruling on field practice — the deciding decision named) · `revit-parity` (Revit's own default, adopted per CLAUDE.md principle 5). A situation not listed has no default: the reference must name its plane. | Category | Situation | Default plane | Basis | | ---------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `wall` | bare wall reference in a directed measurement — `at 4' past wall.W6` | the core face facing the measurement (`wall.W6.foc`, `wall.W6.fos`, or `wall.W6.fom` — one plane) — the far face for `past`, the near face for `short of`
The type-stable plane: a finish change moves `fof` and `centerline`, never the core face. A wall with no layer stack is all core, so its faces are the core faces. Name the plane to measure elsewhere: `past wall.W6.centerline` (the body's center — physical, so a `justify left` wall's center is off its location line), `past wall.W6.core.centerline`, `past wall.W6.fof`. | **cited** — NCS V7 UDS Module 4 §4.2.8.3.1, pp. 8–9 (`notes/standards-extraction-ncs.md`): method 1, face of stud / concrete / masonry unit — listed first of the three methods "in common use", the only one given string rules; NCS declares no default, so the ruling is loft's (decision 65, shipped 67) | | `wall` | no `justify` clause — where the from/to line holds the wall | the assembly centerline (`justify centerline`)
The recommended hold once finishes vary is a core face (`justify left foc`) — the type-stable plane; NCS lists face-of-stud/concrete/masonry first (method 1). | **revit-parity** — Revit's Location Line default is Wall Centerline | | `wall` | bare `justify left` / `justify right` — a side with no plane word | the finish face on that side (`fof`)
NCS fences face-of-finish (method 3) to "only when required by the project" — hold the core when the assembly matters: `justify left foc`. | **practice** — the drawn face — decision 25 (v0.1); kept by the superset rule at decision 66 | | `wall` | wall carrier reference — `at 4' left of wall.W3` (§6.5) | W3's core face on the declared side (`wall.W3.foc`, `wall.W3.fos`, or `wall.W3.fom` — one plane) — the offset is clear of W3's core
The declared side picks the member of the pair, so the face words carry too: `at 3' right of wall.W3.fof` is 3' clear of the finish, `right of wall.W3.centerline` / `.core.centerline` the centers. Zero offset is D0609 (the wall would sit ON the core face); the body must stay clear of the plane it measures from. | **cited** — NCS V7 UDS Module 4 §4.2.8.3.1, pp. 8–9 (`notes/standards-extraction-ncs.md`): method 1, face of stud / concrete / masonry unit — the same ruling as the bare measurement ref (decision 65, shipped 67: "core face everywhere"); the offset states the clear side, never a straddle (D0609) | | `wall` | wall extent reference — `from wall.W1 to wall.W3 at …` (§6.5) | the crossing wall's centerline plane (`wall.W1.centerline`; `.core.centerline` by name)
Revit-parity too: walls drawn to another wall's location line join and clean up there. A face word on an extent teaches D0327 (nothing states which face); `wall.W1.end` cuts at the line datum. | **practice** — an extent is a JOIN, not a tape — the wall runs to the crossing wall's centerline exactly where a point-pair wall's `(grid.A, grid.1)` meets it (decision 67 keeps extents on the centerline on purpose) | | `opening` | plain element reference in a directed measurement — `at 4' past door.D1` | the jamb facing the measurement (clear of the opening)
NCS shows openings following the wall method — jamb-stud (RO) faces under method 1, CL under method 2 (M4 Figs. 4.2.8.3.1-3/-4). The door/window worksheet re-derives this default with the rough-opening ruling in hand (decision 65). | **practice** — decision 46 (v0.3): element-to-element measurements state clear distances; three AI rounds and the live-typing ledger | | `opening` | the placement station itself — `door D1 in wall.W1 at 12'` | the opening's centerline | **revit-parity** — Revit places doors and windows by their center; its temporary-dimension default for doors and windows is Centerlines | | `opening` | landing when measured from a wall or grid — `at 4' past wall.W6` / `past grid.A` | the opening's centerline (`to jamb` / `to jamb.far` override per end)
The origin plane — the bare wall ref's core face (decision 67) or a named plane (`past wall.W6.foc`, `past wall.W6.centerline`) — changes nothing here; the door/window worksheet decides whether face-of-stud origins land at the RO (decision 65). | **cited** — NCS V7 UDS Module 4 §4.2.8.3.1, pp. 8–9 (`notes/standards-extraction-ncs.md`): method 2, centerline: openings "shown to the centerline of that object" | | `opening` | landing when measured from another opening — `at 4' past door.D1` | this opening's near jamb (the stated value is the clear gap; `at 0'` is flush) | **practice** — decision 46: the tape's two ends match on element-to-element measurements; `to centerline` / `to cl` overrides | | `grid` | any grid reference — `(grid.A, grid.2 - 4')`, `past grid.A`, `along grid.A` | the gridline itself (a declared datum — no selection) | **cited** — DoD A/E/C Graphics Standard R2.2 §3.3.1, p. 30 (`notes/standards-extraction-free-pair.md`): "Grid lines are used as a basis for dimensioning." | | `room` | a room's point in an expression | the labeled point (a room's boundary is derived, never a referenceable plane) | **practice** — decision 39: rooms anchor to declared datums; the boundary is a query over the walls (decision 68), so it can never be a datum a wall depends on | | `roomline` | the shared line placement — carrier, extents, `along` (`roomline from wall.W1 to wall.W3 at 12' right of grid.A`) | exactly the wall's rows: a bare wall carrier is its core face on the declared side, a grid is the gridline, extents join at a crossing wall's centerline, `along` rides a declared datum | **practice** — decision 69: carrier + extents is ONE line-positioning grammar with one resolver — walls its first consumer, roomlines the second; a zero-width line has no body, so the straddle rule (D0609) is vacuous and the tape lands on the line itself | | `room` | the derived boundary and area — `roomRegions`, the takeoff's rooms table | the enclosing walls' finish faces (`fof` — today's footprint) and any `roomline` (zero width — the line itself), openings ignored
Corner notches count: walls are rectangles to their centerline endpoints (v0 geometry, no join cleanup), so an island's outer corners add their w/2 × w/2 notch to the room — the room sees exactly what the plan draws. | **revit-parity** — Revit's Room Area Computation default is At wall finish, and doors/windows do not break a room-bounding wall; BOMA 2017 measures office area to the inside finish face as well — the cited area-scheme extraction waits for the views/takeoff era (PARKINGLOT "Rooms, areas, zones") | ## Default values — what an unstated parameter means (decision 82(d)) A default is a resolution path with no inputs, so it silently un-requires whatever it shadows. Every default is therefore a named catalog row with its basis beside it, never a parser constant: the resolver and the printer both read the row. A parameter not listed has no default — leaving it off is an error naming the fix. Each page's parameter table lists every default beside its word; this table is the index's summary. | Category | Parameter | Default | Basis | | --------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `opening` | `sill` | the host level + 0'
`sill 3'` reads as `sill + 3'`; a value below the level is legal (the anchor spelling that writes one is parked — PARKINGLOT "ẑ anchors everywhere"). | **practice** — a hole with no sill is a passage, the commonest opening of all — decision 84; the window refines `sill` to required with no default (decision 82, D0272) because a 0' window sill is never intended | ## Types (walltype, doortype, windowtype) Types don't project datums — projection is instance-level (a datum is somewhere; a type is nowhere). A type *parameterizes* its instances' projections (width positions the faces and jambs; the kind picks the selector lens) through the binding system (SPEC-v0.3 §6.1–6.3: the category requires, the type fixes or delegates, the instance is checked). Registry-era: a vendor family's declared datum set lives in its readable wrapper and is checked against this catalog at publish/import/placement. ## Future categories (reserved) Each class has members with no rows yet. Each arrives with its catalog section and its required core defined *before* first ship, per the projection rule. * **builtin:** `floor`/`roof` (the `F2.top`/`F2.bottom` partition-head payoff — surface carriers), stairs. Linear members (beams, columns, railings, pipes) arrive already owing the segment/curve carrier interface above — their catalog sections start from the inherited core, not from scratch. * **component:** columns, furniture, equipment; MEP. * **datum:** `refplane`, scope box; the project frame (origin / base point, survey point, true north, elevation datum — the `geo` file role); and **phase** — a datum in time: an ordered list declared in its own file, elements created in one and demolished in another, a view looking at the model *as of* one (existing / demo / new / temporary are computed by the view and printed by the graphics standard, never authored). * **annotation:** text, dimensions, spot elevations / coordinates / slopes, detail lines, filled and masking regions, revision clouds. * **symbol** (Revit's own word — Annotate ▸ Symbol): tags, generic annotations, detail components, keynote tags, section / elevation / callout heads. The word also names a component definition's 2D block and a line class in the graphics standard — different tables, no collision. Title blocks belong to no class here: the artifact of drafting is the *sheet*, out of v0 entirely; the title block is the sheet's furniture and arrives with a `sheet` class in that era. *** *Governance: the spec owns this vocabulary (closed; additions come with format versions). Project profiles may add and tighten, never remove or weaken (additive-only, Liskov-governed). Designers may declare ad-hoc datums that shadow nothing here. Full ladder: PARKINGLOT.md, "Authoring & governance layers."*