1 Purpose and Scope

Operational definitions of the key technical terms developed across the thesis are consolidated here as a governed terminology reference. Coverage spans three systems that each contribute a distinct vocabulary to the artefact suite: the PlaniSyn notation (the applied grammar layer of the notation), the RecPol predicate vocabulary (the formal core underlying PlaniSyn), and the SDA clause classification framework (the standardisation schema). Each entry records the operational definition of the term as deployed in the thesis, with a back-reference to the section in which the term is introduced and elaborated. The dictionary discharges the thesis’s terminology-traceability commitment: every term that carries technical load in a downstream chapter is recorded here under the same governed definition that the chapter’s argument depends on.

The three subsections are organised by the artefact whose vocabulary they document. Section 2 records the PlaniSyn applied-layer vocabulary (object model, tag grammar, spatial primitives, interaction types, and nesting mechanism). Section 3 records the RecPol formal-core vocabulary (axiom set, entity types, verb registry, invariant register, and boundary-pair register). Section 4 records the SDA clause classification framework (five-layer schema, stratified entity vocabulary, relation-operator layer, and clause-class labels). Within each subsection, entries follow a uniform definition-list format: term — operational definition — source section reference. Where a term carries a code in the originating specification (e.g., V-01, INV-P-03, IFACE-02), the code is preserved exactly.

The dictionary does not duplicate the derivational evidence on which each definition rests. Where the definition is grounded in corpus measurements, ablation results, or formal verification verdicts, the relevant evidence is in the source chapter or the corresponding substantive appendix (the PlaniSyn Grammar appendix, the RecPol Specification appendix, Supplementary Foundational Mapping Coverage).

2 PlaniSyn Notation Vocabulary

This subsection records the applied-layer vocabulary developed in Chapter 7 §7.13 and specified in technical detail in the PlaniSyn Grammar appendix. PlaniSyn is a text-based planimetric notation through which building spatial arrangements are encoded as governed, inspectable, transportable text representations. The vocabulary is organised into three groups: the seven tag types of the tag grammar; the object model and module-type identifiers; and the four interaction types together with the three-level nesting mechanism.

2.1 Tag Grammar

The seven tag types collectively constitute the syntactic apparatus through which the three architectural layers (declaration, interaction, composition) are instantiated in text. Each tag is bound to a specific RecPol extension-point token, ensuring that the applied grammar layers cleanly onto the formal core under the DA-08 extension contract.

Declaration tag < > — Encloses the full specification of a PlaniSyn object: identity, perimeter, border, access state, openings, and anchors, partitioned by class separators into defined parameter positions. The primary syntactic construct of the declaration layer. Source: the PlaniSyn Grammar appendix §4.1; Chapter 7 §7.15.

Action / iteration tag { } — Encloses inter-object interactions or iterative processes applied to sequences of objects; used both for interaction declarations and for nested child declarations in composition. The primary syntactic construct of the interaction and composition layers. Consumes the RecPol extension-point tokens OPEN_BRACKET and CLOSE_BRACKET. Source: the PlaniSyn Grammar appendix §4.2; Chapter 7 §7.15.

Prerequisite value tag [ ] — Encloses cardinality constraints, target-object identifications, or conditional validity conditions that must be satisfied before a parameter or interaction is treated as well-formed. The syntactic locus for encoding the governed kernel’s mandatory inclusion, conditional, exclusion, and cardinality constraints. Source: the PlaniSyn Grammar appendix §4.3; Chapter 7 §7.19.

Transformation tag ( ) — Encloses geometric transformation parameters (rotation about a pivot point in multiples of 90°; uniform scaling by an integer factor) applied to an object without altering its declared identity or interaction contracts. Consumes the RecPol extension-point tokens OPEN_PAREN and CLOSE_PAREN. Source: the PlaniSyn Grammar appendix §4.4; Chapter 7 §7.15.

Class separation tag | — Partitions the internal components of a declaration expression into their defined parameter positions (identity, perimeter, border, access state, openings, anchors). Overloads the RecPol PIPE token with applied-grammar semantics. Source: the PlaniSyn Grammar appendix §4.5; Chapter 7 §7.15.

Capital parameter tag — Uppercase named-parameter identifiers within declarations. The six load-bearing capital parameter identifiers are: P (perimeter), B (border), D (door / dimensions), A (access state), O (openings), An (anchors). Each names a parameter slot whose meaning is fixed by the grammar specification and does not vary by instance. Source: the PlaniSyn Grammar appendix §4.6; Chapter 7 §7.15.

