Appendix F: Reference Catalogs and Dictionaries

Code Families Legend

This appendix is the single consolidated legend for the short-form identifier families used across the thesis. Each family is a prefix that names a class of governed objects (requirements, design features, evaluation measures, contracts, claims, axioms, invariants, and the rest) so that the artefact chapters can refer to a specific object by a stable code rather than re-describing it on each mention. The legend pairs every prefix with its single uniform expansion, a one-line operational description, and the location where the family is defined and first used.

The legend consolidates and extends the List of Abbreviations, which defines the acronyms that appear in running prose. Where a family already appears there, this legend cites it and does not restate a divergent expansion; where a family is used in the chapter bodies, appendices, or figure specifications but is absent from the abbreviations list, this legend is its authoritative definition. For full conceptual definitions of the underlying constructs, see the Glossary and the Data Dictionaries; for the reference registers the codes index, see the Environment-Derived Requirements Register, the Evaluation Workbench, the Requirements-Design-Evaluation Traceability Matrix, the RecPol Specification, and the PlaniSyn Grammar.

Reading the table

Each row records a prefix, its uniform expansion, what an instance of the family denotes, and the defining location. A representative instance is given in parentheses where it aids recognition. The “Defining location” column points to the module that introduces the family on first use and carries its canonical inventory.

The argument-spine and traceability families

These families carry the thesis’s design-science traceability chain from problem to contribution. They are introduced in Chapter 4 and recur in every subsequent chapter.

The proposition and property families

The two P senses are deliberately distinguished at every first use per the property-versus-proposition discipline, because P1 to P5 carries two distinct meanings.

The alignment is one-to-one: Property Pn motivates Proposition Pn, which is tested by evaluation question EQ-0n. The abbreviations list records the proposition sense; the property sense is qualified in prose by the word “Property” at first use, never left as a bare Pn. The full consolidated wiring, pairing property, proposition, meta-requirement, evaluation question, formative and summative measures, and evidence objects for each Pn, is the Canonical Property-Proposition-Evaluation Map.

The notation families (RecPol and PlaniSyn, Chapter 7)

These families govern the two-layer planimetric notation. RecPol is the formal core; PlaniSyn is the applied layer. The full inventories are in the RecPol Specification appendix and the PlaniSyn Grammar appendix, with operational definitions in the Data Dictionaries.

The empirical-substrate families (Chapter 8)

These families govern the empirical substrate: its claims, its scope limits, its cross-pipeline coherence probes, and its packing-efficiency indices. The supporting registers are in the Chapter 8 supplementary-context modules.

The cross-chapter handoff-contract family (HC)

HC names the formal interface a chapter hands to the chapter that consumes its product. The abbreviations list registers only the HC-6 series; the full series is registered here. The handoff chain itself is documented in the Artefact Suite Handoff Contracts appendix.

Module-type and instance-suffix codes

The nine governed-kernel module types (ENT, CIR, SAN, BED, LIV, KIT, SVC, EXT, DWL), the Rule-4 variant tags (HLP, LNK, OFC, DIN), and the Chapter 10 instance suffixes (BRn for BED-class instances, BAn for SAN-class instances) and trajectory codes (S0-S5, E0→1 … E4→5) are registered in the List of Abbreviations under “Modularity-scheme primitives” and “State and trajectory codes” and are not duplicated here.

The infix grammar

Several families embed a chapter or category infix between the prefix and the running number. The conventions are uniform across the thesis and are stated here once.

