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: 2 records the seven 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 in response to critical defects C1 and C2 and high-severity defects S1 through S5 identified in the comprehensive audit of the Version 5.0 specification.

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 (§9.2) 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 (§9.1), MakeCompound (§9.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.

9.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 > } >

9.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 > } >

9.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 } > } >

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

10.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 > } >

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

11.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 }

>

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