Lowercase variable tag — Lowercase identifiers designating instance-specific values associated with named parameters (e.g., n10 for ten-module northward perimeter movement, e8 for eight-module eastward movement). Provides a visual parsing aid in addition to its syntactic role, distinguishing parameter labels from their values without additional annotation. Source: the PlaniSyn Grammar appendix §4.7; Chapter 7 §7.15.

2.2 Object Model and Module Types

Object — The fundamental entity of the PlaniSyn system. Any spatial or physical entity in a planimetric description — physical infrastructure (walls, doors, windows, grab rails), enclosed spatial zones (rooms, corridors, outdoor areas), or dwelling aggregates. Objects carry no inherent type in the base grammar; they are what their declarations specify them to be. Source: the PlaniSyn Grammar appendix §5.

Stable referential identity — The property that each object identifier names the same spatial entity consistently across all references to it within a representation, enabling deterministic comparison across representation versions, cross-module reference without duplication, and version-tracked modification histories. The PlaniSyn instantiation of the source-node requirement of the trigram structure in Chapter 3 §3.3. Source: the PlaniSyn Grammar appendix §5; Chapter 7 §7.15.

Module-type identifiers — Nine three-letter codes drawn from the governed type vocabulary established in Chapter 6 §6.2 and inherited as the object-model vocabulary in PlaniSyn: ENT (Entry), CIR (Circulation), SAN (Sanitary), BED (Bedroom), LIV (Living), KIT (Kitchen), SVC (Service), EXT (External), DWL (Dwelling aggregate). Each module-type identifier inherits the constituent-element specifications and interaction-rule contracts defined for the corresponding type. Source: Chapter 7 §7.15; the Space Category Taxonomy appendix.

2.3 Spatial Primitives

Perimeter — The outer spatial boundary of an object, encoded as a closed loop of directional movements (N, S, E, W) and integer module distances from a declared anchor origin. Well-formedness requires that the final movement return the trace to its starting grid position. Corresponds to the RecPol MakeShape verb at the Primitive plane. Source: the PlaniSyn Grammar appendix §6.1; Chapter 7 §7.16.

Border — An integer offset (in modules) from the declared perimeter, representing the structural boundary layer of the object (wall thickness, clearance margin). A border of 0 specifies that the interior extends to the full perimeter extent. Source: the PlaniSyn Grammar appendix §6.2; Chapter 7 §7.16.

Anchor — A positional constraint locating an object within the spatial hierarchy. Three anchor types are admissible: point anchor (absolute integer grid coordinates (x, y)), edge anchor (alignment to a named edge of another object or grid boundary), and surface anchor (positioning within a named interior region of a containing object — e.g., SE_CORNER, NW_CORNER, CENTRE). Source: the PlaniSyn Grammar appendix §6.3.

Opening — A perforation in an object’s boundary enabling spatial connectivity between adjacent objects. Doors (D), windows (W), and passages (P) are the admissible opening identifiers. Each opening declaration specifies identity, placement (distance along a named perimeter segment, e.g., D1@W3), sizing, and direction. Source: the PlaniSyn Grammar appendix §7.1; Chapter 7 §7.16.

Segment — A named section of an object’s perimeter, enabling differentiated treatment of distinct boundary portions (boundary-type specification, opening-constraint declaration, interface identification). The mechanism through which the bilateral interface adjacency constraint of Chapter 6 §6.3 is operationalised in notation. Source: the PlaniSyn Grammar appendix §7.2.

2.4 Interaction Types and Nesting

The four typed interaction declarations specified at Handoff Contract HC-6D (per Chapter 7 §7.17, NR-014) collectively realise the three governed-kernel interface types (semantic, transformation, verification). Each is a Chapter 7 PlaniSyn-level construct whose interface-contract activation is documented in the four-to-three mapping table of §7.17.

Engaging — A symmetrical adjacency interaction. Two objects engage when their respective perimeters share a common boundary segment without traversal or penetration. Bilateral declaration required: if A engages B, B must declare engagement with A. Activates the semantic interface (IFACE-01) only. Declaration form: <OBJ_A>{ENGAGE}[<OBJ_B>]. Source: the PlaniSyn Grammar appendix §9.1; Chapter 7 §7.17.

Coupling — A symmetrical connection interaction via aligned openings. Two objects couple when each carries an opening declaration at a compatible position and orientation, and those openings are declared as the connection point between the objects. Bilateral opening declaration required. Activates both the semantic interface (shared opening entity) and the transformation interface (dimensional propagation). Declaration form: <OBJ_A>{COUPLE}[<OBJ_B>]. Source: the PlaniSyn Grammar appendix §9.2; Chapter 7 §7.17.