• The -4W- / -09- evaluation-measure infix. An evaluation measure carries the chapter that operationalises it as an infix. EM-4W-01 to EM-4W-03 are the three measures defined and pre-registered in Chapter 4 (the “4W” workbench notation); EM-09-01 to EM-09-04 are the four measures executed and reported in Chapter 10 against the Chapter 9 generator outputs. The infix is the chapter binding, not a sub-series: EM-4W-* and EM-09-* are one seven-measure set, three pre-registered and four executed.
• The design-feature chapter infix. A design feature carries its chapter as a two-digit infix with a sub-letter: DF-05A-01 is a Chapter 5 design feature, DF-06B-01 a Chapter 6 feature, DF-07C-* Chapter 7, DF-08D-* Chapter 8. The sub-letter tracks the artefact letter the chapter develops.
• The -CW- candidate-work and -AW- author-work infix. A deferred-work item is named Ch{N}-CW-{NN} (candidate post-submission work) or Ch{N}-AW-{NN} (author-carried limitation or future-work commitment), where {N} is the originating chapter and {NN} the running number: for example Ch5-CW-04 (single-rater calibration scope) and Ch6-AW-04 (cross-corpus generalisation).
• The trailing ER suffix. A deferred-work code may carry a trailing ER to mark that the item is an external-review obligation: a check that, by its nature, requires an independent third party rather than the candidate or author to discharge. For example Ch7-CW-10ER is the independent third-party Goodman-verification item: candidate-work that is sealed only on external review. The suffix is read as part of the code, not as a separate token.

Cited-undefined codes: resolutions and flags

The seal requires every code cited as an authority in examiner-facing prose to be either enumerated here or, where its meaning is not determinable from the text, flagged for operator judgement. The following are the determinations.

Enumerated (defined above and resolvable from the text)

• EXP-*: Experiment file. A sealed experiment record under experiments/recpol-v6/ or the corresponding experiment directory (for example EXP-7.5-hc6-compliance.md, EXP-6.3-interactive-plane-semantics.md, EXP-5B.1), cited as the provenance for a notation or semantic result. Note: every use in the body and appendices is the experiment-file sense; the List of Abbreviations previously glossed EXP as “Exemplar file (PlaniSyn-encoded)” and has been corrected to the uniform experiment-file expansion, so the two records now agree.
• EC-01 … EC-10b: Extensibility Contract clauses (EXP-7.6); enumerated under the notation families above.
• SL-02 … SL-06: Scope Limits; enumerated under the empirical-substrate families above (SL-02 source bound, SL-03 packing cap, SL-04 hardcoded thresholds, SL-05 untestable probes, SL-06 boundary-margin sensitivity).
• INV-C / INV-I: Configurative-plane and Interactive-plane invariants; enumerated under the notation families above.
• NR-014: Notation Rule 014 (the four typed interaction declarations realising the three interface types); enumerated above.
• G-V-01: Generator-Verification audit 01 (the 2026-04-24 D8-canonicalisation implementation audit confirming the 100 canonical packings are unique under the D8 equivalence relation). Determinable from the Chapter 8 polyomino-grammar supplementary module; registered here as a generator-verification audit identifier.

Flagged for operator judgement (not determinable from examiner-facing text)

• T-E-01 / T-V-01: No definition or use exists anywhere in the examiner-facing text (publish-text/). The strings appear only in non-examiner working records (debt registers, plans, and archived drafts). They cannot be enumerated from context. Flag: if these codes are cited in any examiner-facing passage, the citation is orphaned; if they are not cited there, no legend entry is required. Removal from prose, if any citation is found, is a separate operator decision and is not performed here.
• AM-08: Cited once in examiner-facing text, as an axiom-trace tag on invariant INV-P-06 (“Axiom trace: DA-06; AM-08”) in the Data Dictionaries. Resolved, the citation is correct: AM-08 is Identity Preservation Under Transformation, entry 08 of the Abstract Model Specification Register (AM-01-AM-18) established in the working experiment record EXP-3.4-abstract-models.md. The INV-P-06 trace pairs the design-axiom warrant (DA-06, Stratified) with the abstract-model commitment (AM-08); both halves are intended, so the trace is correct as written (it is not a stale alias for DA-08, which is the unrelated “Extensible” axiom). The only residual is presentational: the AM register is defined in a working experiment file rather than in examiner-facing text, so promoting an AM-family summary into this legend is an optional operator choice, not a correction.
• DP-R1 … DP-R3: Prescriptive Principle (design principle). Resolved, examiner-facing: the family appears as the three prescriptive principles DP-R1-DP-R3 in Appendix A, "Prescriptive Principles" (DP-R1 separate semantic obligations from geometric rendering at the interface; DP-R2 treat change as named transformation units with explicit invariants; DP-R3 use pre-registered comparators for burden and validity claims), and is now enumerated under the traceability families above. The prior audit-internal flag is superseded.

