Skip to main content
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 component datum 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/<page>.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): 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.

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.

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.”