Entangling — An asymmetrical perimeter-to-interior interaction. Object A entangles object B when A’s boundary connects to the interior of B without fully enclosing B (e.g., a structural column piercing a room’s perimeter; a services riser entering a circulation module). Not reversible: B does not entangle A. Activates the transformation interface with directional containment propagation. Declaration form: <COLUMN_01>{ENTANGLE}[<ROOM_A>]. Source: the PlaniSyn Grammar appendix §9.3; Chapter 7 §7.17.

Encasing — An asymmetrical full-enclosure interaction. Object A encases object B when A’s perimeter completely surrounds B’s perimeter and B is fully contained within A’s interior extent. Activates the verification interface cascade rule: failure of the contained module’s verification triggers re-verification of the containing module under the CASCADE_NEXT default. Declaration form: <BUILDING_01>{ENCASE}[<ROOM_A>]. Source: the PlaniSyn Grammar appendix §9.4; Chapter 7 §7.17.

Nesty (hierarchical nesting) — The PlaniSyn mechanism for hierarchical spatial composition: objects are nested within other objects, with the child object declared within the action tag of the parent. The result is a recursive parent-child tree corresponding to the three-level planimetric hierarchy. Declaration form: <PARENT|...>{<CHILD|...>}. Source: the PlaniSyn Grammar appendix §9; Chapter 7 §7.18.

Three-level nesting hierarchy — The structural correspondence between the three nesting levels and the three planimetric planes. Level 1 (Primitive plane) carries individual fixtures, openings, path segments, and boundary elements with invariant geometry. Level 2 (Configurative plane) carries rooms and spaces — the eight space-specific module types (ENT, CIR, SAN, BED, LIV, KIT, SVC, EXT) — with relational geometry. Level 3 (Interactive plane) carries the dwelling aggregate (DWL) with contextual properties: site-specific placement, design-category assignment, and aggregate constraint evaluation. Source: the PlaniSyn Grammar appendix §9; Chapter 7 §7.18.

3 RecPol Predicate Vocabulary

This subsection records the formal-core vocabulary developed in Chapter 7 §7.3 and specified in technical detail in the RecPol Specification appendix. RecPol (Rectangular Polyomino Language) is the serialised, human-readable, modular language layer upon which the PlaniSyn applied grammar is built. The vocabulary is organised into four groups: the eight design axioms; the entity type system and plane projection operator; the verb registry (the V-01..V-20 closed verb set together with the operational verb families introduced in §7.9); and the invariant register that any conformant RecPol document must satisfy.

3.1 Design Axioms

The eight axioms specified at §7.4 and frozen in EXP-2.2 establish the structural invariants from which RecPol’s representational governance properties are formally derivable rather than incidental.

DA-01: Discrete-Spatial — The spatial substrate is an orthogonal integer coordinate system; cells are atomic spatial units; rectangular polyominoes are the spatial inhabitants. No real-valued coordinates appear at the formal core. Source: §7.4; the RecPol Specification appendix §2.1.

DA-02: Serialised — Language elements are linear token streams in subject–verb–object patterns; the canonical orthography defines a deterministic text representation for every configuration. Source: §7.4; the RecPol Specification appendix §2.1.

DA-03: Uniform Outer Syntax — Every entity is declared using the single outer form < identifier | predicate_list >; internal content varies by entity type and plane, but the enclosing delimiters and structural pattern are constant. Source: §7.4; the RecPol Specification appendix §2.1.

DA-04: Context-Free — RecPol is a Chomsky Type 2 grammar; each entity block is parseable without reference to any other entity block, and no production rule requires non-local context. Source: §7.4; the RecPol Specification appendix §2.1.

DA-05: Modular — The language provides explicit, first-class boundary and interface declarations; three interface-type forms (semantic, transformation, verification) are syntactically distinguished; bilateral constraint evaluation across module boundaries is expressible. Source: §7.4; the RecPol Specification appendix §2.1.

DA-06: Stratified — The language defines exactly three planes — Primitive, Configurative, Interactive — each inhabited by a distinct entity type assigned via the plane projection operator (^). The verification sequence (Primitive → Configurative → Interactive) is a structural property of the grammar. Source: §7.4; the RecPol Specification appendix §2.1.

DA-07: Bounded — No left-recursive production cycles; entity reference graphs are acyclic; parsing and verification terminate in finite steps for any well-formed document. Source: §7.4; the RecPol Specification appendix §2.1.

DA-08: Extensible — Applied grammar layers may introduce domain-specific tokens only through six reserved extension-point tokens (OPEN_PAREN, CLOSE_PAREN, OPEN_BRACKET, CLOSE_BRACKET, DOT, AT) via the wrapping functor W: G→A. Novel to RecPol v6.0; formalises the two-layer extension contract. Source: §7.4; the RecPol Specification appendix §2.1.