ER expansion: the locked decision

The List of Abbreviations previously hedged the ER expansion as “Evaluation Requirement (or Evaluation Reference)”. The seal requires a single uniform expansion, and the evidence fixes it unambiguously:

• The two registers that own the ER-01 … ER-06 identifiers are titled the Environment-Derived Requirements Register and the Environmental Grounding Dossier, and each row is an “environment-derived requirement”.
• Chapter 4 introduces the family as “six environment requirements (ER-01 to ER-06), each a governance obligation derived from the housing-adaptation problem”, and the traceability matrix routes “environment-derived requirements through design features to evaluation measures”.
• Neither “Evaluation Requirement” nor “Evaluation Reference” matches any register title or body usage; both hedge expansions are spurious.

Locked expansion: ER = Environment Requirement (equivalently, environment-derived requirement), uniform across the abbreviations list, this legend, and the requirements appendices. The hedged abbreviations-list entry is corrected to this single form.

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, Liveable). 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.

Artefact Suite Handoff Contracts

The five artefacts of this thesis are built in sequence, and each one inherits a defined product from the artefact before it and leaves a defined product for the artefact after. Stating those handoffs explicitly is what allows each chapter to check its inputs locally rather than re-derive them from the whole suite. The artefacts are laid down in build order: the standardisation schema (Chapter 5); the Governed Kernel Architecture (Chapter 6); the notation (Chapter 7); the empirical substrate (Chapter 8); and the procedural generation and documentation prototype, the generator (Chapter 9), whose output is evaluated in Chapter 10. The empirical substrate of Chapter 8 is sealed before the generator of Chapter 9 is built, because the generator consumes that substrate.

The handoff chain

The chain runs standardisation schema → Governed Kernel Architecture → notation → empirical substrate → generator → Chapter 10 evaluation. The table below records, for each artefact, the chapter that develops it, what it produces, what it requires from upstream, and what it checks before passing its product on. The empirical substrate is the point at which the representational stack of the schema, the kernel architecture, and the notation meets the corpus evidence; the generator then consumes that substrate together with those three upstream contracts.

What Chapter 5 commits to downstream

The standardisation schema makes five commitments that the rest of the suite relies on, and each is backed by evidence an examiner can inspect. Baseline ambiguity and fragmentation are measured, with the measurements held in the corpus-integrity, polysemy, and structural-metrics appendices (SDA Corpus Integrity Metrics, Polysemy Metrics and Confidence, and Trigram and POS Structural Metrics). The schema design fields are decision-complete, as set out in Chapter 5, Sections 5.3 and 5.4. Mapping quality is reported together with its residuals in Foundational Mapping Coverage. The full results and the downloadable release artefacts are exposed in SDA Results and Data Package. And the constraints that bind the downstream handoff are stated in Chapter 5, Section 5.11, and in the contracts below.

The Chapter 6 to Chapter 7 contracts

Four formal contracts govern the transmission of the Governed Kernel Architecture from Chapter 6 to the notation of Chapter 7. Each names the substrate Chapter 7 inherits and the property its grammar must preserve; the full prose specification is in Chapter 6, Section 6.5, and the four-row summary follows.

Evidence discipline across the suite

The handoffs rest on one discipline applied throughout: each substantive claim is tied either to an evidence appendix or to a cited scholarly source, no claim depends on a path outside the deposited materials, and residual limitations are declared wherever the evidence remains partial.

1 Purpose and Scope

