Appendix E: Notation and Schema Specifications

1 Purpose and Scope

The formal specification of the RecPol (Rectangular Polyomino Language) notation system, the formal core of the planimetric notation architecture developed in this thesis, is provided here. RecPol constitutes the underlying language layer upon which the PlaniSyn applied grammar (documented in the PlaniSyn Grammar appendix) is built. Chapter 7 (the notation: Planimetric Notation) presents the theoretical grounding and design rationale for this notation system; this appendix documents the complete formal specification of the language itself.

RecPol is a serialised, human-readable, modular language for defining and manipulating rectangular polyominoes as the primary subjects of spatial description. Statements are expressed as linear text-serialised expressions, structured as subject-verb-object patterns. These three characterising properties are the formal conditions under which PlaniSyn’s governance-capable spatial representation becomes possible, and each carries specific architectural consequences for the applied layer that PlaniSyn constitutes.

Serialised: RecPol expressions are linear sequences of tokens that can be emitted and consumed as a character stream without requiring random-access parsing or the maintenance of non-local state. This property is the enabling condition for PlaniSyn’s transportability: a PlaniSyn dwelling expression is a self-contained text artefact requiring no proprietary software to inspect, no rendering environment to interpret, and no schema negotiation to transmit. Serialisation is also the condition under which spatial records become version-controllable: a PlaniSyn representation can be stored in any text-capable repository, diffed against prior versions, and reviewed in any standard text editor without instrumentation.

Human-readable: RecPol’s uniform syntax (< id | predicates >) and natural-language-proximate verb vocabulary (MakeShape, CallForm, Place, Rotate) are designed so that a human reader can scan a RecPol expression and reconstruct the spatial intent without executing the expression. This property is load-bearing for the accessibility planning context in which PlaniSyn operates: dwelling planners, accessibility assessors, and regulatory verifiers require the capacity to audit spatial representations directly, without dependence on tool-mediated interpretation. PlaniSyn’s domain-specific vocabulary (module type identifiers (BED, SAN, CIR), interaction type names, and hierarchical nesting conventions) extends RecPol’s readability into the dwelling-specific semantic layer, maintaining the principle that the notation is inspectable by the practitioners who author and assess it, not only by the systems that parse it.

Modular: RecPol’s modularity is expressed through three co-operative mechanisms: the plane projection operator (^) makes every entity’s existential type explicit at the point of reference; the Context-Free axiom (Axiom 4) ensures that any entity block is fully interpretable without requiring access to surrounding expressions; and the Bounded axiom (Axiom 7) prevents composition cycles. Together, these mechanisms make every RecPol entity a self-contained unit of meaning: individually parseable, individually validatable, and individually reasoneable in isolation from the rest of the world model. PlaniSyn exploits this modularity to map RecPol entities onto the nine SDA module types, each of which carries its own constraint contracts and verification sequence requirements established in Chapter 6. The modular character of RecPol is thus the formal basis for PlaniSyn’s claim to governance-capable representation: modularity is what makes each spatial unit independently verifiable, and what prevents the representational monolithism that the thesis identifies as the primary structural deficiency of existing floor plan formats.¹

The language is designed to be both human-scannable and machine-parseable, maintaining the strict semantic properties (discreteness, composability, and governance preservation) that the thesis’s representational substrate requirements (§3.3) establish as necessary conditions for a governance-capable spatial notation. In summary, the three characterising properties (serialised, human-readable, and modular) are not independent desiderata but mutually reinforcing architectural commitments: serialisation enables transportability, human-readability enables auditability, and modularity enables governance-capable verification. Therefore, these three properties jointly constitute the formal basis upon which PlaniSyn’s applied grammar is constructed. The next section documents the design axioms and world model that formalise these properties at the language level.

This appendix is Version 6.0 of the RecPol specification (dated 2026-04-20). It supersedes Version 5.0 (2026-03-26), which specified seven design axioms. Version 6.0 adds Axiom 8 (Extensible), which formalises the two-layer extension contract (the wrapping functor W: G→A) that converts the applied-grammar architecture from an informal convention into a guaranteed property. It documents the notation at its current normative level. Sections marked normative define absolute requirements; sections marked non-normative are informative.

Scope: This specification records: the coordinate systems and world model; the entity type system; the predicate language and available verbs across all three planes; the parsing and tokenisation rules; the formal grammar in Extended Backus-Naur Form (EBNF); the canonical orthography; generative constraints; and error handling conformance levels. It does not cover specific implementation details of the interpreter or rendering engine beyond what is required to satisfy the semantic requirements.

Organisation: The specification is organised as follows: Section 2 records the eight design axioms and the three-plane world model. Section 3 specifies the coordinate systems comprising the spatial infrastructure. Section 4 defines entity types and the plane projection operator. Section 5 presents the formal EBNF grammar and parsing rules. Section 6 specifies the canonical orthography. Sections 7, 8, and 9 specify the semantics of each plane: Primitive, Configurative, and Interactive respectively. Section 10 documents generative constraints. Section 11 specifies evaluation and error handling. Section 12 positions this formal core relative to the PlaniSyn Grammar specified in the PlaniSyn Grammar appendix.

2 Design Axioms and World Model

This section is normative.

2.1 Design Axioms

The RecPol language is grounded in eight design axioms that constrain its architecture and govern the interpretation of all constructs. These axioms establish the structural invariants that make RecPol’s representational governance properties formally derivable rather than incidental.

Axiom 1: Polyomino-First. Polyominoes and their operations are the primary subjects of the language. All other constructs (coordinate systems, entity types, transformations) exist to describe and govern polyominoes. This contrasts with coordinate-first systems where shapes are emergent properties of point sets rather than first-class entities; in RecPol, the shape is the unit of meaning.²

Axiom 2: Serialised. Statements are linear and mirror subject-verb-object patterns. Linearity ensures that any RecPol expression can be parsed as a stream, facilitating real-time interpretation and human scanning without requiring the interpreter to maintain non-local state.

Axiom 3: Uniform Syntax. A single outer syntax (< id | predicates >) is used for all constructs across all planes and all entity types. Uniformity reduces cognitive load and simplifies the parser grammar, treating all entities as variations of a single structural archetype.

Axiom 4: Context-Free. The meaning of an expression is determined solely by its parts. No expression requires surrounding context (authorial intent, naming conventions, or positional metadata) for its semantic interpretation to be fully determined. This axiom is the formal basis for the self-contained governance property: a RecPol expression carries all information required for its own verification without bespoke reconstruction.

Axiom 5: Modular. Shapes and behaviours are composed using explicit interfaces. Internal composition of an entity is governed by the entity’s own declaration; external relationships are governed by explicitly declared interaction contracts. This axiom operationalises the information-hiding principle of modular systems at the language level.³

Axiom 6: Stratified. The world is divided into three planes (Primitive, Configurative, and Interactive) each inhabited by a distinct entity type. This stratification separates concerns: geometry (Primitive plane), relation (Configurative plane), and placement (Interactive plane), preventing category errors in spatial reasoning and enforcing the verification sequence constraint established in §6.3.⁴

Axiom 7: Bounded. Evaluation is guaranteed to terminate via acyclic composition. Cyclic entity references, in which an entity’s definition depends on itself directly or transitively, are prohibited. This axiom ensures that all RecPol models are computable in finite time, satisfying the finitude requirement of Axiom 3 in the thesis’s modularity framework (§3.3).

Axiom 8: 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 a machine-checkable character-set extension registration contract (the wrapping functor W: G→A). No other token type may be added without modifying core productions. A formal character-set extension registration mechanism ensures that new tokens do not collide with core tokens. This constraint preserves the formal core’s LL(1) parsing guarantees under extension and converts the two-layer grammar architecture from an informal convention into a formally guaranteed property. This axiom was added in Version 6.0 to close gaps in extension safety and parser-guarantee preservation that were identified when the Version 5.0 specification was reviewed: without a reserved, registered extension mechanism, applied-grammar tokens could collide with core tokens and break the formal core’s parsing guarantees.

Taken together, the eight axioms establish a coherent set of architectural constraints that make RecPol’s governance properties formally derivable rather than incidental: Polyomino-First defines the unit of meaning, Serialised enables stream processing, Uniform Syntax reduces parser complexity, Context-Free enables self-contained verification, Modular enforces information hiding, Stratified separates concerns across three planes, Bounded guarantees computability, and Extensible formalises the two-layer extension contract. Building on this axiomatic foundation, the world model section describes the lattice-structured spatial substrate through which these axioms are instantiated.

2.2 World Model

The RecPol world is a lattice of cells occupied by rectangular polyominoes. Three structural elements constitute the world model:

Cells: The atomic unit of space is the cell, which is a square area identified by a cell_index. Cells are defined as areas rather than points, avoiding the ambiguity of grid-intersection logic. Cells are the discrete, countable spatial units that provide RecPol’s orthogonal discrete world its governance properties: exact addressability, finite enumeration, and structural congruence with module boundaries.

Rectangular Polyominoes: Rectangular polyominoes are finite, edge-connected sets of cells that fill a contiguous rectangle with no gaps or holes. The restriction to rectangular polyominoes simplifies adjacency logic and ensures that all shapes can be decomposed into a union of rectangles: a decomposition property that supports the near-decomposable structure required by §3.3.

Planes. The world is stratified into three planes:

• Primitive Plane: Shapes, entities of invariant geometry, are the inhabitants of this plane.

• Configurative Plane: Forms, entities of relational geometry, are the inhabitants of this plane.

• Interactive Plane: Instances, entities of concrete placement, are the inhabitants of this plane in the World Grid.

The three-plane stratification is the structural basis for the verification sequence constraint (§6.3): Primitive-plane entities must be defined before Configurative-plane compositions that reference them; Configurative-plane Forms must be defined before Interactive-plane Instances that instantiate them. This ordering is architecturally enforced by the language semantics rather than being a workflow convention. Overall, the world model establishes the discrete, stratified spatial substrate that makes RecPol’s governance properties realised rather than merely claimed. The next section specifies the coordinate systems and spatial infrastructure through which entities are located in this world.

3 Coordinate Systems and Spatial Infrastructure

This section is normative.

3.1 Cell Index

A cell_index is a pair of integers x,y identifying a cell’s position in a coordinate space.

• x: Column index (horizontal, increasing left-to-right).

• y: Row index (vertical, increasing bottom-to-top).

• Zero Exclusion Constraint: x ≠ 0 and y ≠ 0. The origin is the implicit gap between x = −1 and x = 1, and between y = −1 and y = 1. The coordinate system is non-continuous across the origin (… −1, 1 …). Arithmetic operations calculating distance or span must account for the missing zero.⁵

3.2 Bounding Box (Local Grid)

Every entity operates within its own local coordinate frame called its bounding_box.

• Coordinates are strictly positive: x ≥ 1, y ≥ 1.

• The bottom-left occupied cell of the entity is normalised to 1,1.

• All internal geometry operations (such as MakeShape) occur in this frame.

Local coordinates are strictly positive to enforce a canonical normal form for all shapes, independent of their global position. This normalisation ensures that every shape has a unique, position-independent representation: a prerequisite for the stable referential identity that the semantic interface contracts in §6.3 require. Therefore, the bounding box normalisation is not an aesthetic convention but a governance requirement: without it, the same geometric shape could have multiple encodings, undermining the deterministic comparison property that version-controlled spatial records depend on.

3.3 World Grid (Global Grid)

The world_grid is the global coordinate frame for resolved entities on the Interactive Plane.