3.2 Entity Type System and Plane Projection

Plane projection operator ^ — Identifiers in RecPol are structured as namespace^name_stem. The caret signifies the projection of an abstract name stem onto a specific existential plane, constituting the entity’s plane-typed identity. A alone is a name; s^A, f^A, and i^A are distinct entities even if they share the same name stem. Source: §7.6; the RecPol Specification appendix §4.1.

Shape (s^) — A Primitive-plane entity of invariant geometry: a rigid body that defines a reusable geometric archetype. Created via MakeShape or MakeComposite. Cannot receive geometric transformations within its own definition. Source: the RecPol Specification appendix §4.2.

Form (f^) — A Configurative-plane entity of relational geometry: spatial organisation defined by relationships between member components rather than absolute cell positions. Created via CallShape, MakeCompound, or Pass. Carries constraint specifications (ConsLatchment, ConsOccupancy) precomputed at the Configurative plane but evaluated only at the Interactive plane. Source: the RecPol Specification appendix §4.2.

Instance (i^) — An Interactive-plane entity of concrete placement: occupies specific cells in the World Grid and interacts with other Instances according to the constraint policies of its underlying Form. Created via CallForm, CallInstance, or Instantiate. Source: the RecPol Specification appendix §4.2.

3.3 Verb Registry

The governed-kernel verb registry V-01..V-20 is specified in EXP-5B.1 and inherited by the chapter body. Where the chapter-level operational summary uses a composite verb name (e.g., MakeComposite, ConsLatchment, ConsOccupancy), the registry entry records the canonical formal-core verb and the EXP-derivation note linking the operational summary to the formal specification. The twenty entries below are organised by plane.

V-01 MakeShape — Primitive plane. Declares the base rectangular polyomino geometry for a Shape; the foundational primitive-plane verb. Must be the first (and typically the only) operation in a Shape definition. Source: the RecPol Specification appendix §7.1; EXP-5B.1; EXP-6.1 SEM-P-01.

V-02 DeclBoundary — Primitive plane. Declares boundary edges of a Shape, exposing the boundary edge set B(s^X) for downstream selection by CallShape and wildcard-edge selectors. Source: §7.9 (verb registry note); EXP-5B.1.

V-03 DeclConnect — Primitive plane. Declares a connectivity relation between Shapes; preserved under composition by INV-P-05. Source: §7.9 (verb registry note); EXP-5B.1.

V-04 EdgeRun — Primitive plane. Selects a sequence of perimeter edges on a Shape for use as a joining specification in MakeComposite. Position-independent via canonical clockwise perimeter walk. Source: the RecPol Specification appendix §7.3; EXP-5B.1.

V-05 MakeComposite — Primitive plane (composite operation). Fuses two Shapes into a single contiguous Shape by joining them along specified edge segments; semantics derived from SEM-P-01 cell-set construction plus SEM-C-01 alignment transform τ. Source: the RecPol Specification appendix §7.2; EXP-5B.1.

V-06 CallShape — Configurative plane. Imports a Shape’s geometry as a member of a Form. The Shape reference must resolve to a valid s^ entity. Source: the RecPol Specification appendix §9.1; EXP-5B.1; EXP-6.2 SEM-C-01.

V-07 MakeCompound — Configurative plane. Groups multiple members into a single Form without geometric fusion. Members retain individual geometry and constraint policies; primary mechanism for assigning distinct constraint policies to different geometric parts of a single Form. Source: the RecPol Specification appendix §9.2; EXP-5B.1.

V-08 TransPosition — Configurative plane. Local translation: moves a member’s origin to x,y within the Form’s local frame. Source: the RecPol Specification appendix §9.3; EXP-5B.1.

V-09 TransPivot — Configurative plane. Local rotation: rotates a member by n × 90° clockwise around its local origin. Source: the RecPol Specification appendix §9.3; EXP-5B.1.

V-10 TransReflect — Configurative plane. Local reflection: mirrors a member across the X or Y axis. Source: the RecPol Specification appendix §9.3; EXP-5B.1.

V-11 TransScale — Configurative plane. Local scaling: scales a member by a declared quantity along the specified axis. Source: the RecPol Specification appendix §9.3; EXP-5B.1.

V-12 ConsLatchment — Configurative plane (constraint class). Declares latching rules for a specified edge segment within a given interaction lane. Policy values: 1 (Required), 0 (Allowed), −1 (Forbidden). Derived from SEM-C-06 ConsInclusion and SEM-C-07 ConsExclusion. Source: the RecPol Specification appendix §9.4; EXP-5B.1.