The artefact suite presented in Chapters 5 through 10 is the v6.0 state of a research programme whose architectural commitments and methodological choices have evolved through prior iterations. This appendix documents two evolutions that materially shape the current artefacts: the Bunnings corpus processing pipeline (the dimensional-analysis methodology of Chapter 8) and the notation conceptual framing (the two-layer architecture of Chapter 7). Both evolutions involved earlier approaches that were investigated, partially executed, and superseded by the approaches now reported in the main text. The earlier approaches are documented here for transparency: the examiner can trace the architectural-thinking trajectory rather than encounter the v6.0 state as if it were the only state ever considered.

The appendix does not relitigate the earlier approaches. Where an earlier approach is shown, the appendix explains what it did, why it was investigated, and what drove the move to the current approach. Cross-references to the current main-text treatments are provided so the reader can navigate between the earlier and current methods without re-reading the canonical chapters. The transparency commitment served by this appendix is consistent with the methodology chapter’s and discussion chapter’s commitments to documenting evidential trajectory honestly, including the approaches that did not produce the contribution but informed the search for the approach that did.

The appendix is organised in two sections. §2 documents the methodology evolution of the Bunnings corpus processing pipeline, with two earlier-approach figures and a cross-reference to the current Chapter 8 §8.21 treatment. §3 documents the notation conceptual evolution from a four-layer nested-onion framing to the current two-layer functor architecture, with one earlier-framing figure and a cross-reference to Chapter 7 §7.3.

2 Methodology Evolution: Bunnings Corpus Processing Pipeline

The Chapter 8 dimensional analysis (§8.21) operates over the validated rebuild corpus of 40,342 dimension values across 23,048 products, drawn from the Bunnings Australian retail catalogue. The substantive source is the same Bunnings catalogue across the methodology evolution documented here; what changed across the successive approaches is the measurement, cleaning, and scoring logic. The decisive change was the last one: the final, current approach replaced an un-instrumented language-model measurement and an ISO-floored composite-coverage score, which together produced the now-retired “25 mm base module” reading, with a deterministic, instrument-validated measurement scored by lift over a reporting-convention null, which finds a 50 mm dominant grain with 25 mm a secondary sub-module. The two earlier approaches below are recorded as superseded history.

2.1 Earlier Cleaning Approach: Tukey IQR Outlier Fences with k = 8.0

The November 2025 cleaning pipeline applied Tukey IQR outlier fences with a configurable k value (default 8.0) to remove extreme dimension values from the raw catalogue. The pipeline computed Q1, Q3, and the inter-quartile range over the unified pool of dimensions across the four field types (width, length, height, thickness), then marked any dimension outside [Q1 − k·IQR, Q3 + k·IQR] as outranged. Outranged values were set to missing rather than removed entirely, so that a product retaining at least one valid dimension after fence-application was still classified as “cleaned” rather than “no-dimension”. The same fence parameters were applied to all four field types, on the principle that a single coherent fence is more interpretable than per-field fences. An optional hard cap (default none) provided a second exclusion gate above the IQR fence.

The k = 8.0 default reflected a deliberately permissive fence: a typical Tukey IQR analysis uses k = 1.5 for outlier flagging and k = 3.0 for “far out” classification. The choice of k = 8.0 was made to remove only the most extreme catalogue artefacts (data-entry errors, products with implausible dimensions such as a 50-metre door) while retaining the long tails that legitimate residential construction products produce. The wide fence was tractable in the November 2025 corpus but raised two interpretability concerns. First, the choice of k was not derived from a principled criterion; it was set by inspection of the empirical distribution. Second, the same fence applied to four different field types (each with their own dimensional regime) presupposed comparability across fields that the cleaning step did not verify. Both concerns motivated re-examination of the cleaning approach prior to the v6.0 dimensional analysis.

2.2 Earlier Module-Selection Approach: Divisibility Scoring with LCM-Based Meso-Tier Extension

