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 design categories — FA, RB, LV, UN — partition the SDA accessibility specification space by target occupant profile and source-standard provision. 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 decomposes 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.