V-13 ConsOccupancy — Configurative plane (constraint class). Declares overlap tolerance for the Form within a given interaction lane. Policy values: 1 (Empty — tolerates content), 0 (Partial — tolerates other partial), −1 (Full — tolerates only empty). Lane-additive arithmetic; conjunctive cross-lane evaluation. Source: the RecPol Specification appendix §9.4; EXP-5B.1.

V-14 CallForm — Interactive plane. Instantiates a Form on the World Grid; the reference must resolve to a valid f^ Form. The Instance inherits the constraint policies of its underlying Form. Source: the RecPol Specification appendix §10.1; EXP-5B.1.

V-15 CallInstance — Interactive plane. Re-instantiates an existing Instance (for duplication or variant creation). Source: the RecPol Specification appendix §10.1; EXP-5B.1.

V-16 Place — Interactive plane (global transformation). Anchors the Instance’s local 1,1 origin at x,y in the World Grid. Source: the RecPol Specification appendix §10.2; EXP-5B.1.

V-17 Rotate — Interactive plane (global transformation). Rotates the Instance by n × 90° clockwise in the World Grid; identity-preserving. Source: the RecPol Specification appendix §10.2; EXP-5B.1.

V-18 Mirror — Interactive plane (global transformation). Mirrors the Instance across the World Axis through its anchor point; identity-preserving. Source: the RecPol Specification appendix §10.2; EXP-5B.1.

V-19 Stretch — Interactive plane (global transformation). Stretches the Instance along the specified World Axis by the declared quantity. Source: the RecPol Specification appendix §10.2; EXP-5B.1.

V-20 StretchFit — Interactive plane (generative constraint). Adapts an Instance’s geometry to match a target entity’s resolved dimensions. Supports four edge-specification types (cell-based EdgeRun, index-based EdgeRun, point-to-point, wildcard). Operates within the bounds declared by RangeStretch where present. Source: the RecPol Specification appendix §11.1; EXP-5B.1.

Range constraints (RangePlace, RangeFit, RangeRotate, RangeMirror, RangeStretch) — Generative-constraint verbs that restrict the permissible parameter space for their corresponding transformation verbs. Declarative specifications consulted by external generation and validation systems; attached to Instances but not evaluated during entity construction. Source: the RecPol Specification appendix §11.2; §7.11.

3.4 Invariant Register

The six numbered invariants below are cross-cutting compliance conditions that every well-formed RecPol document must satisfy. Each invariant is traced to the design axiom that guarantees it. Additional plane-specific invariants (INV-C-01..03 for the Configurative plane; INV-I-01..03 for the Interactive plane) are recorded in EXP-6.2 and EXP-6.3 and referenced from the RecPol Specification appendix.

INV-P-01: Boundary completeness — For every Shape entity s^X with cell set C(s^X), the boundary edge set B(s^X) is enumerable, finite, and closed: every perimeter cell contributes at least one boundary edge, and B(s^X) covers the polyomino’s full perimeter without gap or duplicate. Plus Shape immutability post-MakeShape (geometry frozen). Axiom trace: DA-01. Source: §7.9; EXP-6.1.

INV-P-02: No phantom regions — No entity may declare cells, boundaries, or relations that lie outside a declared, named, plane-typed entity block. Every cell, edge, and relation is within C(s^X) for some declared Shape, part of B(s^X) for some declared Shape, or part of an explicit relation in R linking two declared entities. Axiom trace: DA-02. Source: §7.9.

INV-P-03: Canonical-form invariance — Two RecPol documents that are geometrically and relationally equivalent (same cell sets, same boundary edge sets, same relations under entity renaming) produce byte-identical canonical token sequences. Conversely, two canonical representations differing in any token represent geometrically distinct configurations. The formal basis for round-trip fidelity and diff-ability. Axiom trace: DA-04 and DA-07. Source: §7.9; EXP-5C.2.

INV-P-04: Level (plane) consistency — Every entity is assigned to exactly one plane via the plane projection operator (^); the assignment is determinable from the identifier alone. Shape entities (s^…) reside on the Primitive plane; Form entities (f^…) on the Configurative plane; Instance entities (i^…) on the Interactive plane. No entity carries a mixed or null plane assignment. Axiom trace: DA-03 (jointly with DA-06). Source: §7.9.

INV-P-05: Connectivity preservation — When two Shapes are composed via MakeComposite into a derived Shape s^Z, every connectivity relation declared on either source Shape (where the connected entity is also imported into the Form context) is preserved in the composite. Composition does not silently drop declared connectivity. Axiom trace: DA-05; NR-028. Source: §7.9.