The November 2025 module-selection methodology operated in two tiers. The micro-tier evaluated candidate modules in the 19-296 mm range, ranking each candidate by its divisibility score: the proportion of corpus dimensions that the candidate exactly divides. The procedure required each candidate to be non-divisible by any earlier candidate (preventing trivial multiples from competing as separate candidates) and discarded any candidate whose multiples were already represented by an earlier-ranked candidate. The top five candidates from the micro-tier were then passed to the meso-tier extension. The meso-tier combined the top five into pairs, triples, and quadruples, calculated the least common multiple (LCM) for each combination, removed LCMs exceeding 50,000 mm or duplicated by earlier combinations or overshadowed by simpler ones, and scored the remaining LCMs by the same divisibility criterion. The procedure terminated by ranking the meso-tier results and producing a final ordered list.

The divisibility-and-LCM methodology had two structural weaknesses that emerged on closer examination. First, the divisibility criterion alone could not discriminate between a candidate that achieves wide coverage by happenstance (because the corpus contains many multiples of small integers) and a candidate that achieves coverage by co-ordinating with the corpus’s preferred-number structure. Two candidates with similar divisibility scores could carry substantively different co-ordinating utility, and the methodology had no way to surface that difference. Second, the LCM-based meso-tier extension generated combinations whose interpretability was thin: an LCM of 25 mm × 50 mm × 100 mm × 300 mm equals 300 mm and is therefore dominated by the 300 mm candidate alone, and the combinatorial expansion produced many such trivially-dominated combinations. The meso-tier filtering removed the most obvious dominations but did not eliminate the underlying issue that LCM-based combination was the wrong operator for testing multimodule co-ordination.

2.3 Intermediate Approach: Composite-Coverage Sweep with Subsampling Stability (superseded 2026-06-19)

This methodology, itself since superseded, evaluated candidate modules using a composite score that integrated three coverage metrics: hard coverage (exact divisibility), soft coverage (within ±12.5% of nearest multiple), and ISO 2848 conformance (whether the candidate is an M/n sub-module of the 100 mm basic module M). The composite score was computed as S(m) = w₁·C(m) + w₂·F(m) + w₃·R(m), evaluated over m ∈ {25, 26, …, 296} mm against the then-current 3,592-instance corpus, with the composite-coverage “knee” identified as the argmax. It returned m* = 25 mm. A 2026-06-19 methodological audit found this construction question-begging: the search floor was fixed at the ISO M/4 value of 25 mm, and the composite was not baselined against any null, so it could not distinguish a genuine grid from the trivial preference of any coverage measure for a finer grain. The measurement it scored was, moreover, an un-instrumented language-model inference from product titles. The approach is retained here only as superseded history; the current approach is §2.5.

2.4 What Drove the Evolution

Three drivers moved the methodology from the earlier cleaning and module-selection pipelines (the two earlier-approach figures above) to the current Chapter 8 §8.21 approach. First, the composite-score methodology introduced an explicit weight policy that the divisibility-only score lacked, allowing the dimensional analysis to be reproduced with declared rather than implicit priorities. Second, the composite-coverage knee operationalisation replaced the divisibility-rank operationalisation with a selection criterion that has a literature precedent in the modular product family research and that admits an interpretable visual diagnostic (the composite-coverage knee shown in the 4D composite-coverage curve for module candidate selection). Third, the subsampling stability test replaced informal stability checks with a fifty-resample procedure that records how often the composite-coverage knee recurs across resamples: a plain count over the complete corpus, with no interval estimate or significance test attached. Together, the three changes lifted the dimensional analysis from a single-pass divisibility ranking to a composite-coverage study whose selected module recurred under resampling: the form in which Chapter 8 previously reported an m* = 25 mm finding. That intermediate finding, and the claims first written from it, did not survive the clean-room rebuild of §2.5; the validated forms of claims CL-8-01, CL-8-02, and CL-8-03 are those reported against the rebuild.

2.5 Current Approach. Clean-Room Rebuild: Lift over a Reporting-Convention Null

