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

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

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

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

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

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

11.2 Interaction Grammar

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

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

11.3 Nesting Grammar

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

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

11.4 Transformation Grammar

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

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

11.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 Backus-Naur Form, 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 remains in development as of the current thesis draft. The PlaniSyn grammar documented in this appendix constitutes the current operational specification of the notation system as implemented and evaluated in the demonstration cases presented in Chapter 10. Thus the two-layer architecture — applied grammar and formal core — is not a redundancy but a governed division of responsibility: this appendix specifies what practitioners write, and the RecPol specification specifies what conformant tools must validate, and therefore both layers are necessary for the system to achieve simultaneously the accessibility and the formal governability that the thesis’s design science objectives require.