INV-P-06: Identity preservation under transformation — For any Form entity that imports a Shape s^X via CallShape and applies any sequence of admissible local transformations, the underlying Shape declaration — its cell set, bounding box, and boundary edge set — remains unchanged. Transformations are stored as predicates within the Form’s content block and never mutate the source Shape’s symbol-table entry. Axiom trace: DA-06; AM-08. Source: §7.9.

3.5 Interface Type Register and Boundary-Pair Vocabulary

IFACE-01 Semantic interface — Governs the meaning of entities that appear at module boundaries. Enforces the entity-ownership rule, the vocabulary-closure rule, and the visibility-qualifier rule (EXPORTED, READ_ONLY, RESTRICTED). Carried by the engaging and coupling interaction types in PlaniSyn. Source: Chapter 6 §6.3; §7.17; EXP-6.3.

IFACE-02 Transformation interface — Specifies the admissibility declaration rule, the containment / propagation rule, and the invariant-retention check that govern how changes within a module’s declared degrees of freedom either remain contained or propagate to adjacent modules. Carried by the entangling and encasing interaction types in PlaniSyn. Source: Chapter 6 §6.3; §7.17; EXP-6.3.

IFACE-03 Verification interface — Specifies the re-checking scope triggered when a module’s properties are assessed against a requirement. Encodes the localisation principle, the cascade rule (CASCADE_NEXT, CASCADE_ALL, CASCADE_STOP, CASCADE_BOUNDED), and the depth-bound guarantee. Activated bilaterally by all four PlaniSyn interaction types through their lane membership. Source: Chapter 6 §6.3; §7.17; EXP-6.3.

Active boundary-pair register — The twelve boundary pairs at which the module system declares active cross-module interactions: ENT–CIR, ENT–EXT, CIR–SAN, CIR–BED, CIR–LIV, CIR–KIT, CIR–SVC, LIV–KIT, LIV–EXT, BED–SAN, EXT–DWL, DWL–All. Each pair carries declared shared entity types, an owner module under the entity-ownership rule, and an empirically measured interaction differential (range 13.2 LIV–KIT to 34.1 LIV–EXT). Source: Chapter 6 §6.3.

4 SDA Clause Classification Framework

This subsection records the standardisation schema developed in Chapter 5 §5.5. The schema defines its operational core: a layered contract through which SDA clauses are represented as governed records preserving identity, role, lexical evidence, primitive assignment, and audit provenance. The vocabulary is organised into three groups: the five-dimension schema layer contract; the stratified entity vocabulary (seven primitives, seven composites) and the ten-operator relation layer derived in Chapter 6, Section 6.1 and consumed by the schema’s ontological mapping layer; and the clause-class label set together with the residual-governance vocabulary.

4.1 Schema Layer Contract

The five layers operationalise the six design principles of the standardisation schema. Each layer specifies a purpose, a required-field set, a validation rule, an ambiguity-handling rule, and a handoff consumer.

Identity layer — Stabilises record identity across duplicated clause IDs and preserves source traceability. Required fields: record_uid (SHA1 hash of source_clause_id | source_text, unique across all rows), source_clause_id (string, repeats allowed only with distinct record_uid), source_text (non-empty string), provenance_ref (source file path plus location anchor). Validation: record_uid unique; source_text non-empty; identity conflicts marked via ambiguity_profile.identity_conflict=true. Source: Chapter 5 §5.5.

Clause-role layer — Preserves the inferential class of each statement. Required fields: clause_class, modality_profile. Validation: missing/unknown class is invalid; defaulting disallowed unless explicitly justified; mixed or uncertain frames marked via ambiguity_profile.role_conflict=true with an explanatory note. Source: Chapter 5 §5.5.

Lexical-semantic layer — Represents term evidence and polysemy burden at row level. Required fields: term_lemma_set (array of normalised lemma strings), ambiguity_profile (object carrying polysemy confidence, identity conflict, role conflict, and explanatory notes). Validation: each mapped high-frequency lemma must include a confidence label drawn from {strong, moderate, weak}; polysemous terms keep the confidence label and method-evidence summary. Source: Chapter 5 §5.5.

Ontological mapping layer — Binds terms to primitives and relations under declared constraints. Required fields: primitive_assignments (array of {term, primitive, rationale} tuples with rationale tag drawn from {direct, keyword, fallback}), relation_assignments (array of canonical relation tags), residual_flag (boolean). Validation: mappings outside the approved primitive and relation sets are invalid; each assignment requires a rationale tag; unstable assignments take the residual path. Source: Chapter 5 §5.5.