The current Chapter 8 §8.21 methodology is a clean-room rebuild of the entire dimensional analysis, undertaken after the 2026-06-19 audit of §2.3. It differs from the intermediate approach in three decisive ways. Measurement is deterministic: each product title is parsed for stated dimensions by rule, with the ambiguous cases (mixed units, imperial marks, pack counts, gauge-and-length fasteners) resolved by a governed arbitration whose rules were fixed in advance; the instrument was validated at a conformance audit (random-stratum precision 1.000, unit-error 0.0%), where the intermediate approach had inferred dimensions by language model with no instrument check. Scoring uses no normative floor, the search runs over m ∈ [2, 300] mm, and ranks candidates by their lift over a rounded-to-5 mm reporting-convention null, removing the part of any module’s coverage that reporting convention alone explains, where the intermediate approach used an un-baselined composite floored at the conclusion it sought. Result: across the validated corpus of 40,342 values, 50 mm carries the highest lift of any standard grain in every cohort, 100 mm next, and 25 mm registers as a genuine but secondary sub-module, robust across three cohort cuts and a matching-tolerance sweep: the sole candidate to out-lift 50 mm anywhere being the fine divisor m = 4 mm, in the building cohort at exact match alone and by 0.002, which survives no tolerance. The full method is reported in §8.21, the robustness in §8.57, and the corpus construction in §8.10. The validated finding is a 50-100 mm metric grid (standard sheet/door sizes), with 25 mm a common sub-module, consistent with, but not unique to, ISO 2848, on which the validated forms of CL-8-01..03 are graded.

3 Notation Conceptual Evolution: From Nested Onion to Two-Layer Functor Architecture

The Chapter 7 notation system is presented as a two-layer architecture (RecPol formal core and PlaniSyn applied grammar) connected by a category-theoretic wrapping functor W: G → A (§7.2). An earlier conceptual framing represented the same architectural question as a four-layer nested-onion structure with an informal outer “ontological mapping” layer. The earlier framing did not survive into v6.0 because its outer layer lacked a formal mechanism; the current architecture provides the formal mechanism (the functor plus the extension-point token discipline) that the earlier framing only named.

3.1 Earlier Conceptual Framing (November 2025)

The November 2025 conceptual sketch organised the notation architecture as four concentric layers with an external linkage. The innermost layer was a specific module dimension (labelled unit module 150, corresponding to the 150 mm module candidate from the dimensional analysis’s meso-tier sweep); the next layer outward was RECTANGULAR POLYOMINO (the formal-core syntax now called RecPol); the next was PLANIMATIC SYNTAX (the applied layer now called PlaniSyn); and the outermost was ONTOLOGICAL MAPPING (the bridge to external systems). A bidirectional dashed link connected the outer layer to a separate OTHER SYSTEMS element.

The earlier framing carried two specific commitments that did not survive the architectural review. First, it conflated the module-dimension question (which belongs to Chapter 8’s empirical analysis) with the notation-architecture question (which belongs to Chapter 7’s formal specification); the unit module 150 innermost layer was an empirical commitment masquerading as a notation-architecture commitment. Second, the ONTOLOGICAL MAPPING outer layer named a bridge function without specifying a mechanism: there was no functor, no extension contract, no preservation property; the outer layer was a label rather than a structure.

3.2 Current Architecture: Two-Layer with Wrapping Functor

The current Chapter 7 architecture separates module dimension from notation architecture (the 50 mm base grain and the 150 mm meso grid are evaluated in Chapter 8 §8.21 and the dimensional library is specified in §8.26; neither appears in the notation architecture diagram) and replaces the informal outer-bridge layer with a category-theoretic wrapping functor W: G → A whose preservation properties are formally specified. The functor preserves identity (W(id_X) = id_{W(X)}), composition (W(g ∘ f) = W(g) ∘ W(f)), and semantic derivability (every PlaniSyn assertion is derivable from the composition of RecPol operations and the functor’s vocabulary binding). Six reserved extension-point tokens (OPEN_PAREN, CLOSE_PAREN, OPEN_BRACKET, CLOSE_BRACKET, DOT, AT) and ten extension contracts (EC-01..EC-10b per EXP-7.6) provide the formal channels through which applied-grammar layers introduce domain-specific syntax without modifying the formal core. The full specification is in Chapter 7 §7.3, with the two-layer notation architecture figure visualising the architecture; the wrapping functor’s formal definition is in the RecPol Specification appendix §12 and the PlaniSyn Grammar appendix §11.