• Coordinates are integers ℤ  {0} (positive and negative, excluding zero).

• Extends infinitely.

• Mapping Rule: When an entity is placed in the World Grid, its local 1,1 origin maps to the target cell_index specified by the placement operation.

3.4 Edge Index

An edge is a side of a cell, identified by the triple x,y,eC:

• x,y: The cell_index of the cell whose edge is being referenced.

• C: The Signed Edge Cardinal (±1 to ±4).

Edge cardinal signs determine the facing direction:

External-facing edges (e1..e4) are defined as the space immediately adjacent to the shape boundary and are used for standard abutment interactions; internal-facing edges (−e1..−e4) are defined as the space immediately inside the shape boundary. They are used for alignment or embedding interactions. Thus the signed edge cardinal system provides a single, closed vocabulary for all spatial relationship types (abutment, alignment, and embedding) without requiring separate positional conventions for each relationship category.

3.5 Point and Corner Indices

Point indices (p1..p4) designate the four vertices of a cell’s bounding box:

• p1: Bottom-Left

• p2: Top-Left

• p3: Top-Right

• p4: Bottom-Right

Corner indices (c1..c4 and -c1..-c4) are defined to designate the logical corners of a shape’s boundary: the inflection points of the perimeter. Corner types are Convex (90°) or Reflex (270°). Positive corner indices select the external corner (the empty space wrapping the vertex); negative corner indices select the internal corner (the occupied material at the vertex). The four corner positions correspond to the same bottom-left / top-left / top-right / bottom-right naming as the point indices. Therefore, point and corner indices together provide a complete referential vocabulary for all geometrically significant positions on a shape boundary, and this implies that any placement or joining operation that references a boundary location can be expressed precisely without requiring coordinate calculation.

3.6 Interaction Lanes

A Lane is a string identifier that partitions the interaction constraint evaluation space. Constraints such as ConsLatchment and ConsOccupancy (§8.4) apply only between distinct Instances on the Interactive Plane that share at least one common lane.

• Purpose: Lanes enable selective constraint application: different geometric relationships (physical body, clearance zone, circulation path) can be governed by distinct lane-specific policies without mutual interference.

• Syntax: A string matching the pattern [A-Za-z0-9_]+.

• Default: If no lane is specified, the entity is assigned to default_lane.

Interaction lanes are the RecPol operationalisation of the interaction differential principle from §3.3: within-lane constraint density substantially exceeds cross-lane constraint density, maintaining the governance tractability of the interaction space. Thus the lane mechanism is the formal realisation of near-decomposability at the constraint level; this establishes that governance tractability is not a hoped-for emergent property but a structurally enforced consequence of the lane-partitioned evaluation architecture.

4 Entity Types and the Plane Projection Operator

This section is normative.

4.1 The Plane Projection Operator ^

Identifiers in RecPol are structured as namespace^name_stem. The caret symbol ^ is the Plane Projection Operator: it signifies the projection of an abstract name stem onto a specific existential plane, constituting the entity’s plane-typed identity. This operator is inspired by type theory, where a value is explicitly lifted into a specific context; here the context is the spatial plane.⁶

• A alone is merely a name (a string with no existential commitment).

• s^A projects the name onto the Primitive Plane, creating a Shape identity.

• f^A projects the name onto the Configurative Plane, creating a Form identity.

• i^A projects the name onto the Interactive Plane, creating an Instance identity.

The projection operator is the mechanism that prevents the category error of treating a Shape definition as directly placeable in the World Grid, or treating an Instance as a reusable geometric template: errors that would dissolve the governance properties of the stratified world model. Therefore, the plane projection operator is not syntactic decoration but a type-theoretic commitment: every entity reference carries its plane of existence as a structural part of its identity, and this implies that type errors at the plane boundary are detectable by syntax inspection alone without requiring semantic analysis.

4.2 Entity Type Specifications

Shape (s^)

A Shape is an entity of invariant geometry. Once defined, its internal structure is immutable: it is a rigid body that serves as a reusable geometric archetype. Shapes:

• Must be spatially contiguous.

• Are created via MakeShape (§7.1) or MakeComposite (§7.2).

• Cannot receive geometric transformations within their own definition; transformations are applied only to Shape references within Form definitions.

Form (f^)

A Form is an entity of relational geometry. Its spatial organisation is defined by the relationships between its member components rather than by absolute cell positions. Forms:

• Can be non-contiguous (compound): multiple disconnected islands within one Form are valid.

• Are created via CallShape (§8.1), MakeCompound (§8.2), or Pass.

• Carry constraint specifications (ConsLatchment, ConsOccupancy) that are precomputed at the Configurative Plane but evaluated only on the Interactive Plane.

Instance (i^)

An Instance is an entity of concrete placement. It occupies specific cells in the World Grid and can interact with other Instances according to the constraint policies of its underlying Form. Instances:

• Instances are defined to occupy a unique, specific location in the World Grid.

• Are created via CallForm, CallInstance, or Instantiate.

• Are the only entity type on which Interactive-Plane transformations (Place, Rotate, Mirror, Stretch) and constraint evaluations (ConsLatchment, ConsOccupancy) are performed.

The three entity types are defined to correspond to the three planes of the planimetric triad: Shapes inhabit the Primitive Plane (invariant structural geometry), Forms inhabit the Configurative Plane (relational composition and constraint specification), and Instances inhabit the Interactive Plane (concrete placement and governance-validated interaction). This correspondence makes the verification sequence constraint structurally intrinsic to the language: a valid Instance presupposes a valid Form, which presupposes valid Shapes. Taken together, the three entity types constitute a type system that enforces the governance sequence at the language level rather than at the workflow level, eliminating a class of representational errors that convention-based systems cannot prevent. The next section specifies the formal syntax, tokenisation rules and EBNF grammar, through which these entity types and their predicate vocabularies are expressed in text.

5 Formal Syntax: Tokenisation and Grammar

This section is normative.

5.1 Tokenisation

The source text of a RecPol program is a sequence of tokens. Tokenisation rules:

1. Whitespace: Ignored (space, tab, newline).

2. Comments: Ignored (see §6.7 for syntax).

3. Symbols: The following characters are single-character tokens: < > { } ( ) | ; : ,

4. Words: Any maximal sequence of non-whitespace, non-symbol characters forms a single word token.

5.2 Parsing Structure

Entity Block. The top-level construct is the Entity Block. It has two forms:

• Full form: < identifier | predicate_list >

• Degenerate form (no predicates): < identifier >

The identifier must be a valid namespace^name_stem token. The predicate list is a sequence of one or more Predicate Blocks, separated by semicolons (;). A trailing semicolon after the final predicate is optional.

Example: < s^A | { Op1 } ; { Op2 } >

Predicate Block. A container for a verb and its arguments:

• Syntax: { Verb argument* }

• The verb is a keyword (case-insensitive).

• Arguments are zero or more tokens following the verb.

Arguments. Arguments follow specific patterns depending on the verb signature:

Nested predicates, where an entity reference contains its own predicate list, allow for anonymous inline modification of entities, enabling concise expression without requiring separate top-level definitions. This recursion is bounded by Axiom 7: no cycle may form in the nesting. Overall, the parsing structure ensures that every well-formed RecPol expression is both machine-parseable without lookahead and human-scannable without specialised tooling. The next section presents the formal EBNF grammar that encodes these parsing rules as a strict normative specification. Thus the parsing structure is the bridge between the informal notation that practitioners read and the formal grammar that validators implement; this establishes that the two are guaranteed to agree wherever a conformant parser is in use.

5.3 Formal Grammar (EBNF)

The following Extended Backus-Naur Form (EBNF) provides the strict normative syntax of RecPol.

entity_block    ::= "<" space identifier space ("|" space predicate_list space)? ">"

predicate_list  ::= predicate (space ";" space predicate)* ";"?

predicate       ::= "{" space verb (space argument)* space "}"

identifier      ::= namespace "^" name_stem

namespace       ::= "s" | "f" | "i"

name_stem       ::= [A-Za-z0-9_]+

verb            ::= [A-Za-z]+

argument        ::= cell_index | cell_range | edge_segment | entity_ref | value | point_pair | wildcard

point_pair      ::= point_index ":" point_index

point_index     ::= "p" [1-4]

wildcard        ::= "e*" ("X" | "Y")?

edge_cardinal   ::= "-"? "e" [1-4]

corner_index    ::= "-"? "c" [1-4]

space           ::= " "+

integer         ::= "-"? [0-9]+

cell_index      ::= integer "," integer

cell_range      ::= cell_index ":" cell_index

edge_segment    ::= cell_index "," edge_cardinal ":" cell_index "," edge_cardinal

entity_ref      ::= "<" space identifier space ("|" space predicate_list space)? ">"

value           ::= integer | name_stem

6 Canonical Orthography

This section is normative.

The canonical orthography defines the standard formatting conventions for RecPol source text. These rules ensure consistent, human-readable serialisation across different authoring environments. Building on the EBNF grammar that specifies what is syntactically valid, the canonical orthography specifies how valid expressions should be formatted for maximum human readability and cross-environment consistency. Therefore, canonical orthography compliance is a publication standard rather than a parser requirement; this implies that a non-canonically formatted expression may be syntactically valid but fails the human-readability property that the notation’s auditability obligations demand.

6.1 Case Sensitivity

• Verbs are case-insensitive: MakeShape, makeshape, and MAKESHAPE are equivalent.

• Namespaces are case-sensitive: s^, f^, i^ MUST be lowercase.

• Name Stems are case-sensitive: s^Box and s^box are distinct entities.

• Edge Cardinals are case-insensitive: e1 and E1 are equivalent.

This asymmetric case policy (case-insensitive for verbs and edge cardinals, case-sensitive for namespaces and name stems) therefore encodes a deliberate governance principle: the structural identity of entities must be unambiguous (hence case-sensitive namespaces), while the operational vocabulary used to manipulate them may accommodate typographic variation (hence case-insensitive verbs).

6.2 Whitespace Rules

1. Tokens MUST be separated by at least one whitespace character.

2. Canonical spacing: tokens SHOULD be separated by exactly one space, except where line breaks are used.

3. Indentation: use 3 spaces per nesting level. Tabs MUST NOT be used for indentation.

4. Trailing whitespace at the end of lines SHOULD be removed.

6.3 Formatting Conventions

Multi-line canonical form

< s^A |

   { MakeShape 1,1 : 2,2 } ;

   { EdgeRun 1,1,e1 : 2,1,e1 }

>

6.4 Numeric Literals

• Only decimal integers are supported. Hexadecimal, octal, and binary notation are NOT permitted.

• Negative integers use the minus sign with no space: -1 not - 1.

• Leading zeros are permitted but discouraged; canonical form uses minimal representation.

• Zero is prohibited in cell_index coordinates.

6.5 Identifier Naming Rules

• Namespace: is required to be exactly one character (s, f, or i).

• Caret: MUST be ^ (U+005E) with no surrounding whitespace.

• Name Stem: MUST match [A-Za-z0-9_]+; MUST begin with a letter or underscore; SHOULD use PascalCase for multi-word names (e.g., s^DiningTable).

6.6 String Literals

RecPol does NOT support quoted string literals. All identifiers and values are unquoted tokens. Therefore, the absence of string literals is a deliberate closure property: every token in a RecPol expression is either a keyword, an identifier, or a numeric value, and this implies that the token vocabulary is closed and exhaustively enumerable: a property that makes conformant parser implementation deterministic.

6.7 Comments