Governance audit layer — Ensures reproducible, reviewable artefact behaviour across chapter boundaries. Required fields: provenance_ref, residual_flag, notes. Validation: every verified claim row must trace to its source object and chapter claim-bank ID; residuals cannot be suppressed; unresolved rows require a documented disposition stage. Source: Chapter 5 §5.5.

4.2 Stratified Entity Vocabulary: Seven Primitives and Seven Composites

The closed entity vocabulary derived in Chapter 6, Section 6.1 and inherited by the standardisation schema’s ontological mapping layer. The cognitive primitive–composite–module architecture stratifies it into seven schematic primitives — irreducible conceptual baselines — and seven elaborated composites construed from them through the relation operators (Section 4.3). Each term is recorded with its plane and operational definition; SDA-corpus clause-coverage figures are documented in Supplementary Foundational Mapping Coverage.

Schematic primitives

space — Spatial extent: a bounded area without residential-function constraint; includes approach spaces, transition zones, and access spaces. Plane: Primitive. External grounding: IFC4 IfcSpace; BOT bot:Space. Source: Chapter 6, Section 6.1.

boundary — Limit or interface: a spatial edge defining the containment limit of a space; walls, partitions, and demarcating elements. Plane: Primitive. External grounding: IFC4 IfcWall; BOT bot:Interface. Source: Chapter 6, Section 6.1.

element — Built objecthood: an abstract built component without fixture specificity; structural and non-structural building elements. Plane: Primitive. External grounding: IFC4 IfcBuildingElement. Source: Chapter 6, Section 6.1.

quality — Property or scale: a measurable or observable attribute of an entity; dimensional, performance, presence, or categorical. Plane: Configurative. External grounding: Thesis-specific (no IFC4 / BOT direct equivalent). Source: Chapter 6, Section 6.1.

activity — Event or use: an occupant action that a space or fixture is specified to support (toilet transfer, showering, cooking). Plane: Configurative. External grounding: Thesis-specific. Source: Chapter 6, Section 6.1.

context — Frame or applicability: regulatory scope; SDA design-category membership (Fully Accessible, Robust, Livable). Plane: Interactive. External grounding: Thesis-specific. Source: Chapter 6, Section 6.1.

actor — Participant: the human subject a requirement addresses (participant, resident, wheelchair user, support worker); the primitive made explicit under the re-stratification, inheriting the participant lemmas formerly recorded under role. Plane: Configurative. External grounding: Thesis-specific. Source: Chapter 6, Section 6.1.

Elaborated composites

room — Bounded space (a zone) construed as enclosed, functionally identified, and activity-supporting within a regulatory frame; a residential space with declared functional identity (bathroom, bedroom, kitchen). Derivation: space bounded_by boundary + functional identity + supports_activity + within_context. External grounding: IFC4 IfcSpace (typed); BOT bot:Space. Source: Chapter 6, Section 6.1.

dwelling — Aggregate of rooms construed as a residential unit under actor occupancy and regulatory context. Derivation: aggregate(room/space) + within_context(residential) + actor occupancy. External grounding: IFC4 IfcBuilding; BOT bot:Building. Source: Chapter 6, Section 6.1.

opening — A boundary construed as passable; doors, doorways, and hatch-type openings. Derivation: boundary + passable quality + connects(space, space). External grounding: IFC4 IfcDoor, IfcWindow. Source: Chapter 6, Section 6.1.

path — space construed as directed movement; a designed horizontal circulation route between spaces. Derivation: space + connects(origin, destination) + supports_activity(circulation). External grounding: IFC4 IfcSpace (circulation typing). Source: Chapter 6, Section 6.1.

level — space construed through vertical ordering; the storey or floor on which spaces are located. Derivation: space + vertical-order quality + located_at_level. External grounding: IFC4 IfcBuildingStorey; BOT bot:Storey. Source: Chapter 6, Section 6.1.

fixture — An element construed as installed, located, and activity-supporting (grab rail, basin, shower). Derivation: element + installed quality + located-in + supports_activity. External grounding: IFC4 IfcSanitaryTerminal. Source: Chapter 6, Section 6.1.

role — actor, activity, and entity construed as a functional assignment relative to occupant need (grab support, transfer, ambulation); expressed relationally through serves_role rather than as a standalone entity mapping. Derivation: actor + activity + entity + within_context. External grounding: Thesis-specific. Source: Chapter 6, Section 6.1.

4.3 Relation-Operator Layer (Ten Operators)