3.3 What Drove the Evolution

Two drivers moved the conceptual framing from the earlier nested-onion sketch to the current two-layer functor architecture. First, the formal-mechanism requirement, every architectural layer must specify what it does rather than merely name what it is, disqualified the informal ONTOLOGICAL MAPPING outer layer and pushed the notation system toward a functor formulation whose preservation properties are stateable in category-theoretic terms (cited Mac Lane 1998 in the two-layer notation architecture figure’s caption). Second, the separation-of-concerns principle, formalised in the modularity theory of Chapter 3 §3.3 (interaction-density asymmetry) and operationalised in Chapter 6’s interface contracts (semantic, transformation, verification), required that empirical commitments (module dimensions) and structural commitments (notation layers) be located in their respective evidence chains rather than collapsed into a single visual artefact. The two-layer functor architecture satisfies both requirements; the four-layer onion satisfied neither.

4 Closing Position

This appendix documents architectural-thinking evolution as part of the thesis’s transparency commitment, not as an apology for revision. The earlier cleaning and module-selection methodology was a defensible exploratory pipeline whose limitations became visible only under the scrutiny that the current Chapter 8 methodology was designed to withstand; the earlier conceptual framing was a defensible working sketch whose informality became visible only when the current Chapter 7 architecture demanded a formal functor. The earlier approaches are documented here in their own terms, with the cross-references that allow the examiner to navigate to the current main-text treatments. The thesis’s contribution is the v6.0 state of the artefact suite; the trajectory from the November 2025 working state to v6.0 is part of the evidence that the contribution was reached through honest engagement with methodological alternatives rather than by selecting the first defensible approach and committing to it without re-examination.

Canonical Property-Proposition-Evaluation Map

This appendix is the single consolidated map of the thesis’s evaluation spine. It pairs each critical property with the proposition it motivates, the meta-requirement that grounds it, the evaluation question that tests it, the formative and summative measures that instrument it, and the evidence objects that warrant it. Every downstream verdict recital, in Chapter 10, Chapter 11, and Chapter 12, cites this map rather than restating the chain, so the correspondence is fixed in one place. The short-form identifier families used below, SP, ER, MR, EQ, EM, EVID, and the two senses of P, are defined in the Code-Families Legend; this map is their consolidated wiring, and it inherits that legend’s property-versus-proposition discipline.

Reading the table

Each row records one proposition, P1 to P5. The Critical Property column names the problem-class property from Chapter 2, Section 2.9 that motivates the proposition; the Proposition column gives the canonical mechanism name from Chapter 3, Section 3.5, which is the name the List of Abbreviations records. The alignment is one-to-one: Property Pn motivates Proposition Pn, which is tested by evaluation question EQ-0n. The measure columns carry the chapter infix fixed in the Code-Families Legend: EM-4W-* are the three measures pre-registered in Chapter 4, and EM-09-* are the four measures executed and reported in Chapter 10 against the Chapter 9 generator outputs. Proposition-level success is adjudicated under the four-result and promotion scheme of Chapter 4, Section 4.5, not by a separate success-criterion code.

The map

Notes on the map