1. Single-line comments: Start with # and continue to end of line.

2. Multi-line docstrings: Enclosed in triple double-quotes """. These are treated as ignored comments, not string literals.

3. Comments can appear anywhere whitespace is allowed; they are treated as whitespace by the parser.

6.8 Reserved Characters

The following characters MUST NOT appear in name stems or unquoted values: < > { } ( ) | ; : , ^ # "

6.9 File Encoding

RecPol source files are required to be encoded in UTF-8 without BOM. Thus the encoding requirement is the final canonical orthography constraint that ensures cross-environment portability: together with the whitespace, formatting, and identifier rules, it establishes that a RecPol file authored in any conformant environment is byte-for-byte comparable with any other conformant file representing the same model.

7 Semantics: Primitive Plane (Shapes)

This section is normative.

The Primitive Plane is inhabited by Shapes: entities of invariant geometry. Shapes are the archetype layer: they define reusable, immutable geometric forms from which Forms are composed. The following verbs are available for s^ entities.

7.1 MakeShape

Declares the base rectangular polyomino geometry for a Shape.

• Syntax: { MakeShape cell_range }

• Semantics: Creates a solid rectangle of cells defined by cell_range within the Shape’s local bounding box.

• Constraints:

  • Must be the first (and typically the only) operation in a Shape definition.

  • The result must be spatially contiguous.

  • Geometric transformations (Position, Rotate, etc.) are not permitted within a Shape definition. They may only be applied to Shape references within Form definitions. This restriction ensures that Primitive Shapes remain pure, invariant archetypes unpolluted by contextual transformations: the Primitive Plane’s shapes are definitional, not situational.

• Side Effects: Defines the immutable geometry of the Shape entity.

< s^Box | { MakeShape 1,1 : 2,2 } >

7.2 MakeComposite

Fuses two shapes into a single contiguous shape by joining them along specified edge segments.

• Syntax: { MakeComposite shape_ref ; shape_ref }

• Semantics: Joins two Shapes along their specified edge segments to produce a new single-piece Shape. Each shape_ref must include an EdgeRun selector (see §7.3) specifying which edges to join.

• Constraints:

  • The specified edge segments must be of equal length.

  • Edge cardinals must be opposite: e.g., e1 (Left External) joined to e3 (Right External). This is the syntactic expression of the abutment compatibility rule from §3.4: an External-to-External join produces abutment.

  • The input Shapes must not overlap.

  • The result must be spatially contiguous.

• Side Effects: Defines the immutable geometry of the resulting Shape entity.

# Component primitives

< s^A | { MakeShape 1,1 : 2,3 } >

< s^B | { MakeShape 1,1 : 1,3 } >



# Fusion

< s^Fused |

  { MakeComposite

    < s^A | { EdgeRun 2,1,e3 : 2,3,e3 } > ;

    < s^B | { EdgeRun 1,1,e1 : 1,3,e1 } >

  }

>

7.3 EdgeRun

Selects a sequence of perimeter edges on a Shape, for use as a joining specification in MakeComposite.

• Syntax (cell-based): { EdgeRun x1,y1,eC : x2,y2,eC }: Clockwise, inclusive run from start edge to end edge.

• Syntax (index-based): { EdgeRun iStart : iEnd }: Indices refer to the Shape’s canonical clockwise perimeter walk order.

• Side Effects: Returns a set of oriented edges for use in a MakeComposite predicate.

The clockwise perimeter walk is defined to begin at the lexicographically smallest external edge and traverses the boundary until the loop closes. Index-based EdgeRun references are resolved against this canonical traversal sequence (visualised in the top panel of the perimeter-walk, edges-and-points, and corners figure above). Therefore, EdgeRun provides a position-independent referencing mechanism for boundary segments; this implies that joining specifications remain stable across shape translations and coordinate changes, a property that MakeComposite depends on to guarantee deterministic fusion outcomes.

8 Semantics: Configurative Plane (Forms)

This section is normative.

The Configurative Plane is inhabited by Forms: entities whose geometry is defined relationally: by the spatial relationships between their constituent members. Forms carry prespecified constraint rules (Latchment, Occupancy) that are encoded at the Configurative Plane but evaluated only when Instances of the Form interact on the Interactive Plane. The following verbs are available for f^ entities.

8.1 CallShape

Imports a Shape’s geometry as a member of the Form.

• Syntax: { CallShape shape_ref }

• Semantics: Adds the Shape’s cell geometry to the Form’s composition. The Shape reference must resolve to a valid s^ entity.

• Side Effects: Adds a new member to the Form’s composition.

< f^F | { CallShape < s^A > } >

8.2 MakeCompound

Groups multiple members into a single Form without geometric fusion. Members can be Shapes, Forms, or other references.

• Syntax: { MakeCompound member ; member ; ... }

• Semantics: Adds multiple members to the Form’s composition. Unlike MakeComposite, no edge-joining occurs: members retain their individual geometry and may be non-contiguous. This is the primary mechanism for assigning distinct constraint policies to different geometric parts of a single entity (for example, a physical body with strict latchment rules and a clearance zone with permissive occupancy rules).

• Side Effects: Adds multiple members to the Form’s composition.

< f^Group | { MakeCompound < s^A > ; < s^B > } >

8.3 Transformations (Local)

Local transformation verbs are applied in strictly left-to-right order and modify a member’s position or orientation within the Form’s bounding box. Transformations are non-commutative. The final Form is always resolved to canonical bounding box normalisation (bottom-left occupied cell at 1,1).

The strict left-to-right evaluation order is defined to eliminate transformation ambiguity and aligns with the serialised nature of RecPol: the expression { TransPosition ... } { TransPivot ... } unambiguously means “translate first, then rotate around the new local origin.” Thus the non-commutativity of local transformations is not a limitation but a governance feature; this establishes that any two authors applying the same transformation sequence to the same shape will produce identical results, making Form definitions reproducible across authoring environments.

< f^F | { CallShape < s^A | { TransPosition 2,2 } > } >

8.4 Constraints

Constraint verbs encode prespecified validity rules into a Form that are evaluated when Instances of the Form interact on the Interactive Plane. Constraints do not apply to the Form’s own internal composition: they are only evaluated when an Instance of this Form interacts with other Instances in the World Grid.

ConsLatchment. Defines latching rules for a specified edge segment within a given interaction lane.

• Syntax: { ConsLatchment x1,y1,eC : x2,y2,eC ; policy ; lanes }

• Policy values: 1 (Required: must latch), 0 (Allowed: may latch), −1 (Forbidden: must not latch).

• Rule: If any involved edge has policy −1, latching is forbidden at that edge. If an edge has policy 1, it must latch to something.

ConsOccupancy. Defines the overlap tolerance policy for the Form within a given interaction lane.

• Syntax: { ConsOccupancy policy ; lanes }

• Policy values: 1 (Empty: tolerates content), 0 (Partial: tolerates other partial), −1 (Full: tolerates only empty).

• Rule: Given two Forms A and B, overlap is valid if and only if policy(A) + policy(B) ≥ 0.

Occupancy arithmetic

Constraint Accumulation. Constraint predicates are additive. A Form may carry multiple ConsOccupancy or ConsLatchment predicates defining different policies for different lanes.

Constraint Evaluation (Conjunctive): Constraint evaluation is conjunctive: when two Instances interact, the system identifies their common lanes. The interaction is valid if and only if all constraints in every common lane are satisfied. Constraints in non-overlapping lanes are not evaluated. This lane-scoped evaluation operationalises selective constraint application: the physical body of a room and the clearance zone of a fixture can be governed by independent policies without mutual interference. Therefore, the conjunctive evaluation rule within lanes, combined with the independence of non-overlapping lanes, is the formal mechanism through which RecPol achieves interaction tractability at scale; this implies that adding a new constraint lane never invalidates existing evaluations in other lanes.

Attachment Geometry. The sign of the edge cardinal in ConsLatchment specifications determines vector orientation and join compatibility:

9 Semantics: Interactive Plane (Instances)

This section is normative.

The Interactive Plane is where abstract Forms are reified into concrete Instances. This is the plane where prespecified constraints (ConsLatchment, ConsOccupancy) are evaluated against actual placement and interaction in the World Grid. The following verbs are available for i^ entities.

9.1 CallForm / CallInstance

Instantiates a Form, or re-instantiates an existing Instance.

• Syntax (Form): { CallForm form_ref }

• Syntax (Instance): { CallInstance instance_ref }

• Semantics: Creates a concrete Instance entity in the Interactive Plane. The reference must resolve to a valid f^ Form or i^ Instance.

• Side Effects: Creates a new Instance entity; the Instance inherits the constraint policies of its underlying Form.

< i^I | { CallForm < f^F > } >

9.2 Transformations (Global)

Global transformation verbs modify the Instance’s placement in the World Grid. These are the final, concrete positioning operations that determine where the Instance occupies cells in the World Grid.

Global transformations preserve the Instance’s identity and constraint contracts: rotating an Instance changes its orientation in the World Grid but does not alter its underlying Form or the constraint policies derived from it. Thus global transformations are identity-preserving operations; this establishes that an Instance’s governance properties are invariant under placement and orientation changes, which implies that verification results computed for a Form remain valid regardless of how its Instances are subsequently positioned in the World Grid.

10 Generative Constraints

This section is normative.

While the core RecPol verbs (Sections 7-9) describe the actual state of entities (their geometry, composition, and placement) generative constraints define potential states by specifying what transformations are permitted during algorithmic generation and constraint validation.

Purpose: Generative constraints define the validity and exploration space for algorithmic layout generation, layout validation, and search space pruning.

Key distinction: Core verbs describe reality (“the entity is at position X”); generative constraints define possibility (“the entity may be placed within range R”). Therefore, the distinction between descriptive and generative constructs is structurally enforced in RecPol; this implies that a conformant parser can always determine whether a given expression describes an actual world state or defines an exploration space, without requiring contextual interpretation.

10.1 StretchFit (Adaptive Transformation)

StretchFit is a generative constraint that defines adaptive sizing based on the geometric features of another entity. It establishes a relational dependency in which an Instance’s dimensions are determined by another entity’s resolved geometry.

• Syntax: { StretchFit <entity_ref> ; edge_spec [; edge_spec]* }

• Semantics: Resolves the target entity in the World Grid; evaluates edge specifications in order until a valid match is found; calculates the length of the matched edge or segment; determines stretch axis automatically (horizontal edges → X axis; vertical edges → Y axis; point pairs → axis from pair orientation); stretches the current Instance to match the calculated length.

• Constraints: Target must be a placed Instance (has World Grid position); edge specifications must be axis-aligned; point pairs must be axis-aligned (diagonal pairs raise an error); if RangeStretch is present, the result must satisfy the range.

Edge specification types for StretchFit

When multiple edge specifications are provided, the first valid match is used; subsequent specifications serve as fallbacks.

# Point-to-point: stretch wardrobe to full room width

< i^Wardrobe |

  { CallForm < f^WardrobeUnit > } ;

  { Place 2,2 } ;

  { StretchFit < i^Room > ; p1 : p4 }

>

10.2 Range Constraints

Range constraints restrict the permissible parameter space for their corresponding transformation verbs. They are declarative specifications consulted by external generation and validation systems.

Range constraints are attached to Instances but are not evaluated during entity construction. They are consulted by external generation and validation systems when exploring the solution space.

RangeFit with dynamic target

< i^Room | { CallForm < f^BedroomShape > } ; { Place 1,1 } >



< i^Furniture |

  { CallForm < f^Chair > } ;

  { RangeFit < i^Room > }

>

When targeting an Instance reference, RangeFit is dynamic: the valid containment zone is defined by the target Instance’s actual resolved geometry, enabling adaptive layout specifications. Thus range constraints with dynamic targets make RecPol generative specifications responsive to the resolved world state; this establishes that layout generation algorithms operating over RecPol models can adapt to partial placements without requiring the full model to be resolved before any constraint can be evaluated.

11 Evaluation and Error Handling

This section is normative.

RecPol defines two conformance levels for error handling, addressing the different operational contexts of a compiler-level validator versus a runtime interpreter.

Strict Conformance (Compiler/Validator): Strict conformance requires that any syntax error, undefined reference, or construction rule violation (such as MakeComposite with mismatched edge lengths) causes evaluation to halt immediately. The system MUST report the specific error type and its location in the source. This is the conformance level for verification tools that check PlaniSyn representations against accessibility requirements.

Lenient Conformance (Runtime/Sandbox): Lenient conformance enables recoverable errors (such as overlapping Instances in a non-rigid simulation) to be logged as warnings rather than halting evaluation. Invalid entities SHOULD be treated as Null or Void without crashing the full world state. This conformance level is appropriate for exploratory generation environments. Therefore, the two-level conformance architecture allows RecPol to serve both rigorous verification contexts and exploratory generation contexts within a single language specification; this implies that tool developers select the appropriate conformance level based on their use context without requiring a separate language dialect.

Defined error codes

12 Relationship to the PlaniSyn Grammar

The RecPol specification documented here establishes the formal core of the planimetric notation architecture. It defines the complete language: its world model, entity types, formal grammar, canonical orthography, plane-specific semantics, generative constraint system, and conformance requirements.

The PlaniSyn Grammar (the PlaniSyn Grammar appendix) is the applied layer built over this formal core. Where RecPol specifies what constitutes a syntactically and semantically valid expression, PlaniSyn Grammar specifies how those expressions are used in the specific domain of accessible dwelling plan representation: the object model aligned to the nine SDA module types, the naming conventions for dwelling-specific identifiers, the three-level nesting hierarchy corresponding to the planimetric triad, and the interaction type vocabulary aligned to the module boundary contracts of Chapter 6.

The architectural separation is analogous to the standard two-layer organisation of formal language specifications: a base language specification (RecPol) that is domain-agnostic, and a domain profile (PlaniSyn Grammar) that restricts and extends the base language for a specific application context. RecPol’s Axiom 4 (Context-Free) and Axiom 5 (Modular) are properties of the base language; the PlaniSyn Grammar’s module type vocabulary and interaction type semantics are properties of the domain profile. Neither layer is redundant: the base language provides the formal tractability and governance-capable parsing properties that the domain profile inherits; the domain profile provides the semantic grounding in accessibility requirements, module interaction rules, and verification sequence constraints that the base language cannot specify without domain knowledge. Therefore, the RecPol specification is the normative foundation that any future domain profile, beyond the PlaniSyn Grammar documented in the PlaniSyn Grammar appendix, must conform to, and this establishes that the language architecture is extensible to new domains without requiring modification of the formal core.

Together, the two appendices document the complete notation specification, the planimetric notation system, at both the formal and applied levels.

1 Purpose and Scope

The foundational technical specification for the PlaniSyn notation system is provided here, as developed in this thesis. PlaniSyn is a text-based planimetric notation format through which building spatial arrangements are encoded as governed, inspectable, and transportable text representations. It constitutes the grammar layer of the notation of the thesis’s design science research suite: the full development and theoretical grounding of which is presented in Chapter 7.

The PlaniSyn system was initially designed and documented at the Confirmation of Candidature stage. Four representational properties were identified as absent from existing floor plan formats: explicitness of spatial relations, discreteness of boundary conditions, support for hierarchical decomposition, and transportability across tools and actors. PlaniSyn was established as the primary vehicle for achieving these properties. The specification here is the technical documentation of that system as developed through the research, integrated with the thesis’s theoretical commitments to modular representational governance.

The notation conforms to the representational substrate established in Chapter 3 §3.3. All spatial relations are encoded as explicit directed assertions. Encoding units are governed by the discreteness and composability of the text medium. The hierarchical structure mirrors the near-decomposable structure that §3.3 identifies as a necessary condition for tractable interface governance.⁷ The object model is directly aligned with the nine module types specified in Chapter 6. PlaniSyn expressions can thereby be parsed and evaluated against the module-level verification contracts established in that chapter.

The specification is organised as follows. Section 2 establishes the foundational spatial model on which the notation rests: the orthogonal discrete planimetric world and its structural properties. Section 3 presents the three-layer system architecture. Sections 4 through 8 specify the individual notation components in full technical detail: the tag grammar (4), the object model (5), spatial primitives including perimeter, border, and anchors (6), openings and segments (7), and the four interaction types (8). Section 9 documents the hierarchical nesting mechanism and its correspondence to the planimetric triad levels established in the literature review. Section 10 provides the complete formal syntax reference with canonical examples. Section 11 positions this grammar specification relative to the RecPol formal core specified in the RecPol Specification appendix and clarifies the architectural relationship between the two complementary specification layers.

2 The Orthogonal Discrete Planimetric World

PlaniSyn operates on a discretised spatial model in which all positions are quantised into fundamental units called modules. Modules occupy unique positions on a two-dimensional grid formed by two perpendicular axes, creating a structured environment without gaps or overlaps. This orthogonal discrete world is the enabling condition for the governance properties that distinguish PlaniSyn from continuous drawing-based representations and from parametric modelling environments in which spatial relations are embedded in proprietary data structures rather than explicitly declared.

Three properties of the discrete model are architecturally consequential for the notation system. In summary, the orthogonal discrete world provides the formal spatial substrate through which PlaniSyn achieves the governance properties that continuous drawing formats cannot deliver. Three specific properties are documented below. Exact addressability, a closed directional basis, and structural congruence with modularity each contribute to the notation’s representational governance. This establishes that the choice of a discrete spatial model is not an implementation convenience but a necessary condition for the governance properties the system is required to deliver.

Exact addressability: Each module is identified by integer grid coordinates, making every positional reference deterministic rather than scale-dependent or convention-relative. Unlike continuous drawing formats in which spatial relationships depend on resolution, rendering scale, and graphical convention, PlaniSyn positional assertions are unambiguous and encoding-independent: a perimeter movement of N10 specifies exactly ten module units northward regardless of any display or rendering environment. This property satisfies the discrete, finitely differentiated character that Goodman’s notational theory requires for a system to achieve the semantic disjointness that governance-capable representation demands.⁸

Closed directional basis: The four cardinal directions (North, South, East, West) are defined to constitute a complete directional basis for perimeter specification in an orthogonal system. Because the spatial model admits no non-orthogonal positions, the movement basis is closed: any valid perimeter in the PlaniSyn world is expressible as a finite sequence of N/S/E/W movements over integer module distances. This closure property makes the grammar of perimeter specification decidable, there is no open-ended positional vocabulary that could escape enumeration, and ensures that any two PlaniSyn perimeter expressions are directly comparable without conversion or interpretation.

Structural congruence with modularity: Discretisation at the module level provides the spatial substrate for the interaction differential required by the modularity axioms established in §3.3: module boundaries can be precisely located at grid lines rather than being fuzzy spatial zones requiring interpretive reconstruction. The interaction differential measured across the nine module types in §6.3, ranging from 13.2 to 34.1, is empirically grounded in the SDA clause corpus, but its spatial instantiation in PlaniSyn representations depends on the orthogonal discrete model providing exact boundary locations. In a continuous geometric world, the boundary between a circulation module and an adjacent sanitary module would be a line of indeterminate thickness requiring explicit wall-specification conventions; in the discrete grid, the boundary is an edge between adjacent module-units, exactly locatable and unambiguously belonging to one or the other object.

Polyominoes, shapes formed by connecting one or more modules edge-to-edge, are the inhabitants of the discrete planimetric world. The PlaniSyn object model encodes spatial arrangements as governed compositions of these objects. Identities, boundaries, openings, and interaction relationships are explicitly declared for each. At the architectural scale at which accessible dwelling plans are specified, rooms and spaces correspond to rectangles or L-shaped polyominoes; furniture and fixtures correspond to smaller rectangular or single-module polyominoes nested within the enclosing spaces. Overall, the orthogonal discrete planimetric world provides the formal precondition for every governance property that PlaniSyn subsequently instantiates: determinism, comparability, and exact boundary localisation all derive from the discrete spatial model. The next section documents the three-layer system architecture that organises these properties into a coherent notation infrastructure. Thus the spatial model and the architectural layers are not separable design choices: the former is the precondition without which the latter cannot achieve its governance obligations.

3 System Architecture

The PlaniSyn notation system is organised into three functional layers that together constitute a complete representational infrastructure for planimetric spatial description. The three-layer organisation mirrors the three planes of the Planimetric System established in Chapter 2 and the three interface types specified in the module interaction rules of Chapter 6.

The declaration layer is defined to specify the identity, geometry, and properties of individual objects. Every entity in a PlaniSyn representation is declared through a bracketed expression that assigns it a unique identifier and specifies its spatial extent, boundary properties, access conditions, openings, and anchor constraints. Declaration expressions are structurally self-contained: all information required to parse and verify a declared object is contained within its declaration bracket. This property directly instantiates the information-hiding principle of modular systems: what an external actor needs to know about an object is expressed by its declaration; interior elaboration is decoupled from its boundary specification.⁹

The interaction layer is defined to govern the relationships between declared objects. Interactions are typed (four distinct interaction types are specified in section 8, each encoding a different geometric and operational relationship) and explicitly declared using the action tag syntax. An object’s interaction declarations are syntactically separable from its internal declaration. This separation preserves the modularity principle in the notation architecture: knowing the internal specification of an object does not reveal its interaction relationships, and knowing its interaction relationships does not require reading its full internal specification.

The composition layer is defined to organise objects into hierarchical assemblies through the nesting mechanism described in section 9. Objects at any scale in the spatial hierarchy, from individual fixtures to rooms to dwelling aggregates, can be composed as nested structures, enabling the fractal-like recursive organisation that mirrors Simon’s near-decomposable hierarchy.¹⁰ The composition layer allows the notation system to represent the full dwelling as a structured assembly of modules, each internally specified and externally governed through declared interfaces. Taken together, the three layers (declaration, interaction, and composition) constitute a complete and internally consistent representational infrastructure: the declaration layer ensures identity and geometry, the interaction layer ensures relational governance, and the composition layer ensures hierarchical tractability. Therefore, this three-layer architecture is the formal realisation of the near-decomposable structure that the thesis’s theoretical framework identifies as a necessary condition for tractable interface governance. The next section specifies the tag grammar through which these three layers are syntactically instantiated in text, and thus the tag grammar is the point where the abstract architectural commitments become concrete, inspectable notation elements.

4 Tag Grammar

The PlaniSyn notation system is defined by seven distinct tag types, each with a precisely defined syntactic role and semantic function. The tag grammar is the formal mechanism through which the three-layer architecture is syntactically instantiated in text. Together, the seven tag types constitute a complete notational apparatus for encoding spatial declarations, inter-object interactions, prerequisite conditions, geometric transformations, parameter separation, parameter identification, and value assignment.

4.1 Declaration Tag < >

The declaration tag encloses the full specification of a PlaniSyn object. It marks the beginning and end of an object declaration, with its internal content partitioned by class separators (|) into defined parameter positions.

General form: <OBJECT_ID|PERIMETER|BORDER|ACCESS|OPENING|ANCHOR>

Function: Defines an object’s identity, spatial extent, boundary conditions, access state, openings, and anchor constraints as a single, atomically parseable unit. The declaration tag is the primary syntactic construct of the declaration layer; every entity in a valid PlaniSyn expression must be introduced through a declaration tag expression before it can appear in interaction or composition expressions.

4.2 Action/Iteration Tag { }

The action tag encloses interactions between objects or iterative processes applied to sequences of objects.

General form: <OBJECT_ID>{INTERACTION} or <PARENT>{<CHILD>} for nesting declarations

Function: Declares the type and target of an inter-object relationship, or encloses nested child objects within a parent declaration. The action tag is the primary syntactic construct of both the interaction layer and the composition layer. When used for interactions, the enclosed content identifies the interaction type and the target object. When used for nesting, the enclosed content is itself a complete object declaration, enabling recursive composition.

4.3 Prerequisite Value Tag [ ]

The prerequisite value tag encloses values or conditions that must be satisfied before a parameter or interaction is treated as valid.

General form: P [int] or {INTERACTION}[<TARGET_OBJECT>]

Function: Specifies necessary conditions on parameter values (cardinality constraints, value type requirements, or conditional validation constraints) and identifies target objects in interaction declarations. The prerequisite notation makes validation conditions explicit within the expression itself rather than leaving them implicit in parsing conventions. In interaction declarations, the prerequisite tag encloses the target object whose declaration must be satisfied as a condition of the interaction’s validity.

4.4 Transformation Tag ( )

The transformation tag encloses transformation parameters or functions that modify an object’s geometric orientation or scale.

General forms: (ROTATE 90), (SCALE 2)

Function: Specifies admissible geometric transformations (rotation about a pivot point in multiples of 90 degrees, consistent with orthogonal system constraints, or uniform scaling by an integer factor in module units) without altering the object’s declared identity or interaction contracts. Transformation declarations are syntactically separable from the object’s base declaration, operationalising the transformation interface governance principle from §3.3: the object’s what (identity and composition) is unchanged by a geometric transformation; only its orientation or scale is modified.

4.5 Class Separation Tag |

The class separator partitions the internal components of a declaration expression into their defined parameter positions.

Function: Ensures correct parsing and semantic interpretation by making the boundaries between object identifier, perimeter specification, border specification, access state, openings specification, and anchor constraints unambiguous within a single declaration bracket. The separator constitutes the syntactic realisation of parameter-class boundaries within a declaration: analogous to the class boundary markers in strongly typed data specifications, where each field slot carries a distinct semantic type that cannot be mixed with adjacent fields.

4.6 Capital Parameter Tag

Uppercase identifiers designate named parameters within declarations. These carry specific properties and parsing constraints that distinguish them from variable-value tokens.

Examples: P (perimeter), B (border), D (door), A (access), O (openings), An (anchors)

Function: Identifies the category of information being specified, enabling parsers to route each token to its correct semantic handler without requiring positional disambiguation beyond the class separator boundaries. Capital parameter tags correspond to the stable, typed parameter positions in the declaration schema: their meaning is fixed by the grammar specification and does not vary by instance.

4.7 Lowercase Variable Tag

Lowercase identifiers designate variable values associated with named parameters: instance-specific data tokens that hold the concrete values for a given object declaration.

Examples: n10 (perimeter movement: 10 modules north), e8 (perimeter movement: 8 modules east), module_size, color

Function: Holds instance-specific values linked to the enclosing capital parameter, maintaining the structural separation between the parameter’s identity (what type of thing is being specified) and its instantiated value (what that thing’s value is for this particular object). The lowercase convention provides a visual parsing aid in addition to its syntactic role: human readers can immediately distinguish parameter labels from their values without additional annotation. Therefore, the seven tag types together form a self-consistent notational vocabulary in which syntactic form encodes semantic category: a property that makes PlaniSyn expressions auditable by inspection without requiring a separate schema document.

5 Object Model

Objects are the fundamental entities of the PlaniSyn system. An object represents any spatial or physical entity in a planimetric description: ranging from physical infrastructure elements (walls, doors, windows, grab rails) to enclosed spatial zones (rooms, corridors, outdoor areas) to dwelling aggregates. Objects carry no inherent type in the base grammar: they are what their declarations specify them to be. However, in the context of this thesis’s SDA accessible housing application, the nine module types established in Chapter 6 §6.3 (ENT, CIR, SAN, BED, LIV, KIT, SVC, EXT, DWL) provide the governed type vocabulary from which object identifiers are drawn. Object identifiers that correspond to module type designations inherit the constituent element specifications and interaction rule contracts defined for those types.

The general object declaration structure is:

<OBJECT_ID | P: <perimeter> | B: <border> | A: <access_state> | O: <openings> | An: <anchors>>

Each parameter position in the declaration is specified in the following table:

Object identifiers carry stable referential identity: each identifier names the same spatial entity consistently across all references to that object within the representation, enabling deterministic comparison across representation versions, cross-module reference without duplication, and version-tracked modification histories. This identity property is the PlaniSyn instantiation of the source-node requirement of the trigram structure established in §3.3: a named object in a PlaniSyn expression is the source node of all relations declared for it, and its identity persists regardless of any transformation, scaling, or positional modification applied to its geometric specification. Overall, the object model establishes stable referential identity as the foundational property that makes PlaniSyn representations auditable and version-comparable: a prerequisite for the governance-capable spatial representation that the thesis’s design science artefacts require. This establishes that object identity is not a naming convention but a structural commitment: every reference to the same spatial entity must resolve to the same declared object regardless of context, transformation, or revision history.

6 Spatial Primitives: Perimeter, Border, and Anchors

6.1 Perimeter Specification

The perimeter defines the outer spatial boundary of an object as a closed loop of directional movements from a declared anchor origin. The movement basis for orthogonal discrete space comprises four cardinal directions:

Each directional movement is followed by an integer value specifying the distance in module units. A perimeter specification is a sequence of such movement-distance pairs that trace a closed boundary when traversed in order from the anchor origin: the final movement in the sequence must return the trace to its starting grid position for the perimeter to be well-formed.

Example: P:N10 E8 S10 W8 specifies a rectangular perimeter (10 modules north, 8 east, 10 south (returning to the original northing), 8 west (closing to the anchor origin)) yielding a 10 × 8 module rectangle.

More complex non-rectangular perimeters are expressed as longer movement sequences:

Example (L-shaped perimeter): P:N10 E8 S6 W4 S4 W4 traces an L-shaped boundary (10 north, 8 east, 6 south, 4 west, 4 further south, 4 west) returning to the anchor origin to produce an L-shaped polyomino.

The closed-loop requirement is a well-formedness constraint on the perimeter grammar: any perimeter expression that does not return to its starting position is syntactically invalid and will be rejected by a conformant PlaniSyn parser. Overall, the perimeter specification provides a complete and deterministic description of an object’s outer spatial extent using the same directional vocabulary throughout, and this implies that a single positional reference system suffices for all boundary-description tasks in the notation. The next section specifies the border parameter, which extends this boundary description to include the structural layer between perimeter and accessible interior. Thus the perimeter and border specifications are complementary: the perimeter defines the outer extent of governance, and the border defines the accessible interior within which nested objects and interactions are subsequently validated.

6.2 Border Specification

The border defines an internal offset from the declared perimeter, representing the structural boundary layer of the object. In architectural representations, the border corresponds to wall thickness: the zone between the object’s outer boundary (the perimeter) and its accessible interior. In abstract spatial zone representations, the border may represent a minimum clearance margin.

Example: B:1 specifies a one-module border inset from all perimeter edges. The accessible interior of the object (the region available for placement of nested objects, fixtures, and activities) is the total perimeter area minus all border zones.

A border value of 0 specifies that the object has no structural boundary layer: its interior extends to the full perimeter extent. This is appropriate for abstract zone representations and for surface-anchor objects that occupy a region within a containing space without having their own wall structure.

6.3 Anchor Specification

Anchors are positional constraints that locate objects within the spatial hierarchy: they specify where in the grid (or relative to another object) the object’s perimeter origin is placed. Three anchor types address the three spatial positioning relationships an object may have with its containing environment:

Point Anchor. Positions the object at a specific integer grid coordinate pair (x, y). The object’s perimeter trace begins at the designated point anchor coordinate, with all subsequent directional movements computed from that origin.

Function: Establishes absolute spatial position for objects that occupy fixed locations in the planimetric layout. Appropriate for primary structural objects (dwelling boundary, site boundary) whose position is defined in absolute grid terms.

Edge Anchor. Anchors the object relative to a named edge of another object or the enclosing grid boundary. The anchored object’s perimeter aligns with the specified edge, enabling wall-aligned placement without requiring explicit coordinate calculation.

Function: Supports interface adjacency declarations consistent with the bilateral interface adjacency constraint in §6.3. An ENT module object can be edge-anchored to an EXT module boundary, declaring that the entry’s spatial origin aligns with the outer boundary without requiring the author to manually compute the absolute coordinates of that boundary.

Surface Anchor. Anchors the object to a named interior region within another object, used for objects that occupy a position inside a containing space rather than being positioned along its perimeter.

Function: Operationalises the placement of furniture, fixtures, and sub-components within containing rooms and spaces: the primary anchoring mechanism for objects at the primitive plane of the nesting hierarchy (section 9). Surface anchors reference a named corner, zone, or position within the interior of the enclosing object’s declared perimeter.

Examples: An:SE_CORNER, An:NW_CORNER, An:CENTRE

7 Openings and Segments

7.1 Opening Specification

Openings are perforations within an object’s boundary that enable spatial connectivity between adjacent objects. Openings represent doors, windows, passages, and any traversable throughway. They are declared as part of the object’s own declaration (in the O: parameter position), and their positions are specified using the perimeter’s directional structure as a positioning reference system.

Each opening declaration specifies four properties:

The interaction property of an opening, how it connects with an adjacent object’s opening, is not declared within the opening specification itself but is governed by the Coupling interaction type (section 8.2) declared at the interaction layer. This separation maintains the architectural distinction between an object’s internal specification (what openings it has) and its external interaction declarations (how those openings connect to the openings of other objects). In summary, the opening specification encodes the access topology of a PlaniSyn object as a first-class declaration, making the connectivity structure of a spatial layout auditable independently of its geometric specification. Therefore, access topology is a governed property of the notation, not an inferred consequence of geometric proximity, and this implies that two representations with identical perimeters but different opening declarations describe fundamentally different spatial objects.

Example: O:D1@W3 specifies Door 1 positioned 3 modules along the west perimeter segment.

Example (multiple openings): O:D1@W3;D2@N5 specifies Door 1 at 3 modules west and Door 2 at 5 modules north.

The @<segment><distance> positioning convention uses the same directional notation as the perimeter grammar, maintaining a single positional reference system throughout the notation. This consistency property is an important usability feature of the grammar: authors who understand the perimeter specification need no separate positional vocabulary to specify opening placement.

7.2 Segment Specification

Segments divide an object’s perimeter into named sections, enabling differentiated treatment of distinct boundary portions. A room object may have perimeter segments with different structural properties (load-bearing wall, non-structural partition, full-height glazing), different constraint conditions (a segment prohibited from bearing openings due to structural or acoustic requirements), or different governance obligations (a segment shared with an adjacent module that requires bilateral declaration).

Segments are declared as modifiers on perimeter movement tokens using a segment identifier suffix. The primary applications of segments in the PlaniSyn system are:

1. Boundary type specification: identifying different wall types or construction systems on distinct faces of an object, carrying implications for structural constraint and opening placement eligibility.

2. Opening constraint declaration: explicitly marking segments as OPEN_ELIGIBLE or OPEN_PROHIBITED, making the placement constraints on each face of the object visible in the notation without requiring a separate constraint specification document.

3. Interface identification: marking segments that are shared with adjacent objects, providing the syntactic basis for the bilateral interface adjacency constraint in §6.3. When Module A declares that its northern segment is the interface with Module B, and Module B declares that its southern segment is the interface with Module A, the bilateral declaration can be verified directly in the notation without geometric interpretation.

Segments operationalise the semantic interface contract requirement that shared boundary entities be identifiable as the same entity from both sides of a module boundary. A segment identifier applied to a perimeter movement token provides the named boundary element that both modules reference: without segment naming, boundaries are geometrically adjacent but semantically anonymous, making bilateral verification impossible in the notation layer. Thus segment naming is the mechanism through which the notation achieves the bilateral interface adjacency property: it transforms a geometric coincidence into a declared, verifiable shared boundary identity.

8 Interaction Types

The PlaniSyn system specifies four typed interaction declarations governing the spatial relationships between objects. Interaction typing is the mechanism by which the notation achieves the explicitness property that distinguishes it from geometric drawing: where a drawing can only show that two objects are spatially proximate, a typed PlaniSyn interaction declaration states precisely how two objects are related: their geometric relationship, their connectivity status, and the directional or hierarchical character of their association.

Interactions are declared in the action tag, with the target object enclosed in the prerequisite value tag:

General form: <OBJECT_A>{INTERACTION_TYPE}[<OBJECT_B>]

8.1 Engaging

Engaging is a symmetrical adjacency interaction. Two objects engage when their respective perimeters share a common boundary segment: they are spatially adjacent along a defined edge. The engaging interaction is unconditionally bidirectional: if A engages B, then B engages A, and both declarations must be present in a well-formed representation for the adjacency to be validated. No traversal is implied; engaging objects are spatially adjacent but not necessarily connected through openings.

Architectural instantiation: Two rooms sharing a party wall engage. A circulation module sharing a boundary with an adjacent sanitary module engages at that shared boundary. The engaging interaction is the declaration that makes wall-sharing explicit and verifiable in the notation: without it, two objects with geometrically aligned perimeters are merely proximate, not structurally related.

Declaration form: <ROOM_A>{ENGAGE}[<ROOM_B>]

This establishes that physical adjacency between modules is never implicitly inherited from geometric placement: it must always be declared, and therefore the absence of an Engaging declaration is a verifiable governance condition, not an ambiguous omission.

8.2 Coupling

Coupling is a symmetrical connection interaction via aligned openings. Two objects couple when they each carry an opening declaration at a compatible position and orientation, and those openings are declared as the connection point between the objects. Coupling presupposes that both objects have declared openings of compatible sizing and placement at their shared boundary segment.

Architectural instantiation: A bedroom module (BED) and a circulation module (CIR) couple through a door opening. A dwelling entry (ENT) and circulation hub (CIR) couple through the primary entry door. The coupling interaction is the PlaniSyn encoding of the connected-interface relationships between module types specified in §6.3: ENT-CIR, CIR-SAN, CIR-BED, CIR-LIV, and CIR-KIT boundary pairs are all instantiated as coupling interactions in valid dwelling representations.

The symmetry of coupling reflects the bilateral declaration requirement: both objects must declare compatible openings for a coupling to be valid. A coupling declared from A to B but with no corresponding compatible opening declared in B is a well-formedness violation. This constraint is the PlaniSyn implementation of the interface adjacency constraint from §6.3: cross-module connections cannot be asserted unilaterally.

Declaration form: <OBJ_A>{COUPLE}[<OBJ_B>]

Therefore, the coupling interaction is the primary mechanism through which the module connection rules established in Chapter 6 are instantiated as verifiable notation constraints: a coupling declaration that cannot be matched by compatible openings on both sides is a well-formedness failure, not a warning.

8.3 Entangling

Entangling is 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. The asymmetry is intrinsic: the entangling object (A) is the connecting element; the host object (B) is the containing environment that A penetrates. The entangling relationship is not reversible: B does not entangle A.

Architectural instantiation: A structural column element whose footprint pierces the perimeter of a containing room and occupies a position within its interior without being nested as a conventional contained object. A building services riser that connects through the wall plane of a circulation module into the module’s accessible zone. Entangling is used where a component does not conform to the full containment model of nesting (section 9) but establishes a directed connection that modifies the host object’s interior properties.

Declaration form: <COLUMN_01>{ENTANGLE}[<ROOM_A>]

Thus entangling handles the class of physical relationships that cannot be expressed as either symmetrical adjacency or full containment; this implies that without the entangling interaction type, any component that penetrates a containing boundary without fully nesting within it would be unrepresentable in a governance-compliant notation.

8.4 Encasing

Encasing is 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 spatial extent. The encasing relationship is directed: the enclosing object (A) encases the enclosed object (B); B does not encase A.

Architectural instantiation: A building object encases its constituent room objects. A dwelling site encases the building. The DWL module encases all space-specific module instances in its scope. Encasing is the interaction-layer complement to the nesting mechanism described in section 9: it is the explicit interaction declaration that makes a spatial containment relationship verifiable through the notation rather than merely inferred from geometric overlap. An object may be geometrically within another object’s perimeter without that containment being governed; the encasing declaration is what makes the containment explicit and subject to interface contract enforcement.

Declaration form: <BUILDING_01>{ENCASE}[<ROOM_A>]

Therefore, the encasing declaration is the explicit governance complement to the nesting mechanism: nesting establishes the compositional structure syntactically, while encasing declares the containment relationship as a verifiable interaction contract that both parties acknowledge at the notation level.

9 Hierarchical Nesting (Nesty)

Nesty is the PlaniSyn mechanism for hierarchical spatial composition: objects can be nested within other objects, with the child object declared within the action tag of the parent. The result is a parent-child structure that encodes the spatial hierarchy of the planimetric arrangement (rooms within dwellings, fixtures within rooms, sub-modules within modules) in a form that is both syntactically explicit and structurally recursive.

Nesting syntax

<PARENT_OBJECT|P:...|B:...|A:...|O:...|An:...>{<CHILD_OBJECT|P:...|B:...|A:...|An:...>}

Nesting is recursive: a nested child object may itself contain nested objects within its own action tag, producing a spatial hierarchy of arbitrary depth. The full expression of a complex accessible dwelling plan is a multi-level nested structure of PlaniSyn declarations, with each level corresponding to one plane of the planimetric triad.

The correspondence between the three nesting levels and the three planes of the Planimetric System established in Chapter 2 is as follows:

This three-level correspondence is architecturally significant for two reasons. First, it means that the PlaniSyn nesting hierarchy directly encodes the verification sequence constraint established in §6.3: the sequence primitive → configurative → interactive forms the structural ordering of the nesting levels. A L2 object cannot be fully parsed without its L1 contents; the DWL module cannot be evaluated without its L2 module instances. The grammar thus enforces the verification sequence as a structural property of the notation itself.

Second, the three-level hierarchy is the spatial instantiation of near-decomposability.¹¹ At each nesting level, the interactions within a level substantially exceed the interactions crossing to the enclosing or enclosed level: the within-module interaction differentials measured in §6.3 confirm this empirically across all 12 active module-pair boundaries. The Nesty mechanism makes this hierarchy representationally explicit: rather than inferring the compositional structure from spatial proximity in a drawing, the PlaniSyn nesting syntax makes the hierarchy an observable, parseable property of the notation.

Constraint property of enclosing objects. The enclosing object’s perimeter constitutes a geometric constraint on all nested children: no child object’s spatial extent may exceed the interior of the enclosing object’s perimeter minus the border offset. This constraint is enforced at the grammar level: a child object whose perimeter expression would place it outside the containing object’s interior is a well-formedness violation. This property eliminates the class of representation errors in which a nominally contained element is encoded as falling outside its container, without requiring a separate spatial intersection calculation. Thus the Nesty mechanism converts hierarchical spatial containment from an interpretive convention into a structurally enforced, grammar-level property; this implies that no valid PlaniSyn expression can represent a spatially inconsistent nesting relationship.

10 Formal Syntax Reference

The complete PlaniSyn notation syntax is presented below as a formal reference schema for implementation and validation purposes.

10.1 Core Grammar

Object declaration

<ID | P: <perimeter> | B: <border_int> | A: <access_state> | O: <openings> | An: <anchors>>

Perimeter

<perimeter>   ::= <movement>+

<movement>    ::= ( 'N' | 'S' | 'E' | 'W' ) <int>

where <int> is a positive integer in module units; the sequence of movements must form a closed loop returning to the perimeter origin.

Access state

<access_state> ::= 'open' | 'closed' | 'conditional'

Opening

<opening>     ::= <opening_id> '@' <direction> <int>

<opening_id>  ::= 'D' <int>   (door)

               |  'W' <int>   (window)

               |  'P' <int>   (passage)

Multiple openings are separated by semicolons: O:D1@W3;D2@N5

Anchor

<anchor>      ::= '(' <int> ',' <int> ')'            (point anchor: grid coordinates)

               |  <obj_id> '.' <direction>            (edge anchor: named object, named edge)

               |  <obj_id> '.' <zone_id>              (surface anchor: named object, named zone)

10.2 Interaction Grammar

<interaction>      ::= '<' <obj_id> '>' '{' <interaction_type> '}' '[' '<' <obj_id> '>' ']'

<interaction_type> ::= 'ENGAGE' | 'COUPLE' | 'ENTANGLE' | 'ENCASE'

10.3 Nesting Grammar

<nested_expr> ::= '<' <obj_decl> '>' '{' <obj_decl>+ '}'

Nesting is recursive; <obj_decl> may itself be a <nested_expr>.

10.4 Transformation Grammar

<transform>   ::= '(' 'ROTATE' <int> ')'    (rotation in degrees; must be multiple of 90)

               |  '(' 'SCALE' <int> ')'     (uniform scaling factor; positive integer)

10.5 Canonical Examples

Single accessible room: BED module

<BED_01 | P:N10 E8 S10 W8 | B:1 | A:closed | O:D1@W3 | An:(0,0)>

Decoded: Object BED_01; perimeter 10×8 module rectangle (orthogonal closed loop); 1-module wall border; access only via declared openings; Door 1 at 3 modules along the west segment; point-anchored at grid origin.

Nested composition: room containing fixtures

<BED_01 | P:N10 E8 S10 W8 | B:1 | A:closed | O:D1@W3 | An:(0,0)>

  {<FIXTURE_01 | P:N3 E2 S3 W2 | B:0 | A:open | An:BED_01.SE_CORNER>}

  {<FIXTURE_02 | P:N3 E2 S3 W2 | B:0 | A:open | An:BED_01.NW_CORNER>}

Decoded: BED_01 (10×8 room) contains two fixtures: each a 3×2 module footprint, no structural border (open elements), surface-anchored to declared corner zones within BED_01’s interior.

Coupling interaction: bedroom connecting to circulation

<BED_01 | P:N10 E8 S10 W8 | B:1 | A:closed | O:D1@W3>

{COUPLE}[<CIR_01 | P:N4 E12 S4 W12 | B:1 | A:open | O:D1@E3;D2@E9>]

Decoded: BED_01 couples with CIR_01 through their respective Door 1 declarations. Both objects must declare compatible opening positions for the coupling to be valid: BED_01’s D1@W3 must align with CIR_01’s D1@E3 in the assembled layout.

Rotation transformation

(ROTATE 90) <BED_01 | P:N10 E8 S10 W8 | B:1 | A:closed | O:D1@W3>

Decoded: BED_01’s perimeter and all its declared internal elements are rotated 90 degrees. All declared interactions and openings rotate with the object; the object’s identity (BED_01) and interaction contracts are unchanged by the transformation.

Three-level nested dwelling fragment

<DWL_01 | P:N30 E20 S30 W20 | B:2 | A:closed | An:(0,0)>

  {<BED_01 | P:N10 E8 S10 W8 | B:1 | A:closed | O:D1@W3 | An:DWL_01.NE_ZONE>

    {<FIXTURE_01 | P:N3 E2 S3 W2 | B:0 | A:open | An:BED_01.SE_CORNER>}

  }

  {<CIR_01 | P:N4 E12 S4 W12 | B:1 | A:open | O:D1@E3;D2@E9 | An:DWL_01.CENTRAL_ZONE>}

  {COUPLE}[<BED_01>{COUPLE}[<CIR_01>]]

Decoded: DWL_01 is a 30×20 module dwelling with 2-module border; it contains BED_01 and CIR_01 as L2 module instances, with BED_01 in turn containing FIXTURE_01 as an L1 primitive; the coupling interaction between BED_01 and CIR_01 is declared at the L3 dwelling level as a cross-module interaction. Therefore, the canonical examples collectively demonstrate that the full expressive range of the notation, from single primitives to multi-level dwelling aggregates, is captured within the same consistent syntactic framework, and this implies that practitioners and validators share a single normative reference regardless of the representational complexity they encounter.

11 Relationship to the RecPol Formal Core

The specification in this appendix documents the PlaniSyn notation system at the level of its object model, tag grammar, and compositional mechanics: the applied layer of the notation architecture. This corresponds to section 7.5 of Chapter 7’s theoretical treatment.

The RecPol specification (the RecPol Specification appendix) documents the formal core underlying the PlaniSyn applied layer: the complete formal grammar in Extended Backus-Naur Form (EBNF), the production rules governing what constitutes a syntactically valid PlaniSyn expression, the formal semantic assignments mapping grammatical constructs to their governed meanings, and the parsing algorithm that transforms a PlaniSyn text expression into the directed labelled graph structure established as the representational substrate in §3.3.

The distinction between the applied layer and the formal core mirrors the standard architectural separation in formal language design: the applied layer provides the intuitive notation surface that practitioners use directly in authoring accessible dwelling plans, while the formal core provides the mathematical foundation that PlaniSyn-conformant parsers, validators, and tool developers implement. Both layers are required for the system to simultaneously achieve practitioner-accessibility and formal governability.

In concrete terms, the present appendix answers the practitioner question: what do I write, and what does it mean? The RecPol specification answers the implementer and verifier question: what is a valid expression, and how are its constructs formally assigned their semantic interpretations under the governance model? The governance model (in which semantic interface contracts, transformation interface contracts, and verification interface contracts jointly enforce the modular interaction rules of Chapter 6) is operationalised in the PlaniSyn encoding through the interaction types (section 8), the segmentation mechanism (section 7.2), and the nesting hierarchy (section 9). The RecPol specification formalises the conditions under which those operationalisations are correct.

The RecPol specification is documented at its current normative level (Version 6.0), and the PlaniSyn grammar in this appendix is the applied layer built over it. Together they constitute the operational specification of the notation system as implemented and evaluated in the demonstration cases presented in Chapter 10. The two-layer architecture, applied grammar and formal core, is a governed division of responsibility: this appendix specifies what practitioners write, and the RecPol specification specifies what conformant tools must validate, and both layers are necessary for the system to achieve simultaneously the accessibility and the formal governability that the thesis’s design science objectives require.

11.1 Semantic derivation through the wrapping functor

The two layers stand in a stronger relation than parallel documentation: every PlaniSyn construct is derivable from the formal core. The wrapping functor W: G→A registers the applied grammar’s extension tokens over the core grammar, and the desugaring it licenses carries each applied-grammar construct back to a determinate sequence of RecPol entity blocks, without modifying the formal core. The desugaring performs a narrowing rather than a lateral translation, so PlaniSyn introduces no semantics beyond the composition of RecPol operations already available. Two properties hold by construction: identity, in that the empty extension desugars to the empty formal-core sequence; and composition, in that the desugaring of a composite construct distributes over its parts under the left-to-right evaluation rule. These are the properties that make PlaniSyn semantically derivable from RecPol rather than an independent notation with its own primitives.

The derivation is staged, and its staging settles the surface question raised by the two layers’ shared use of the pipe character. A PlaniSyn declaration is consumed first by the applied-grammar parser, which reads the pipe as PlaniSyn’s class-separation tag, partitioning the six declaration fields. That parser hands its output to W, which emits a formal-core token stream in which the pipe appears only in its single RecPol role, dividing an entity identifier from its predicate list. The formal-core parser reads the output of W, never the raw applied-grammar text, so PlaniSyn’s multi-field pipe and RecPol’s single structural pipe never occupy one token stream. The pipe is a source-layer separator in PlaniSyn and a target-layer structural token in RecPol, disambiguated by the processing stage at which each parser runs. Axiom 8’s six reserved extension-point tokens govern only the new tokens the applied layer introduces, and the pipe, a pre-existing formal-core token, is not among them; the formal core’s productions are therefore unchanged and its parsing guarantee is preserved under extension.

A worked derivation of a canonical bedroom declaration makes the mapping concrete. The declaration

<BED_01 | P:N10 E8 S10 W8 | B:1 | A:closed | O:D1@W3 | An:(0,0)>

desugars field by field into a three-plane RecPol document. The object identifier BED_01 is projected onto the primitive, configurative, and interactive planes as s^BED_01, f^BED_01, and i^BED_01; the perimeter P:N10 E8 S10 W8 becomes the primitive-plane shape of the enclosed eight-by-ten cell extent; the configurative form composes that shape and carries its constraint policies; and the anchor An:(0,0) becomes an interactive-plane placement of the form at the grid’s first cell, the World Grid’s zero-exclusion convention mapping the declared origin to cell one-one. The geometry, composition, and placement are exhibited directly:

< s^BED_01 | { MakeShape 1,1 : 8,10 } >
< f^BED_01 | { MakeCompound < s^BED_01 > } >
< i^BED_01 | { CallForm < f^BED_01 > } ; { Place 1,1 } >

Each entity block carries at most one structural pipe, every verb is drawn from the frozen RecPol verb set of the RecPol Specification appendix, and the shape, form, and instance blocks parse under the formal-core grammar. The three remaining declaration fields desugar onto the configurative form under the same discipline, and are described here rather than expanded in the block above. The border B:1 adds an inset interior shape, normalised as an independent primitive and positioned one module within the perimeter’s local frame, with the wall and interior regions governed on distinct occupancy lanes whose policies are Full, tolerating only empty neighbours, and Empty, tolerating content. The access state A:closed and the opening O:D1@W3 add latch constraints on the access lane, forbidding along the perimeter and permitting at the single west-edge cell that carries the door, expressed as ConsLatchment predicates whose policy values are minus one and zero respectively; their edge-segment coordinates follow the edge-cardinal convention of the RecPol Specification appendix. Each of these three mappings uses only frozen RecPol verbs, so the derivation is semantically derivable, introducing no mechanism outside the formal core, and its shape-form-instance progression composes under the plane discipline the core defines. The remaining PlaniSyn constructs, the action, prerequisite, and transformation tags, the four interaction types, and the nesting hierarchy, desugar under the same discipline, each through the extension-point tokens Axiom 8 reserves, so that the applied layer supplies surface convenience without extending the formal core’s semantics.

Schema Architecture

The standardisation schema is structured as five governed layers, each encapsulating a distinct design concern and exposing only governed interfaces to the layers next to it. The layering is itself an enforcement mechanism: no downstream consumer can bypass the identity, role, or ambiguity conditions an upstream layer has established. The table reads from the most foundational layer (identity) to the most integrative (governance audit), and for each layer it states the concern it owns, the fields it requires, the rule that validates those fields, and the way it handles ambiguity rather than hiding it.

Clause Representation Contract (field-level type)

Every schema row is governed by the field-level type contract below. Each field exists because a measured failure mode requires it (the failure analysis is in Chapter 5, Section 5.4), so no field is optional: removing any one reintroduces the failure mode it was designed to prevent.

Foundational Entity Inventory

The foundational inventory is the stratified vocabulary of spatial-semantic entities that remains after the ablation-justified removal of zone. It is organised into seven schematic primitives, irreducible conceptual baselines, and seven elaborated composites construed from them through the relation operators (Canonical Relation Set, below). The set is closed by empirical ablation rather than by definitional fiat: any extension requires a comparable ablation justification before a new term is admitted to the governed schema.

Schematic primitives

Elaborated composites

What the flat vocabulary recorded as a relation primitive is reconceived here as the relation-operator layer (the Canonical Relation Set below) rather than as a standalone entity.

Canonical Relation Set

Ten governed relation operators remain after applying to the relation set the same ablation discipline used for the entities: two standard ontological relations and eight thesis-specific ones. Each is retained only because its removal produces measurable information loss in the corpus analysis, so the set is empirically bounded rather than theoretically open-ended.

Design Principles

Six principles govern how the schema is constructed.

1. Identity before interpretation. Clause identity is anchored to record_uid, not to source_clause_id alone, because duplicate source identifiers can carry distinct statements.
2. Role-aware representation. A clause class is mandatory because requirement, rationale, and applicability frames do not carry equivalent inferential force.
3. Ambiguity visibility. Term-level and row-level ambiguity indicators are first-class fields, not post-hoc commentary.
4. Primitive discipline. Mappings target the foundational primitive and relation sets rather than free-form labels.
5. Residual explicitness. Unresolved cases remain represented, through residual flags carrying a reason and a planned disposition.
6. Handoff readiness. Each row preserves the information a downstream artefact needs, so that no reinterpretation is required at the boundary.

Taken together, the six principles hold completeness, transparency, and downstream usability as co-equal requirements rather than as trade-offs to be balanced. The corpus-scale figures below show the coverage achieved under those constraints.

Corpus Scale

Applied across the full SDA Design Standard, the schema governs 800 representations with no validation failure, which is the quantitative warrant that the field-level contract above is satisfiable over the entire instrument rather than only on selected clauses.

1 Purpose and Scope

The space-category taxonomy developed in Chapter 6 §6.2 for the Governed Kernel Architecture is recorded here as a consolidated reference. The taxonomy classifies the nine SDA-aligned module types (ENT, CIR, SAN, BED, LIV, KIT, SVC, EXT, and DWL) as a non-overlapping, exhaustive partition of the space types that appear in SDA-compliant dwelling configurations, and pairs the module-type axis with the four-category design taxonomy (FA, RB, LV, UN) under which the module library’s governed instance library is organised. The categorical hierarchy, the defining primitive profiles, the inter-category relationship rules, and the verification-sequence ordering are recorded for each type. These specifications govern the module library developed in Chapter 6 §6.4 and establish the categorical basis for the interaction differential analysis presented in Chapter 6 §6.3.

Three substantive sections follow. Section 2 specifies the nine module-type taxonomy by primitive profile, planimetric role, and corpus-level cluster statistics. Section 3 specifies the four-category design taxonomy (FA, RB, LV, UN) by occupant profile, source standard, and in-corpus baseline-library coverage. Section 4 specifies the inter-category relationship rules: the active boundary-pair register, the Rule 4 variant inheritance scheme, and the verification-sequence ordering derived from the planimetric triad alignment.

2 Module-Type Taxonomy

The nine module types are derived from primitive-profile co-occurrence in the 611-clause SDA corpus through the four-stage Jaccard clustering procedure documented at §6.2 (primitive profile vectorisation; pairwise Jaccard similarity; average-linkage hierarchical clustering at cut-height h = 0.35; cluster naming and validation). The procedure produces nine clusters (mean silhouette coefficient 0.72, between-cluster mean Jaccard 0.12), and the nine-cluster partition recurs in 47 of 50 stratified resamples of the corpus. The taxonomy is non-overlapping (by construction of the silhouette-selected partition) and exhaustive (the SDA Standard’s own organisational structure maps one-to-one onto the nine module types; no SDA section addresses a space type absent from the taxonomy).

The three primary compositional axes that organise the taxonomy are connectivity versus function, fixture intensity, and governance-scope conditionality (§6.2). The first axis separates connectivity-dominant modules (ENT, CIR, EXT: high path, opening, boundary, level density) from function-dominant modules (SAN, BED, LIV, KIT, SVC: high room, fixture, activity, quality density), with the dwelling-aggregate module (DWL) occupying a separate branch. The second axis further differentiates function-dominant modules by fixture density: SAN and KIT carry the highest fixture intensity; BED and LIV carry the lowest; SVC sits at intermediate intensity. The third axis is the context primitive’s presence in the defining profile, reflecting which module types carry strongly category-conditional requirements (ENT, SAN, KIT, EXT) versus those whose requirements apply more uniformly across categories (CIR, BED, LIV, SVC).

Each module-type row below records the three-letter code, the full name, the planimetric role (primitive / configurative / interactive plane), the defining primitive profile (the two-to-five-primitive combination that most strongly discriminates this type from all others), the supporting primitive profile (primitives that appear at moderate frequency without unique discriminating force), the dominant relations, the within-cluster Jaccard, and the clause count.

The nine module types cover all 611 corpus clauses without remainder (58 + 76 + 115 + 64 + 61 + 70 + 36 + 50 + 81 = 611). No clause is left unclassified. The within-cluster Jaccard scores range from 0.61 (LIV) to 0.73 (SAN). Four clusters (LIV (0.61), SVC (0.64), DWL (0.65), and BED (0.66)) sit below the chapter mean of 0.68, reflecting genuine intra-cluster requirement-coverage breadth (corroborated by per-cluster silhouette values in the 0.62-0.69 range, all above Rousseeuw’s 0.5 “reasonable cluster structure” threshold) rather than cluster fragility. Source: §6.2.

Where a profile lists relation (LIV, DWL), the term denotes the relation-operator layer of the stratified vocabulary (Section 6.1), not an eighth schematic primitive: these clusters are distinguished by a high incidence of cross-entity links, recorded in the profile as a relation element and realised in the baseline library as concrete relation instances that apply the ten operators. The seven schematic primitives remain space, boundary, element, quality, activity, context, and actor.

2.1 Planimetric-Plane Grouping

The module taxonomy partitions into three planimetric groupings that mirror the three planes of the planimetric triad established in Chapter 3 §3.4 and operationalised in §6.2.

Primitive-plane dominant modules: ENT, CIR, EXT. Verification obligations address structural conditions under which spaces are connected and traversable: path widths, opening clear widths, level thresholds, surface grades. These modules constitute the foundational layer of the representational hierarchy; accessible connectivity is a prerequisite for accessible function.

Configurative-plane dominant modules: SAN, BED, LIV, KIT, SVC. Verification obligations address functional conditions under which spaces support specified activities: grab-rail placement, turning circles, bench clearance, bed approach space. These modules presuppose that primitive-plane modules have been verified.

Interactive-plane dominant module: DWL. Verification obligations address whole-dwelling properties: design-category classification, multi-storey provisions, gross-floor compliance, and cross-module relational requirements. The DWL module is the governance layer; its verification presupposes that all eight space-specific modules have been individually verified.

3 Design-Category Taxonomy

The four module-library design categories, FA, RB, LV, and UN, partition the library’s accessibility specification space by target occupant profile and source-standard provision. This module-library design-category axis is a distinct framing from the SDA Design Standard’s own four categories, which are Improved Liveability (IL), Fully Accessible (FA), Robust (RB), and High Physical Support (HPS): the library shares Fully Accessible and Robust with the Standard, derives its Liveable (LV) category from Livable Housing Australia Silver-level criteria as the nearest analogue to the Standard’s Improved Liveability tier, and adds a category-independent Universal (UN) construct with no Standard counterpart, while the Standard’s High Physical Support and Improved Liveability categories are not carried as separate library axes. The categories provide the second axis of the library entry identifier scheme (entry_id = module-type-code + design-category-abbreviation + zero-padded sequence number, e.g., SAN-FA-01, CIR-RB-02, DWL-LV-01) and govern the design_category field on every governed-instance-library entry. The baseline-library coverage figures record the in-corpus minimum library specified at §6.4, totalling 25 baseline entries.

The 25-entry minimum library is specified by category as FA(9) + RB(9) + LV(7) + UN(0) = 25, and by module type as ENT(3) + CIR(3) + SAN(3) + BED(3) + LIV(3) + KIT(2) + SVC(3) + EXT(2) + DWL(3) = 25. The two pairings produce the same total against the canonical nine-module taxonomy, confirming the library’s coverage closure. Source: §6.4.

The category-independent code UN is retained in the entry-identifier scheme to preserve the option of category-independent variant entries in future library evolution, but the present minimum library carries no UN baseline entry; its category-independent obligations are discharged by the §6.2 governed-kernel constituent specifications. Dwelling plans that exhibit configurations specific to one design category but not the others (a Fully Accessible bathroom with an overhead hoist track, a Robust-category bedroom with impact-resistant wall linings) are captured through the FA, RB, or LV entries with appropriate optional-element population.

3.1 Design-Category Conditional Requirements

The context primitive carries each module’s design-category sensitivity. The four module types in which context appears in the defining primitive profile (ENT, SAN, KIT, EXT) exhibit the strongest category-conditional requirement variation. ENT requirements differ substantially across FA / RB / LV (powerchair-width versus ambulant-accessible versus minimum approach path); SAN requirements differ in turning-circle, hoist-provision, and height-adjustable-fixture obligations; KIT requirements differ in bench-clearance and reach-range obligations (with no LV-specific provisions, hence the KIT-LV omission); EXT requirements differ in surface-dimension and parking-approach obligations (with no LV-specific provisions, hence the EXT-LV omission). The four module types in which context appears only in the supporting profile (CIR, BED, LIV, SVC) exhibit requirements that apply more uniformly across categories, with differences of degree rather than kind. The DWL module’s context primitive is in the defining profile because design-category classification is the DWL module’s primary function. Source: §6.2.

4 Inter-Category Relationship Rules

The inter-category relationship rules govern how module types and design categories interact within the module system’s governed kernel and governed instance library. Three rule sets are recorded: the active boundary-pair register (the cross-module-type interactions specified at §6.3), the Rule 4 variant inheritance scheme (the cross-design-category variant tags exercised in the demonstration cases of Chapter 10), and the verification-sequence ordering (the planimetric-triad-derived precedence constraint specified at §6.3).

4.1 Active Boundary-Pair Register

The twelve active boundary pairs at which the module system declares cross-module interactions are documented below. Each pair carries declared shared entity types, an owner module under the entity-ownership rule, an interaction differential (the ratio of within-module to cross-boundary relation density measured on the 611-clause corpus), and the primary semantic risk pattern. The interaction differential range from 13.2 (LIV-KIT) to 34.1 (LIV-EXT) confirms that all twelve boundaries separate genuinely low-coupling zones rather than dividing uniformly integrated regions: the empirical basis for Axiom 2 (interaction differential).

The most systematic semantic risk across the register is the reclassification of opening entities as boundary entities: a misclassification that loses the directional opens_to relation that the verification interface requires. The second most common risk is level entity duplication in the EXT-DWL and DWL-All pairs, which is addressed by the level-consistency constraint at §6.2. The vocabulary-closure rule prohibits any module or inter-module contract from introducing entity instances whose primitive assignment falls outside the stratified closed vocabulary; semantic-risk patterns are recorded for governance auditing, not for absorption through new primitive types. Source: §6.3.

4.2 Rule 4 Variant Inheritance Scheme

Library Governance Rule 4 (§6.4) restricts variant entries to vary only in optional elements from their parent baseline entry; variants that modify a required element are treated as new entries with different provenance requirements, not as variants of the parent. The four variant tags exercised in the Chapter 10 demonstration cases illustrate the rule’s operational reach. Each tag is hosted by a specific Level 2 module type and differentiates from the parent baseline entry only through optional-element population.

The variant relationship is strictly about optional-element variation within the governed kernel’s declared degrees of freedom. The four tags collectively demonstrate that the governed instance library absorbs the genuine diversity of SDA dwelling configurations observed in practice without requiring governed-kernel modification: the structural basis for Proposition P4 (transformability). Source: §6.4.

4.3 Verification-Sequence Ordering

The planimetric-triad alignment established at §6.2 identifies a natural ordering among the nine module types that functions as a hard constraint on verification sequences: primitive-plane modules must be verified before configurative-plane modules before the interactive-plane module. The ordering reflects a logical dependency structure: configurative-plane modules presuppose that the connectivity modules providing access to them have been verified as accessible; the dwelling module presupposes that the individual space-specific modules have been verified before cross-module relations, design-category compliance, and whole-dwelling properties are evaluated.

The verification-sequence constraint is embedded in the verification-interface contracts as a priority rule: verification requests for configurative-plane modules are flagged with a dependency check requiring all primitive-plane modules for the same dwelling instance to be in a verified state before configurative-plane verification can proceed; verification requests for the DWL module carry a full dependency check requiring all eight space-specific modules to be verified. The constraint is the operational expression of Axiom 1 (bounded frame) applied across modules rather than within them: each module’s verification scope is bounded by its own constituent specification and by the pre-conditions established by its logical predecessors in the sequence. Source: §6.3.

The notation system in Chapter 7 encodes the sequence constraint as a structural property of the formal grammar: the plane projection operator (^) makes it syntactically impossible to place configurative-plane references before primitive-plane references within a well-formed dwelling expression, and the three-level hierarchical nesting structure of PlaniSyn (Level 1 Primitive plane fixtures and openings; Level 2 Configurative plane rooms and spaces; Level 3 Interactive plane DWL aggregate) encodes the inside-out verification ordering directly. The procedural generation pipeline in Chapter 9 implements the sequence constraint as an execution-order rule in the generation algorithm. The verification sequence is therefore not a workflow convention but a non-negotiable structural property of every artefact built on the module system. Source: §6.3; §7.18.

The space-category taxonomy establishes the governed categorical substrate within which the module library’s governed-kernel specifications and governed-instance-library entries operate. The nine-type module taxonomy, the four-category design taxonomy, and the inter-category relationship rules together fix the categorical commitments inherited by Chapter 7’s notation system, Chapter 9’s procedural pipeline, and the demonstration cases of Chapter 10.