The closed operator layer against which the standardisation schema’s relation_assignments field is validated. What the flat vocabulary listed as a relation primitive is reconceived here as the layer of operators that connect primitives and generate composites. Two operators (is_a, part_of) are standard ontological primitives; eight are thesis-specific extensions justified by the novel-relation analysis in Chapter 6, Section 6.1.

is_a — Taxonomic-type assignment (e.g., a module is a Fully Accessible bedroom). Status: Standard ontological primitive. Source: Chapter 5 §5.5; Chapter 6 §6.2.

part_of — Mereological containment between entities (e.g., a fixture is part of a room). Status: Standard ontological primitive. Source: Chapter 5 §5.5; Chapter 6 §6.2.

bounded_by — A space is bounded by a named boundary element (typically a wall or partition). Status: Thesis-specific extension. Source: Chapter 5 §5.5; Chapter 6 §6.2.

opens_to — An opening provides access from one space to another, with directionality recorded. Status: Thesis-specific extension. Source: Chapter 5 §5.5; Chapter 6 §6.2.

connects — Two spaces are connected by a path or opening. Status: Thesis-specific extension. Source: Chapter 5 §5.5; Chapter 6 §6.2.

located_at_level — An entity is located at a named storey or vertical level. Status: Thesis-specific extension. Source: Chapter 5 §5.5; Chapter 6 §6.2.

has_quality — An entity carries a named quality (dimensional, performance, presence, or categorical). The most heavily loaded relation in the SDA corpus (Gini 0.6639 across four semantic subgroups). Status: Thesis-specific extension. Source: Chapter 5 §5.5; Chapter 6 §6.2.

serves_role — A fixture or element serves a declared functional role within a space. Status: Thesis-specific extension. Source: Chapter 5 §5.5; Chapter 6 §6.2.

supports_activity — A space or fixture supports a declared occupant activity. Status: Thesis-specific extension. Source: Chapter 5 §5.5; Chapter 6 §6.2.

within_context — A term is framed within a regulatory or situational scope (a design-category context), recorded as a governed link distinct from the context entity itself. Status: Thesis-specific extension (added under the re-stratification). Source: Chapter 6, Section 6.1.

4.4 Clause-Class Labels and Mapping Vocabulary

The closed enum admitted as values of the clause_class field; the schema disallows defaulting and requires explicit justification for uncertain classifications.

design_requirement — A clause specifying a binding accessibility obligation that the dwelling must satisfy (the dominant SDA clause class). Source: Chapter 5 §5.5.

rationale — A clause stating the reasoning, design intent, or evidential basis for a related requirement; non-binding on the dwelling but binding on interpretive context. Source: Chapter 5 §5.5.

applicable_to — A clause specifying the design-category scope or condition under which a related requirement applies; the syntactic locus of governance-scope conditioning. Source: Chapter 5 §5.5.

other — Residual class label for clauses that do not fit the three primary classes (administrative, transitional, or definitional content). Use requires explicit note and role_conflict marker. Source: Chapter 5 §5.5.

Modality profile — Object field recording modal_terms (the modal vocabulary present in the clause: shall, must, should, may, is to, etc.) and normative_force (the inferred deontic strength). Weak or ambiguous normative-force classifications are recorded explicitly rather than collapsed. Source: Chapter 5 §5.5.

Ambiguity profile — Object field carrying four sub-fields: polysemy_confidence (strong / moderate / weak); identity_conflict (boolean — flagged when source_clause_id repeats with distinct source_text); role_conflict (boolean — flagged when clause-role classification is mixed or uncertain); notes (free text). Source: Chapter 5 §5.5.

Residual flag and residual reason — Boolean field and accompanying free-text reason indicating that the row carries insufficient evidence for stable primitive assignment, relation assignment, or role disambiguation. Residual rows must include a planned disposition stage (§5.6 implementation pass, expert adjudication pass, or chapter-limit statement); suppression of residuals is prohibited. Source: Chapter 5 §5.5.

Mapping rationale vocabulary — Three-value closed enum for the rationale tag attached to each primitive_assignments entry: direct (the term is the primitive’s lexical instance), keyword (assignment via keyword evidence from the SDA’s requirement structure), fallback (assignment through the fallback pathway when direct and keyword routes are unavailable; the corpus carries 54 fallback-route assignments per the §5.5 reporting). Source: Chapter 5 §5.5; Supplementary Foundational Mapping Coverage.

The dictionary establishes the governed terminological substrate against which downstream chapter claims, appendix specifications, and tool-implementation contracts are to be read. No term in the thesis that carries technical load is left to interpretive reconstruction: each is anchored to a single operational definition with a back-reference to its derivational source.