• Argument-spine position. The map is the Evaluation stage, SP-03, of the four-stage argument spine registered in the Code-Families Legend (SP-01 Problem, SP-02 Artefact, SP-03 Evaluation, SP-04 Contribution, defined at Chapter 4, Section 4.1). The environment requirements in the linked-ER column are the SP-01 problem anchor; each proposition licenses a technological rule (TR-01 to TR-04, Chapter 11, Section 11.2) as its SP-04 contribution.
• Two naming registers. Each proposition carries a property name and a mechanism name, and both are load-bearing: the property name states what the proposition is a property of, the mechanism name states how it holds. This table fixes the mechanism name (Section 3.5, the List of Abbreviations sense) as the canonical proposition name and keeps the property name in its own column; recitals that name a proposition by its property (for example “Proposition 1, interoperability”) and recitals that name it by its mechanism (for example “Proposition 1, semantic interface and identity persistence”) both resolve to the same row.
• Formative-measure gaps. Only P1, P2, and P4 carry a Chapter 4 formative measure (EM-4W-01, EM-4W-02, EM-4W-03). P3 has no EM-4W-*; its formative round-trip evidence is inherited from Chapter 7, Section 7.20. P5 is summative-only, evaluated in Chapter 10 through EM-09-03.
• EM-09-01 definition. The EM-09-01 metric is the standards-interpretability aggregate resolution rate with a pre-registered floor of a 0.25 aggregate delta, computed from clause-level trace-completeness inputs, as fixed at Chapter 4, Section 4.4. Where the Requirements-Design-Evaluation Traceability Matrix records EM-09-01 as a “trace-completeness index”, that is the input term of the same three-term relationship (trace completeness to resolution rate to ambiguity reduction), not a competing definition.
• P4 evidence set. Proposition 4 is warranted by both EVID-P4-VARIATION and EVID-P4-EXCEPTION-BUDGET; the single-object entry in the Section 4.4 traceability matrix is an omission reconciled here.
• Success adjudication, not success codes. The SC-01 to SC-05 success-criterion labels used in the Section 4.4 traceability matrix are not reproduced here: proposition-level success is adjudicated by the Section 4.5 four-result and promotion scheme, and the artefact-level acceptance criteria live with their artefact chapters. The SC prefix in the Code-Families Legend denotes the Chapter 7 semantic contracts (SC-1 to SC-5), a distinct family; reconciling or retiring the Section 4.4 SC-0n labels against these is a residual for the Section 4.4 and legend sweep.

Codes above are defined in the Code-Families Legend; the full measure specifications are in the Evaluation Workbench and Chapter 4, Section 4.4.

Deposit Scope and Deposited-Artefacts Catalog

This appendix states the deposit scope of the thesis and catalogues the deposited artefacts, so that every empirical claim can be traced to the materials that warrant it. The deposit scope is the set of data bundles, artefact packages, and interactive surfaces deposited with the thesis; the running text and the data appendices draw on these, and no claim depends on a path outside them. The corresponding one-paragraph statement in the front matter records the scope for a reader who does not open this appendix; this catalogue is its enumerated form.

What is deposited

The deposited materials are organised by the chapter whose evidence they carry. Each bundle is a directory (or file) in the thesis data package; where a bundle carries its own index, that index records the bundle’s contents and its integrity manifest.

Integrity discipline

Most deposited files carry a recorded integrity check: a SHA-256 hash (for the interactive artefacts whose hashes are listed in the appendix data index) or a bundle deposit manifest (for the Chapter 5, 6, and 8 bundles). Where a hash or manifest is recorded, an examiner can confirm that the deposited file behind a figure or table is the one the analysis used. Completing integrity manifests for the Chapter 9 worked-example dataset and the Chapter 10 trajectory bundle is registered as an open deposit task.

Note on the Governed Instance Library deposit

The baseline library specifies 25 minimum entries; 11 are authored to full schema depth (9 Fully Accessible and 2 Robust: KIT-RB and EXT-RB). Eight of the nine Fully Accessible entries are deposited as standalone library files; the ninth (SAN-FA-01) is carried inline in Chapter 6, Section 6.4 as the schema demonstrator. The 2 authored Robust entries were authored for the Chapter 10 demonstration and are carried within the Chapter 10 demonstration packets. The remaining specified entries are inferred via Rule 4 pending dedicated authoring, consistent with handoff contract HC-6B (Section F.3) and the baseline-library coverage table in Appendix E.4. Completing the standalone deposit of SAN-FA-01 and the two authored Robust entries is registered as an open deposit task.