A Governed Kernel Architecture for Housing

Housing plans that must answer to accessibility requirements need a way of being described that can be reused, modified, and checked without their meaning drifting from one reading to the next. Chapter 5 delivered the raw material for such descriptions: a governed substrate of subject–predicate–object triples extracted from the Specialist Disability Accommodation (SDA) Design Standard — 611 text-clause representations and 189 figure-derived representations, each carrying a stable record_uid, a four-class role assignment, a confidence-labelled ambiguity profile, and transparent residual governance.¹ What that substrate does not yet carry is a compositional architecture: a vocabulary of named, bounded units from which plan descriptions can be assembled and against which accessibility obligations can be evaluated. Supplying that architecture is the work of this chapter, and it is the structural hinge of the artefact suite — without Chapter 5’s semantic substrate the module definitions would encode unresolved ambiguity, and without the compositional structure built here the notation of Chapter 7 would have no architecture to formalise and the procedural generation of Chapter 9 no contracts to operationalise.²

The scheme is therefore best read not as a standalone object but as a transformation: governed triplet data enters, governed compositional structure leaves, under the constraint that nothing entering the system may contradict the semantic commitments of the standardisation schema. That compositional structure is the thesis’s load-bearing engine. Strip away the names — representational governance, the four properties, the five-artefact suite — and what remains is one engineering claim: a nine-type governed kernel with bounded interfaces and a complement-variation rule absorbs divergent regulatory pathways at the instance layer without the kernel itself changing. The sections that follow specify that engine; Chapter 10 demonstrates it at a single decisive fork. The immediate task is to make the engine inspectable and buildable, beginning with the vocabulary from which everything else is composed.

The engine is organised as a three-layer Governed Kernel Architecture, and the chapter is structured around it. The operating definition of modularity governs three different kinds of object — representational elements, module contracts, and governed instances — and the architecture gives each its own layer. Layer 1, the Generative Grammar (this section), defines what can exist: the admissible representational elements, organised as a primitive register, an operator register, and a composite register. Layer 2, the Modular Contract System (Sections 6.2 and 6.3), defines what can count as a module: a cluster of generated elements becomes a module only when it passes a contractual admission test for interaction differential, functional boundary, finite expressed interfaces, constraint closure, verification closure, and stable role. Layer 3, the Governed Instance Library (Section 6.4), defines what can vary without breaking the system: the baselines, variants, provenance, and supersession through which concrete change is absorbed. Layers 1 and 2 together form the governed kernel; Layer 3 is the governed instance environment. The kernel is governed, not frozen — downstream artefacts may not alter it, yet it is itself revisable through a rule-bound, evidence-based, versioned promotion path (Section 6.4), so its stability is disciplined revisability rather than immobility. The governing sequence is Generative Grammar → Modular Contract System → Governed Instance Library, and the no-leakage rule that keeps the three layers from contaminating one another is stated with the library in Section 6.4. The three layers can be read as a sequence of object transformations, which fixes their formal relationship: the grammar maps primitives and operators to admissible elements, G(P, R) → E; the contract system admits only those element-clusters that pass the modularity test, M(E, I, C, V) → K, where I, C, and V are the interaction, constraint, and verification evidence; and the library instantiates module contracts as governed instances under permitted variation and provenance, L(K, X, H) → N. Grammar produces elements, contracts produce modules, and the library produces governed instances.

Representational, not physical, modularity

One distinction must be fixed before the chapter proceeds, because it determines what the module system can claim and what evidence it owes. The modularity developed here is representational: it governs how housing plans are described, composed, and verified in representational form, not how buildings are physically prefabricated or assembled. The distinction separates this work from two adjacent traditions. The Open Building movement, associated with Habraken’s theory of supports and infill, addresses physical modularity — the designed separation of long-lived structural layers from shorter-lived fit-out so that different actors can adapt a building over time.³ The product-platform architectures of manufacturing research, in Baldwin and Clark’s account, likewise treat module boundaries as physical or functional interfaces in an artefact.⁴ This chapter borrows the theoretical vocabulary of platform architecture — governed kernel, governed instance library, interface contracts — but applies it to representational objects. A module here is a representational unit: a bounded, named configuration of primitives with declared constituent elements and checkable interaction rules, whose boundaries are semantic rather than material.

The borrowing is specific. The operative move is Baldwin and Clark’s publish/hide partition: visible design rules are published and held fixed, while hidden module parameters are free to vary within them. Transposed to representation, the published design rules are the primitive vocabulary, the module taxonomy, and the interface contracts; the hidden, free-to-vary parameters are the specific configurations that populate them. Representational modularity makes claims about description completeness, semantic consistency, and verification tractability — claims testable against the governed corpus of Chapter 5 and the notation contracts of Chapter 7. Claims about buildability, structural integrity, and assembly tolerance belong to physical modularity and lie outside the scope of this thesis.⁵

Grounding in the Chapter 3 theory

Chapter 3 established four modularity axioms and three interface types as the design-theoretic commitments governing the suite, and they function here as the Governed Kernel Architecture’s design principles — the prescriptive commitments that constrain every design decision before any specification is written, in the sense Gregor and Jones require of a design theory.⁶ The axioms are not commitments imported from a single tradition; they are the convergent invariants that Chapter 3, Section 3.3 identified from a structured cross-domain corpus of 905 screened records, of which 129 were retained for extraction, yielding 810 evidence rows across biology, computer science, engineering, and management.⁷ Axiom 1 (bounded frame) requires each module to have a finite, declared boundary, operationalised through the non-overlapping taxonomy of Section 6.2. Axiom 2 (interaction differential) requires within-module interaction density to exceed cross-module density, operationalised through the composition and interaction contracts of Sections 6.2 and 6.3. Axiom 3 (finitude) requires a finite, declared module set, operationalised through the library of Section 6.4. Axiom 4 (governed exchange) requires cross-module interaction only through declared interfaces, operationalised through the three interface types applied at module boundaries.

Those three interface types — corpus-derived in Chapter 3 as the distinct governance functions a boundary claim must jointly satisfy to be operational rather than merely descriptive — define the nature of the boundaries. The semantic interface governs meaning preservation, so that module definitions do not alter primitive meanings inherited from the standardisation schema. The transformation interface specifies what may change within a module’s degrees of freedom. The verification interface defines the re-checking protocol that applies when a module’s properties are assessed against a requirement. The chapter additionally inherits the Chapter 3 platform commitment: the system is structured as a governed kernel — the grammar and module contracts, which downstream artefacts must not modify, though the kernel is itself revisable through the governed promotion path — and a governed instance library — the module instances and library entries, which may vary within declared degrees of freedom without disturbing the kernel.

Two of the thesis’s four design propositions are addressed here primarily, and two as supporting claims; their canonical statements and qualifiers are inherited from Chapters 1 to 3 and are not redefined. Proposition 2 (transportability) holds that a representational system governed by explicit interface contracts at module boundaries exhibits lower verification burden than a monolithic system under the same constraints; Section 6.3’s interaction contracts and Section 6.4’s bounded-scope demonstrations supply its structural basis. Proposition 4 (transformability) holds that a platform with a governed kernel and a governed instance library accommodates variant configurations without modifying the kernel; the library architecture of Section 6.4 supplies its structural basis. Proposition 1 (interoperability) is supported by the identity-preservation argument of this section, and Proposition 3 (manipulability) by the interface contracts of Section 6.3; the primary quantitative evidence for both resides in the Chapter 10 demonstration, whose decisive fork this chapter does not pre-empt. The chapter also inherits the four design constraints absorbed in Chapter 3: DC-1 (negotiability) is met by the governed-instance-library mechanism, DC-2 (institutional compatibility) by deriving definitions from the SDA vocabulary practitioners already use, DC-3 (revisability) by declaring what is fixed and what is variable, and DC-4 (tractability) by keeping the taxonomy size and interaction-rule complexity finite and expressible without specialist equipment.

The derivation problem

A triplet corpus does not hand over a primitive vocabulary; it yields an occurrence distribution of terms, relations, and co-occurrence patterns that must be interpreted against several competing constraints at once. The vocabulary must be compact — small enough for contract enforcement without specialist tooling — yet complete, covering every clause-level accessibility obligation without leaving terms unclassifiable. It must be grounded — each primitive justifiable from corpus evidence rather than external ontological preference — yet externally coherent, so that most primitives have equivalents in independently developed spatial schemas and thus capture genuine domain concepts rather than artefacts of the procedure. And it must be stable, generalising beyond the partition from which it was derived. These five constraints — compactness, completeness, groundedness, external coherence, and stability — define the evaluation framework for the vocabulary, and each is addressed by a distinct test: ablation analysis for groundedness and compactness, holdout for stability and completeness, external benchmarking for coherence, and a co-occurrence-structure check that bridges to the taxonomy of Section 6.2.

The derivation runs as a constrained progression from corpus occurrence to named vocabulary, following the mapping protocol established in Chapter 5: begin from occurrence-grounded lemmas and clause-class context; assign primitives only through the approved inventory; assign relations only through the approved relation inventory; record each assignment’s rationale as direct, keyword, or fallback; and preserve ambiguity confidence and residual markers throughout. At the selected frequency threshold of at least three occurrences in the 611-clause corpus — a transparent design decision, not an estimated cut-off — 204 eligible lemmas receive assignments: 150 non-fallback and 54 fallback, the latter concentrated at frequencies three and four where corpus evidence is thinnest. A single clause shows the procedure at work. SDA clause D4.3.a — “in the bathroom, a grab rail shall be provided beside the toilet at a height of 800 mm to 810 mm above finished floor level” — enters Chapter 5’s substrate as a governed triple and maps cleanly: grab_rail to the fixture primitive by direct assignment, bathroom to room, the dimensional specification to quality via has_quality, and the functional requirement to the activity primitive (toilet_transfer) via serves_role and supports_activity. The four vocabulary terms activated — the composites room and fixture, and the primitives quality and activity, all in the service of the actor the clause ultimately addresses — are exactly the defining profile of the Sanitary module type of Section 6.2, and the transformation from corpus triple to governed module constituent is traceable at every stage without information loss.

A stratified vocabulary: schematic primitives, elaborated composites, and an operator layer

The derivation does not return a flat list of equal terms; it returns a vocabulary with internal cognitive structure, and reading that structure is what lets the module system claim more than a naming convention. The terms divide along a construal gradient of the kind cognitive grammar identifies between schematic categories and the elaborated concepts built from them: a small set of schematic primitives naming irreducible conceptual domains, a larger set of elaborated composites that profile those domains into more specific construals, and an operator layer that performs the construal by relating one term to another.⁸ The architecture is named accordingly — a cognitive primitive–composite–module architecture — and reads in a line: schematic primitives generate elaborated composites, and composites whose interactions are denser internally than across their edges cohere into modules. The three planes of the stratified discrete substrate formalised in Chapter 3, Section 3.4 are this same gradient seen from the governance side: the primitive plane carries the schematic baselines and their most direct spatial elaborations, the configurative plane carries identity and intent, and the interactive plane carries relation and scope. The stratification is also a consequence of Axiom 1: each term occupies a bounded, declared semantic role that does not overlap with its neighbours.

The schematic primitives. Seven primitives are irreducible: each names a conceptual domain that cannot be generated from the others without presupposing itself. space cannot be derived without spatiality, boundary without limit or interface, element without built objecthood, quality without property structure, activity without event or use, context without frame or applicability, and actor without a participant. The last is made explicit here for the first time: the human subject — participant, resident, wheelchair user, support worker — whom an accessibility requirement addresses. Naming it is less a discovery than a correction of status. The participant lemmas the standardisation schema already isolated (wheelchair, user, participant, person, staff) had been gathered under a role heading; but a role is something an actor occupies, not the actor itself, and once the actor is named as the primitive, role takes its proper place as a composite. Each primitive’s plane, definition, clause coverage (non-exclusive, since one clause may activate several terms), and external grounding are consolidated below.

The elaborated composites. Seven further terms are not primitive; each is a construal generated from one or more primitives through the operator layer, more specific because it profiles a particular materialisation, function, or institutional recognition of its schematic base. A room is bounded space — a zone — construed as enclosed, functionally identified, and activity-supporting within a regulatory frame; a dwelling is an aggregate of rooms construed as a residential unit under actor occupancy; an opening is a boundary construed as passable; a fixture is an element construed as installed, located, and activity-supporting. The derivations are stated compactly below, each expressed through the operator layer of the next subsection.

The role composite carries no standalone entity mapping because it is expressed relationally, through serves_role, rather than as a term clauses name directly — which is why the participant lemmas formerly recorded under a role heading migrate to the actor primitive while functional assignment remains the business of the relation. The abstraction-first discipline of the original vocabulary is preserved throughout: each term names a conceptual category that groups clause-level terms by shared functional role rather than naming a specific object, so that fixture, for instance, gathers grab_rail, tap, basin, and bed_head under one category of specified, locatable elements.

The architecture also explains a removal carried forward from the derivation cycle. That cycle considered zone as a candidate primitive; it attracted no mapped high-frequency terms, produced no information loss on removal, and was absent from all ten holdout partitions. The cognitive account makes the empirical result intelligible rather than merely convenient: zone is not primitive but composite — space bounded_by boundary — so its descriptive work is already carried by the space primitive and the bounded_by operator, and retiring it as a named term loses nothing. Its removal follows from the architecture, not from an ad hoc economy.

Necessity, stability, and external coherence

The stratification is a claim about derivability, tested independently of the corpus counts, and the counts then cohere with it. Necessity is established by ablation: for each term, the information loss on removal is measured as the proportion of the corpus’s total descriptive granularity attributable exclusively to it. The four highest-necessity terms are all schematic primitives — activity (0.303, active in 603 clauses), quality (0.164, 325 clauses), context (0.142, 283 clauses), and element (0.081, 161 clauses) — reflecting the SDA’s organisational logic, in which requirements are specified chiefly as what occupants must do in designed spaces, under declared regulatory scope, for particular actors. The composites carry real but smaller loads (fixture 0.050, opening 0.046, path 0.045, level 0.043, room 0.026), exactly as the architecture predicts: a composite’s ablation score measures how often it is instantiated, not whether it is irreducible, so a heavily instantiated elaboration can outweigh a sparsely instantiated primitive without thereby becoming one. The lowest scores fall to the least instantiated terms and the operator — actor (0.022, inheriting the footprint the corpus recorded under the former role heading), dwelling (0.013), and the relation operator (0.005) — and each is retained not for its corpus-level loss, which is modest, but for a downstream specification no smaller vocabulary preserves. Naming actor as a primitive keeps the participant the Sanitary and Bedroom modules are specified to serve, and lets role survive as the serves_role composite that separates Kitchen from Bedroom modules; retaining dwelling gives the Dwelling module a singular owner for level and cross-module relations; and retaining the relation operator preserves the explicit cross-module construct on which the dwelling-level constraints of Section 6.2 depend. The vocabulary is, on this reading, the minimal one consistent with the constituent specifications of Section 6.2 and the interaction rules of Section 6.3.⁹

Stability is established by holdout. The fourteen-term vocabulary was applied to the held-out portion of ten random 80/20 partitions of the corpus, and across every partition it covered all held-out clauses; term-level generalisation averaged just under 0.95, meaning roughly nineteen in twenty mapped-term occurrences in a held-out portion used terms that had also met the frequency threshold in the corresponding training portion. These are descriptive observations of the vocabulary’s behaviour across partitions of a fixed corpus, not estimates carrying sampling error: the SDA Design Standard is the population of regulated accessibility obligations under the Australian scheme, not a sample drawn from a larger one, so the partition figures report coverage and term recurrence rather than supporting any inferential claim. The validation is within-corpus; generalisation to other accessibility standards is deferred to the future work of Section 6.5, and the methods are consistent with the knowledge-based disambiguation practice appropriate to a domain lacking sense-annotated training data.¹⁰¹¹

External coherence is established by benchmarking against two independently developed spatial ontologies, the IFC4 spatial type system and the Building Topology Ontology (BOT), which breaks the circularity of a vocabulary derived from and validated against the same corpus. The fourteen-term vocabulary covers all 611 clauses; IFC4’s spatial types cover 196 (32.1 per cent) and BOT 127 (20.8 per cent). These are descriptive coverage counts over the full corpus census, carrying no margin of error: they record how much of the corpus each scheme’s vocabulary already names, and would shift only if the corpus boundary were redrawn. Of the ten terms whose roles correspond to spatial-organisation categories that IFC4 and BOT attempt to model — the primitives space, boundary, and element, the composites room, dwelling, opening, path, level, and fixture, and the context primitive — nine have direct equivalents and only context does not, which is 90 per cent of the benchmarked set, equivalent to 64.3 per cent of the full vocabulary. The two framings answer different questions: 90 per cent of the terms that could in principle have an external equivalent do, while 64.3 per cent of the whole vocabulary is grounded in independently developed schemas. The five thesis-specific terms — the primitives quality, activity, context, and actor, together with the relation operator — have no equivalents, because general-purpose spatial ontologies model geometry and spatial organisation rather than functional accessibility; their absence is a genuine domain gap those ontologies do not address, and they earn their place through ablation necessity and corpus prevalence rather than external precedent.¹²

The relation-operator layer

What the flat vocabulary listed as a fourteenth primitive, relation, is better understood as the layer that performs the construal work: the operators that connect primitives and generate composites, rather than an entity that clauses name. Ten operators are derived: is_a, part_of, bounded_by, opens_to, connects, located_at_level, has_quality, serves_role, supports_activity, and within_context. Two — is_a and part_of — are standard ontological primitives; eight are thesis-specific extensions required to express accessibility-domain semantics. The operators are derived by gap analysis rather than frequency: for each kind of clause-level semantic link, the question is whether an existing standard relation suffices or a novel operator is required. Each novel operator is justified by the gap it fills, the logical constraints it carries, and a falsification test stating the condition under which it would be unnecessary; all eight survive their tests against the corpus.

One relation dominates the distribution: has_quality carries 67.1 per cent of all triples in the corpus, a concentration of 0.6639 on the Gini coefficient over the relation distribution. Four semantic subgroups sit within it — dimensional constraints, performance attributes, presence requirements, and categorical qualifiers — and the natural question is whether has_quality should be split into four narrower relations. A single annotated relation is retained, for reasons of corpus structure rather than preference. Many clauses interleave subgroups within one statement — a doorway “shall have a minimum clear width of 820 mm and shall contrast with adjacent surfaces” carries a dimensional constraint and a performance attribute together — so decomposition would either duplicate such clauses across categories or impose an artificial clause-splitting protocol, neither of which improves precision while both add governance obligations. The single relation with a subgroup annotation keeps the downstream contracts of Chapters 7 and 9 simpler, and the decomposition question is carried to the future work of Section 6.5, where cross-corpus evidence could show whether other standards require the finer relations.¹³

Figure 6.2 sets out the stratified vocabulary as a whole — the seven schematic primitives, the ten operators that relate them, and the seven elaborated composites they build — together with the three closure commitments that govern the layer.

Co-occurrence structure and the vocabulary contract

The vocabulary captures genuine domain structure rather than imposing an arbitrary classification, and the evidence is the corpus’s own co-occurrence pattern. Counting how often pairs of terms appear together across the 611 clauses, the strongest pairings are systematic, not incidental: the context primitive co-occurs heavily with spatial and functional terms — with fixture (96 clauses), path (90), opening (89), level (84), and space (69) — because the standard specifies requirements within declared design-category applicability scopes; quality co-occurs with element (131) and fixture (70) in performance-specification clauses; and the four high-necessity primitives appear in the densest pairings overall. These counts are descriptive features of the closed corpus, reported as observed frequencies rather than tested against a null model, since over a census there is no sampling distribution to test against. What they establish is that the densest groupings are the ones the SDA’s own requirement structure produces, and those groupings are the empirical basis on which Section 6.2 draws the module-type boundaries: modules — read as interaction-bounded gestalts of composites — are defined by the clusters the standard reveals as functionally unified, not by topological convention.¹⁴

Three commitments are fixed here and inherited by every downstream artefact. First, the primitive set is closed: the seven schematic primitives may not be extended without corpus-necessity evidence that a new requirement category is unclassifiable under them. Second, composites are derived, not declared: every composite must be expressible as a construal of primitives through the operator layer, so the taxonomy and interaction rules may introduce composites only with a stated derivation, never a new primitive. Third, the operator layer is closed at ten relations — interaction rules may restrict which operators are admissible at a boundary but may not add operator types — and the has_quality concentration is an acknowledged design constraint, not a defect to be corrected here: module specifications use has_quality with subgroup annotation and defer decomposition until cross-corpus evidence is available. On this basis, Section 6.2 constructs the module taxonomy from the co-occurrence structure established above, grounding the module-type boundaries in the empirical patterns the corpus reveals as structurally genuine; those modules are read, in the cognitive architecture, as interaction-bounded gestalts — clusters of composites whose internal interactions are denser than their external ones, in direct expression of the interaction-differential axiom.¹⁵

The vocabulary of Section 6.1 supports individual triple assertions — this fixture has this quality, this space has this opening — but it cannot on its own support a module-level verification claim, that a sanitary space satisfies its accessibility obligations as a unit, independently of the rest of the dwelling and without the evaluator reconstructing the applicable requirements from scratch for each instance. Module-level verification requires that spaces be typed, so that the verification scope of a typed space is fixed by its type. The taxonomy is the mechanism that supplies that typing, and it opens Layer 2 of the governed kernel, the Modular Contract System: a nine-type classification of dwelling spaces — entry (ENT), circulation (CIR), sanitary (SAN), bedroom (BED), living (LIV), kitchen (KIT), service (SVC), external (EXT), and the dwelling envelope (DWL) — from which a dwelling plan is composed and against which its obligations are checked. The sections that follow define each type and its constituents in turn; the three-letter codes named here are the labels those definitions and the later entry-identifier scheme use throughout.

Three requirements constrain the taxonomy, and each operationalises a commitment from the preceding chapters. Non-overlap — each space belongs to exactly one type — operationalises Axiom 1 (bounded frame), because overlapping categories leave the applicable verification scope undefined at boundaries. Exhaustiveness — no space in an SDA-compliant plan is left unclassifiable — operationalises Axiom 3 (finitude), because a gap in the taxonomy is a gap in verification coverage. Functional grounding — type boundaries reflect differences in accessibility-obligation profile, not geometry — operationalises the representational-modularity commitment of Section 6.1, because a space’s applicable requirements depend on what it is for, not on its dimensions.

Constructing the taxonomy

The taxonomy is constructed from the corpus by a four-stage procedure that moves from co-occurrence evidence to named, validated types without importing external taxonomic conventions. First, each of the 611 clauses is represented as a fourteen-element binary vector recording which entity categories are active in it. Second, the similarity between every pair of clauses is computed by the Jaccard coefficient, the size of the intersection of their active-category sets divided by the size of the union; Jaccard is preferred over Euclidean or cosine distance for binary profiles because it normalises against the active features rather than the full vector length, so two clauses that are both mostly inactive are not scored as spuriously similar.¹⁶ Third, average-linkage hierarchical clustering is applied to the similarity matrix, and the cut height is chosen to maximise the average silhouette coefficient, a standard measure of how well each clause sits within its cluster relative to the nearest alternative.¹⁷ At cut height 0.35 the data resolve into nine clusters with an average silhouette of 0.72, a within-cluster mean Jaccard of about 0.68, and a between-cluster mean of about 0.12. Fourth, each cluster is named by its modal primitive profile and validated against the SDA’s own section headings and the planimetric-triad organisation of Chapter 3, Section 3.4.

The nine-cluster solution is the stable one. Examined across adjacent cut heights, it is the height that maximises separation: at 0.30 the data split into eleven weaker clusters (silhouette 0.59), at 0.32 into ten (0.64), at 0.35 into nine (0.72), and at 0.38 and 0.40 into eight (0.66 and 0.61). The nine-cluster partition is robust in the way that matters for a fixed corpus: within each cluster the modal primitive profile is fixed by the cluster’s core clauses rather than by any one borderline clause, so the defining profiles below do not turn on which clauses sit near a cut boundary. These are descriptive observations of how the clustering partitions the fixed corpus across cut heights, not estimates carrying sampling error; the corpus is the population of regulated obligations, and the figures report the stability of a partition rather than a confidence claim about a wider population.¹⁸

The nine space categories

The clustering reveals a structured space rather than nine equally independent types, organised along three axes. The first separates connectivity-dominant modules — Entry, Circulation, and External, dense in path, opening, boundary, and level — from function-dominant modules — Sanitary, Bedroom, Living, Kitchen, and Service, dense in room, fixture, activity, and quality — with the Dwelling-aggregate module on a branch of its own. The second axis separates high-fixture modules (Sanitary, Kitchen) from lower-fixture ones (Bedroom, Living), with Service intermediate. The third reflects governance-scope conditionality: Sanitary and External requirements vary substantially across design categories, Circulation and Bedroom requirements more uniformly. The near-universal activity primitive (present in 603 of 611 clauses) discriminates not by its presence but by what it co-occurs with — fixture and room in function-dominant clauses, path and opening in connectivity-dominant ones — so two clauses that both carry activity but differ in their other primitives score a low Jaccard similarity and fall in different clusters.

Each type is defined by the primitive combination that most strongly discriminates it, supported by primitives that appear at moderate frequency. The Entry module governs how the dwelling is reached and crossed (defining space, opening, path, context); Circulation governs internal traversal (path, opening, level, quality); Sanitary governs personal-care spaces and has the highest fixture density of any type (room, fixture, quality, activity); Bedroom governs private sleeping spaces, specified chiefly by what occupants must do in them (room, activity, quality); Living governs common-occupancy spaces and is the least fixture-intensive (room, space, activity); Kitchen governs food preparation and is distinguished from Sanitary by elevated element density alongside its fixtures (room, fixture, quality, element); Service governs laundry and utility spaces (room, element, quality); External governs outdoor areas within the curtilage and resembles Entry but carries level in place of opening (space, path, level, context); and Dwelling governs whole-dwelling aggregate properties and cross-module relations, the only type in which dwelling is a defining primitive (dwelling, context, level, relation). The nine cover all 611 clauses without remainder.

Non-overlap and exhaustiveness are both verifiable. Non-overlap holds by construction at the clause level — average-linkage clustering produces a strict partition, so no clause sits in two clusters — and at the instance level through the defining-profile check, since no two types share a defining combination; the silhouette of 0.72 and between-cluster Jaccard of 0.12 confirm the nine are genuinely separable, and a tiebreaker resolves the fewer than three per cent of borderline cases (such as a powder room sitting between Sanitary and Service). Exhaustiveness holds at the clause level trivially and at the dwelling-plan level by enumeration: the SDA’s own requirement domains — entry and approach, internal circulation, bathroom and toilet, bedroom, living and dining, kitchen, laundry and utility, outdoor areas, and design-category classification — correspond one-to-one with the nine types, so no SDA section addresses a space type the taxonomy omits. The four clusters with below-mean within-cluster Jaccard (Living 0.61, Service 0.64, Dwelling 0.65, Bedroom 0.66) reflect genuine breadth of requirement coverage rather than fragile definition: their modal profiles are stable across the adjacent cut heights examined above and their per-cluster silhouettes (0.62–0.69) sit above the conventional threshold for a sound cluster structure.

Why functional grounding, not geometry

The conceptual basis of the taxonomy fixes the scope of the verification claims it can underwrite. A geometry-based taxonomy classifies a space as a bedroom because it is rectangular and falls between nominal area bounds, but geometry alone does not determine which accessibility requirements apply: a twelve-square-metre room that opens to the hallway and holds a bed has different obligations from a twelve-square-metre secondary living area. The present taxonomy grounds membership in primitive profiles instead. A space is a Bedroom module because the clauses governing it activate the room, activity, and quality combination — because its requirements address what occupants must do there and what the space must afford to support those actions. Its geometric specifications enter as has_quality assertions within the module, so modifying a bedroom’s floor area within its declared degrees of freedom does not reclassify it; it triggers only re-verification of the affected quality assertions. This severs the chain that Chapter 2, Section 2.6 identifies as the source of rigidification in monolithic representation, where changing geometry forces type-reassignment and full re-verification, and it is the architectural basis for Proposition 2’s bounded-verification-scope claim, whose full demonstration is deferred to Chapter 10. Functional grounding also answers DC-2 (institutional compatibility): practitioners already organise compliance work by space function, so a taxonomy mapped onto those functional units is expressible in the vocabulary they already use.

The taxonomy instantiates the three planes of the stratified discrete substrate of Chapter 3, Section 3.4. The primitive-plane-dominant modules — Entry, Circulation, External — carry the metric substrate and govern the conditions under which spaces are connected and traversable; accessible connectivity is a prerequisite for accessible function, so a plan that fails entry or circulation fails for every downstream space. The configurative-plane-dominant modules — Sanitary, Bedroom, Living, Kitchen, Service — carry functional identity and govern whether spaces support their specified activities, presupposing that the connectivity modules have been verified. The interactive-plane-dominant module — Dwelling — carries context and cross-space relations and conditions the verification scope of all the others. The alignment yields a natural verification ordering, primitive-plane before configurative-plane before dwelling-aggregate, which Section 6.3 formalises as a sequence constraint and Chapter 7 encodes in the grammar. Three taxonomy commitments are therefore fixed: the nine types are a closed taxonomy admitting no new type without cluster-level corpus evidence; the primitive profile, not geometry, is the normative basis for instance classification; and the planimetric-triad verification ordering is a structural commitment of the system.¹⁹

Constituent elements of each module type

A taxonomy assigns a space to a type; it does not yet say what a complete description of that type must contain. The constituent specification supplies that internal contract — which elements are required, which optional, how many of each may appear, and what relational constraints must hold among them — and it is the layer that turns each type from a named category into a verifiable unit. It defines completeness (a module instance is complete when all required elements are present and all composition constraints are satisfied), modularity scope (the within-module element set against which Axiom 2’s interaction differential is measured in Section 6.3), and degrees of freedom (the optional elements and cardinality ranges within which instances may vary).

The specifications are derived per type from corpus frequency and relation-pattern evidence, by the same logic as the taxonomy but applied within each type’s clause subset. An element is required if its primitive is active in at least ninety per cent of the type’s clauses — the corpus-linguistic convention for near-universality — optional if active in twenty to eighty-nine per cent, and incidental if below twenty per cent.²⁰ The ninety-per-cent threshold is a transparent design decision, not an estimated cut-off, and varying it between eighty-five and ninety-five per cent reclassifies at most two elements across all nine types without altering the taxonomy or the constraint inventory. Cardinality bounds are the smallest and largest counts observed in the type’s clauses, with “n” marking the absence of a corpus-evidenced upper limit. A composition constraint is hard — its violation makes the instance invalid — when its relation is required in at least ninety per cent of the clauses that include both linked entities, and soft — its violation raises a governance flag rather than a rejection — when the relation applies in fifty to eighty-nine per cent. The required and optional elements for all nine types are held intact below as the normative specification an examiner can check type by type.

The composition constraints carry the relational structure each type’s clauses require, and because they are the conditions against which completeness is evaluated they are stated here type by type rather than in summary. The three connectivity types govern traversal. Entry requires that every opening link to the entry space through exactly one opens_to relation; that every path carry at least one connects link to that space; that every quality attach via has_quality to a space, path, or opening; and that the context link via is_a to a declared design category — and, where present, that a level change carry a threshold-compliance has_quality on its associated opening, and that any boundary be linked to an opening via bounded_by. Circulation requires that every path carry at least two connects links to distinct endpoints, since a path with one connection is a dead end and not a circulation element; that every opening carry exactly one opens_to to a path or space; that every quality attach to a path or opening; and that, where a level is present, at least one path carry a located_at_level link to each declared level for multi-storey compliance, while a junction space, if present, carry at least two connects links as a soft constraint. External requires that every path connect to an external space or to an opening in an adjacent Entry module; that every space carry a minimum-area has_quality; that the context link via is_a to a category; that the level be referenced by located_at_level from at least one path; and, softly, that any boundary be linked to a path or space via bounded_by.

The five function types govern what spaces afford. Sanitary requires that the room carry a floor-area has_quality; that every fixture carry at least one dimensional or performance has_quality and at least one serves_role declaring its functional assignment; and that every activity link via supports_activity from the room or a fixture, since an unlinked activity is semantically inert — with element qualities checked softly and any context bound via is_a. Bedroom requires that the room carry both a minimum-floor-area and a turning-circle (or equivalent manoeuvre-space) has_quality, and that every activity link via supports_activity from the room, with fixture qualities checked softly and any context bound. Living requires that at least one activity link via supports_activity from the room, that at least one dimensional has_quality attach to the room, that any open-plan space carry a connects link to the room, and that any relation link an entity in this module to an entity in a different module instance, since a relation looping within one module is redundant. Kitchen requires that every fixture and every element carry a has_quality, that at least one element (the bench or counter) be linked to the room via part_of, and, softly, that any activity link via supports_activity. Service requires that the room carry an access-clearance has_quality, that every element carry a has_quality, and, softly, that any fixture do likewise. The aggregate type completes the set. Dwelling requires that the dwelling carry exactly one is_a to a declared design category through its context, since a dwelling without a declared category cannot be evaluated; that every declared level be referenced by located_at_level from at least one space, room, or path, so that no phantom level creates unverifiable scope; that a multi-storey dwelling include a Circulation instance spanning all levels unless a dedicated lift is declared; that every relation link entities in at least two distinct module instances, cross-module relations being the sole business of the dwelling module; and that any dwelling-level quality attach via has_quality to the dwelling itself.

Across the nine types these number thirty-two hard composition constraints, averaging 3.6 per type — the conditions against which completeness is evaluated — and eleven soft constraints, which raise a governance flag rather than a rejection, consistent with the residual-governance protocol inherited from Chapter 5. A module instance that violates a hard constraint is invalid and may not enter the library or be submitted for verification; a soft violation flags the instance for review.

A further tier governs how module instances compose into a dwelling. Three cross-module composition constraints apply. Dwelling completeness requires at least one instance each of Entry, Circulation, Sanitary, Bedroom, Living, and Dwelling, with Kitchen, Service, and External required for the Fully Accessible and Robust design categories and optional for Livable — a reflection of the SDA’s own structure, which treats entry, circulation, sanitary, bedroom, and living as universal obligations. Interface adjacency requires that module instances sharing an opening or path connection declare it bilaterally: if one module asserts that its path connects to another’s space, the second must carry the matching bounded_by or opens_to assertion at the interface, since a unilaterally declared connection creates a contract gap the notation of Chapter 7 cannot resolve — this is the spatial instantiation of Axiom 4 (governed exchange). Level consistency requires that level entities be owned by the Dwelling module and referenced, never duplicated, by other modules, so that no shadow level entity can create an unresolvable attribution conflict in verification.

Two constituent commitments are thus fixed. The hard composition constraints are non-negotiable for completeness, giving every module a declared, enforceable internal structure rather than a typological label alone, which operationalises Axiom 1. And the cardinality bounds are the declared degrees of freedom defining the space of valid instances: a library entry is valid if and only if all required elements are present within their bounds and all hard constraints are satisfied, while optional elements may vary provided their soft constraints are met or flagged. On this basis, Section 6.3 specifies the interaction rules that govern the relationships between module instances across their boundaries.²¹

The constituent specifications of Section 6.2 fully determine what makes a single module instance complete and internally consistent. They say nothing about the relationships between instances — when a change in one module is permitted to affect another, when adjacent modules must share entity descriptions with consistent meaning, and when verifying one module obliges the re-checking of another. Governing those inter-module relationships is the work of the interaction rules, specified here as contracts of three types following the interface architecture of Chapter 3, Section 3.3. The semantic interface is the meaning-preservation contract, governing the consistency of primitive assignments at boundaries. The transformation interface is the change-propagation contract, governing which alterations within a module’s degrees of freedom cross to its neighbours. The verification interface is the re-checking-scope contract, governing which modules must re-verify when a module’s properties change. The three are logically distinct categories of inter-module relationship and together constitute a complete governance specification for module interaction.

The three types operationalise two of the four axioms at the inter-module level. Axiom 4 (governed exchange) requires that cross-module interactions occur only through declared interfaces; the semantic and transformation contracts are the declarations that render every cross-module interaction governed rather than implicit. Axiom 2 (interaction differential) requires that within-module interaction density exceed cross-module density; the transformation and verification contracts fix precisely which interactions cross a boundary, which lets the differential be measured. Before the contracts are specified, one forward dependency must be named, because it constrains how the contracts are written.

How Chapter 7 will realise the three interface types

The three governed-kernel interface types are not the surface vocabulary that a notation user will encounter. Chapter 7’s PlaniSyn grammar realises them through four interaction types — engaging, coupling, entangling, and encasing — each addressing a distinct configuration of how two module instances may share or transmit a boundary entity. Engaging realises a semantic interface plus a localised verification trigger; coupling realises a semantic plus a transformation contract; entangling realises all three simultaneously; and encasing realises a semantic plus a contained transformation that suppresses the verification trigger. This four-to-three mapping is governed by Handoff Contract HC-6D (Interface Type Expressibility) and is a notation-level decomposition of the configuration space the three types collectively span, not an expansion of the governed-kernel vocabulary, which the closure rule of Section 6.1 prohibits. Each Chapter 6 interface contract therefore governs one or more of the four Chapter 7 interaction types, and the contracts below are written so that HC-6D can map them without renegotiation.

The modularity admission test

The interface contracts specified below complete Layer 2 of the Governed Kernel Architecture — the layer at which modularity is earned rather than assumed. Clustering (Section 6.2) identifies candidate modules; the Modular Contract System admits them. A candidate cluster is admitted as a module contract only when it passes eight tests, drawn directly from the operating definition of modularity. One, element admissibility: every constituent is a Layer-1 element — a primitive, an operator, or a generated composite — so nothing enters a module that the grammar cannot generate. Two, declared frame: the frame of analysis is stated; here it is representational governance under adaptation-heavy housing change, not physical prefabrication. Three, interaction differential: the cluster’s internal interactions are stronger or more frequent than its external ones, the evidence for which is the interaction-differential calculation of this section. Four, functional boundary: the cluster has a boundary that governs exchange, not one that merely divides space. Five, finite expressed interfaces: every intended exchange across that boundary is finite and declared through one of the three interface contracts, with no hidden exchange. Six, constraint closure: the cluster satisfies its required constituents, hard constraints, and cross-module rules (Section 6.2). Seven, verification closure: the cluster specifies what is checked, when, and how far verification propagates. Eight, role stability: the cluster sustains a stable role within the dwelling whole and cannot silently become another module through variant drift. The nine module types of Section 6.2 are, on this reading, not categories admitted by clustering alone but candidate contracts that pass all eight tests; the contracts below supply tests four through seven.

The three interface contracts

The semantic interface rests on three rules. The shared-entity rule requires that any entity referenced in more than one module carry the same primitive assignment in every module that references it: an opening that serves as both the Entry module’s door and the Circulation module’s access point is an opening in both, and neither may reclassify it as a boundary to fit its own composition more neatly, because reclassification would make the same physical entity two different conceptual things depending on which module addressed it. The entity-ownership principle assigns authority to the module in whose specification the entity is a required rather than optional element, with ties resolved to whichever module initialises the entity first in the verification sequence; the non-owner references the entity by its stable record_uid rather than duplicating it. The vocabulary-closure rule forbids any boundary composition from introducing an entity term outside the closed stratified vocabulary — a multi-module path that passes through three instances does not invite a new corridor_segment primitive, but remains a path whose context-specific accessibility specifications are carried by has_quality and context assertions. Twelve active boundary pairs are inventoried below with their shared entity types, owner module, and dominant semantic risk; the most systematic risk across the inventory is the reclassification of opening entities as boundary entities, which would lose the directional opens_to relation the verification interface depends on, and the second the duplication of a level entity in the External–Dwelling and Dwelling–all pairs rather than its reference, which the level-consistency constraint of Section 6.2 addresses.

The transformation interface distinguishes contained from propagating changes. The containment rule holds that a change to a module’s optional elements, or to a required element’s value within its cardinality bounds, is resolved entirely within the module with no cross-module re-checking: revising a bedroom’s floor-area quality from twelve to fourteen square metres is contained, because the bedroom’s boundary entities are unchanged. The propagation rule holds that a change to a required boundary entity — one shared with an adjacent module — propagates to every module that shares it: if an Entry module’s opening changes its clear-width quality below the minimum the adjacent Circulation module requires, the change propagates and triggers re-checking there. The distinction is the concrete mechanism behind the lower-verification-burden claim, because a monolithic representation pre-declares nothing about a change’s scope and so cannot, without re-checking, establish that a given change does not propagate. The containment boundaries are specified per module type — Sanitary fixture and room qualities are contained unless the fixture is a shared boundary entity; Bedroom room and activity changes are fully contained; Dwelling has no containment, since as the governance module all its changes propagate to the sub-modules it conditions — and the pattern across the eight space-specific types is the same rule applied to each type’s particular boundary inventory.

The verification interface specifies the re-checking scope a change triggers, through the localisation principle (a contained change triggers re-checking only within the modified module), the cascade rule (a propagating change triggers re-checking only in modules that reference the changed entity, terminating at the first module that does not), and the sequence constraint set out below. Three representative boundary contracts show the pattern. At the Entry–Circulation boundary, a change to the entry opening’s clear-width quality triggers re-checking of the Circulation opening’s clear-width constraint only, and propagates no further. At the Circulation–Sanitary boundary, a corridor-width change triggers Sanitary re-checking only if it affects the shared doorway, while a change to the Sanitary room’s floor area or turning circle is fully contained. At the Dwelling–all boundary, a design-category reclassification triggers re-checking in every module whose specification includes a context element — the one category of change that legitimately cascades broadly, because it alters the applicable requirement set for category-conditional modules.

The interaction differential

Axiom 2 requires that within-module interaction density exceed cross-module density for every active boundary. The interaction differential is the ratio of the pooled within-module relation density of a boundary pair to the cross-boundary relation density between them, computed from the corpus as integer counts of relation instances over ordered entity pairs. The density-ratio treatment follows the coupling–cohesion measures of the Design Structure Matrix literature, where modularity is operationalised as the ratio of intra-cluster to inter-cluster dependency density.²²²³²⁴ Across the twelve active boundary pairs the differential exceeds one everywhere, ranging from 13.2 at the Living–Kitchen boundary — the most integrated functional boundary, where open-plan layouts raise cross-boundary density — to 34.1 at the Living–External boundary, the most loosely coupled. The Circulation module shows the highest within-module density, consistent with its role as the dwelling’s connectivity hub carrying six of the twelve active boundaries. Even at the minimum the differential is an order of magnitude above the Axiom 2 threshold, which confirms that the taxonomy’s boundaries separate genuinely high-interaction zones from low-interaction ones rather than dividing a uniformly interactive corpus.

These figures are deterministic computations over the closed 611-clause corpus and the closed stratified vocabulary, and they are not sample estimates. A point estimate drawn from a sample of an open semantic space would warrant a confidence band, because a different sample would yield a different estimate; the interaction differentials are not quantities of that kind. The within-module density of each module type is the exact ratio of its relation instances to its ordered entity pairs, and the cross-boundary density is the exact ratio of cross-boundary relation instances to the ordered entity pairs spanning the boundary; both numerator and denominator are integer counts over a fixed input, so the ratio is a deterministic function of the corpus and is not subject to sampling variance that would warrant a confidence interval. The SDA Design Standard is the population of regulated accessibility obligations under the Australian scheme, not a sample drawn from a hypothetical superpopulation of accessibility standards, so resampling the corpus would only re-derive the same figures rather than estimate a wider distribution. The relevant uncertainty bound on the differentials is the derivation pipeline’s overall coverage — the holdout evidence of Section 6.1 — rather than an interval on each cell; the minimum of 13.2 and maximum of 34.1 are exact figures conditional on the corpus and the vocabulary, and would move only if the corpus were replaced (the cross-corpus work deferred to Section 6.5) or the vocabulary revised.

The verification sequence

The planimetric-triad alignment of Section 6.2 yields an ordering among the types — primitive-plane modules (Entry, Circulation, External) before configurative-plane modules (Sanitary, Bedroom, Living, Kitchen, Service) before the interactive-plane module (Dwelling) — and the ordering is a hard constraint, not a workflow preference, because it reflects a logical dependency. A configurative-plane module presupposes verified connectivity: a sanitary module cannot be meaningfully evaluated for compliance if the corridor providing access to it has not been verified, since an unverified corridor might fail its turning-circle or doorway-width requirement and render the bathroom inaccessible regardless of its internal specification. The dwelling module presupposes individual module verification, because a cross-module relation asserting that the accessible bathroom is on the same level as the accessible bedroom cannot be evaluated until both module instances are verified. The constraint is embedded in the verification contracts as a dependency check: a configurative-plane verification proceeds only once all primitive-plane modules for the dwelling are in a verified state, and a dwelling-module verification only once all eight space-specific modules are. Chapter 7 will encode the ordering as grammar precedence annotations and Chapter 9 as an execution-order rule.

Six conditions for manageable change

The framework addresses the six conditions for manageable change that Chapter 2, Section 2.8 identifies as the operational requirements for housing adaptation to remain tractable over a dwelling’s life, and it does so by a named mechanism for each rather than by the abstract architecture of modularity. Containment is met by the containment rule, which guarantees that any change within a module’s optional elements or cardinality bounds resolves within the module. Manageable interface load is met by the twelve-pair boundary map together with the confirmed differential, since the boundaries exist at genuinely low-coupling zones. Limited coordination span is met by the entity-ownership principle, which confines cross-module coordination to the specific shared boundary entities. Incrementality is met by the verification sequence, which lets a change at any tier be verified without re-triggering the full sequence. Reversibility is met by the localisation principle and the ownership protocol together, since a contained change can be retracted within cardinality bounds with no downstream state to unwind. Absorptive capacity is met by the vocabulary-closure rule, since the stratified vocabulary and ten-operator layer are finite and pre-declared, so practitioners operate over a known, bounded set rather than an open-ended semantic space.

Two interaction-rule commitments are fixed and inherited downstream. The containment rule is the primary mechanism for bounded verification scope and the architectural basis for Proposition 2, whose full demonstration is the contribution of Chapter 10 but whose enabling rule is established here. And the verification sequence constraint is a hard structural property to be encoded by Chapter 7’s notation grammar and Chapter 9’s generation algorithm. On this basis, Section 6.4 specifies the Governed Instance Library: the governed package of governed-kernel definitions and governed instances that deploys the architecture as a usable resource.²⁵

The Generative Grammar of Section 6.1 and the Modular Contract System of Sections 6.2 and 6.3 together constitute the governed kernel — Layer 1 and Layer 2 of the Governed Kernel Architecture. This section specifies the third layer, the Governed Instance Library, and validates the assembled system. The kernel supplies the design rules of the architecture: in Baldwin and Clark’s terms the commitments established early, adhered to broadly, and revised only under governed conditions, within which concrete instances may vary.²⁶ What the kernel lacks is an instance environment: an organisation of baselines, variants, provenance, and supersession into a form downstream artefacts can consume without reaching back into the derivation procedure or the corpus. The Governed Instance Library supplies that environment, and it is the home of the engine — the place where the governed kernel and its governed instances are declared as a deployable resource, and where the publish/hide partition the chapter has been building becomes a working architecture.

The library is a governed package with two structurally distinct components. The governed kernel holds every specification downstream artefacts may not unilaterally modify: the stratified entity vocabulary and the ten-operator relation layer (Layer 1), and the nine module contracts with their constituent specifications, the thirty-two hard composition constraints, the three interface types, and the verification sequence (Layer 2). Its stability guarantees that the notation of Chapter 7, the procedural generation of Chapter 9, and the demonstration of Chapter 10 all read a common, non-diverging semantic foundation. The kernel is governed, not frozen: downstream artefacts may not alter it, but the kernel itself is revisable through the promotion path of Section 6.4 — rule-bound, evidence-based, versioned, and auditable. Its stability is disciplined revisability, not immobility. The Governed Instance Library holds the entries — specific, named instantiation configurations that populate the module contracts with concrete accessibility specifications, free to vary within the kernel’s declared degrees of freedom, addable and revisable in response to regulatory change without any modification to the kernel. This three-layer architecture operationalises the Chapter 3 platform commitment at the artefact level, and it discharges DC-1 (negotiability), since a revision of the SDA Design Standard is incorporated by updating or adding entries rather than reconstructing the kernel, and DC-3 (revisability), since what is fixed and what is variable — and the governed path by which the fixed may change — is declared in advance rather than left implicit.

The governed kernel: a grounded derivation hierarchy

The governed kernel is not a flat set of commitments but a strict derivation hierarchy, each stratum grounded in a section of this chapter and each carrying its own stability rationale. The Generative Grammar (Layer 1, Section 6.1) holds the seven primitives, seven composites, and ten relation operators; revising it requires new corpus evidence that a term carries zero information or that a new requirement category is unclassifiable under the existing grammar. Within the Modular Contract System (Layer 2), the module taxonomy holds the nine module contracts with their cluster-derived profiles (Section 6.2); revising it requires new clustering evidence for a different cut or a new space type with a distinctive profile. The constituent specifications hold the required, optional, and cardinality declarations and the thirty-two hard constraints; revising them requires new frequency evidence that a previously optional element has become universal or a required one merely conditional. The interaction rules hold the three interface contracts, the differential evidence, and the verification sequence (Section 6.3); revising them requires a change in the constituent specifications or in the planimetric-triad dependency structure. The grammar grounds the taxonomy, which grounds the constituent specifications, which ground the interaction rules, so no higher stratum can be revised without first confirming the lower strata remain stable. This grounding is what makes “governed” a substantive claim rather than an administrative one: the kernel is stable because it is grounded, and a change in the ground conditions, carried through the promotion path of this section, is the only legitimate basis for kernel revision.

Library entries and the minimum library

Each Governed Instance Library entry follows a standard schema of eight mandatory fields — a unique entry_id, the module_type, the design_category, the required_elements and optional_elements instantiations, a consolidated quality_assertions list with semantic-subgroup annotation, a constraint_status recording whether all hard constraints are satisfied, and an sda_provenance reference to the source clauses — and three optional fields, configuration_notes, superseded_by, and variant_of. The schema is designed to be machine-processable for Chapter 9’s validation and practitioner-legible for cross-reference against the printed standard, which discharges DC-4 (tractability). A representative entry for a Fully Accessible sanitary module illustrates the form.

Entry ID: SAN-FA-01 · Module type: SAN · Design category: FA Required elements: room (1; has_quality: minimum floor area 4.4 m²); fixture (grab_rail ×2 — beside toilet and shower, each has_quality: diameter 32–38 mm, length ≥600 mm; basin ×1, has_quality: height 720–820 mm adjustable; shower_base ×1, has_quality: clear floor ≥1200 × 1200 mm); quality (turning_circle ≥1500 mm diameter; contrast_ratio ≥30% LRV differential for grab rails); activity (toilet_transfer and shower_transfer supported_by room) Optional elements: element (shower_curtain_track, has_quality: ceiling-track hoist provision); context (FA: is_a Fully Accessible) Constraint status: True (all hard constraints satisfied) · SDA provenance: clauses D4.1, D4.2, D4.3, D4.6, D4.8

The minimum library required for Chapter 7 to formalise the notation and Chapter 9 to operationalise generation is twenty-five baseline entries, covering every module-type and design-category combination for which the standard specifies distinct requirements. The count is ENT 3, CIR 3, SAN 3, BED 3, LIV 3, KIT 2, SVC 3, EXT 2, DWL 3, totalling twenty-five; equivalently, by category, Fully Accessible 9, Robust 9, Livable 7. Kitchen and External take only two categories because the standard’s Livable tier specifies no dedicated kitchen fit-out or separable outdoor-area provisions, a scope reading corroborated by the broader Australian accessible-housing framework.²⁷²⁸ Non-standard configurations — combined wet areas, open-plan layouts, multi-storey variants — are represented by variant entries that reference a baseline through the variant_of field and add only the optional-element configuration that distinguishes them, which operationalises Proposition 4: the platform accommodates variant configurations through instance addition without modifying the governed kernel.

Governance rules

Six rules regulate the library’s evolution without threatening the kernel. Kernel-protection forbids any entry from modifying the governed kernel; an entry that specifies a value inconsistent with the grammar, uses a relation outside the closed ten, or declares a type outside the closed nine is automatically constraint_status False and cannot be deployed, which enforces Axiom 4 at the library level. Provenance traceability requires every quality assertion to carry a valid sda_provenance reference, so that any assertion traces to its governing clause and entries whose provenance clauses change on revision can be identified for review; this is the data-provenance discipline that distinguishes governed variation from undocumented drift.²⁹³⁰ Entry supersession requires that a revised entry mark its predecessor superseded_by rather than delete it, preserving an auditable, versioned revision history (discharging DC-3). Variant governance — Rule 4 — requires that a variant differ from its parent only in optional elements; a variant that modifies a required element, such as reducing a minimum floor area below the corpus-derived bound, is treated as a new entry with its own provenance, not a variant. This is contract-governed substitutability in the sense of design-by-contract: a variant is admissible only where it honours the parent contract’s preconditions, postconditions, and invariants, so that it can stand in for its parent without violating any obligation the parent guarantees.³¹³² Two further rules keep the layers distinct. The no-leakage rule forbids category error across the architecture: instance-specific variation may not redefine a module contract or the grammar (no upward leakage), the grammar may not contain library-specific implementation detail (no downward leakage), and an interface obligation may not be hidden as an internal module parameter (no lateral leakage). The promotion rule states what to do when a proposed change exceeds the instance layer’s degrees of freedom: a variant that changes a required constituent, a hard constraint, an interface obligation, a verification trigger, the dominant interaction profile, or a module’s role identity is not an instance variation but a module-contract issue, and must be promoted to Layer 2; a Layer 2 revision that requires a concept not generable from the existing grammar, or a relation the operator register cannot express, must in turn be promoted to Layer 1. Rule 4, together with the no-leakage and promotion rules, is the mechanism by which the governed kernel absorbs divergent regulatory pathways at the instance layer — the very move the Chapter 10 fork demonstrates — and the four variant tags exercised there illustrate its reach: HLP (a helper or carer room hosted by the Bedroom module), OFC (an office hosted by the Living module), DIN (a dining variant hosted by the Living module), and LNK (a covered, step-free connecting link hosted by the External module), each a Rule-4 derivation preserving its parent’s required elements unchanged.

The library hands off to Chapter 7 in two parts. The governed kernel is transmitted as the object of formalisation — fixed for the duration of formalisation and not alterable by the notation, though itself revisable through the promotion path — its primitive and relation types becoming the grammar’s terminal symbols, its composition constraints the production rules, and its interaction contracts the structural constraints. The twenty-five baseline entries are transmitted as the instantiation scope within which the notation’s expression rules are validated: notation expressions for specific configurations must produce valid representations of the entries without violating any kernel constraint.

Validation

The constructed system makes four claims testable before the end-to-end evaluation of Chapter 10 — completeness, internal consistency, interoperability, and preliminary support for Propositions 2 and 4 — and a construction-versus-evaluation boundary must be declared before they are tested, because the evidential weight of each test depends on which side of that boundary it falls. Clause-level coverage holds by construction: exhaustive hierarchical clustering necessarily assigns every input clause to exactly one cluster, so re-confirming that the taxonomy covers the corpus it was built from is a sanity check on the derivation, not a discriminating result. The substantive empirical tests are obligation-level coverage, internal consistency across the twelve active boundary pairs, the interaction-differential calculation, and grammar-formalisation interoperability — each of which can fail in ways the derivation does not predetermine. Distinguishing the construction guarantee from the empirical tests follows the methodological standard of Sonnenberg and vom Brocke, who argue that design-science evaluation must separate what an artefact achieves by construction from what it demonstrates against external criteria, because conflating the two inflates the apparent weight of the construction itself.³³ Within the thesis’s design science research methodology, the present validation is the build–evaluate component of the module system’s design cycle: an analytical evaluation against the artefact’s own declared criteria, not the comparative evaluation against a monolithic baseline that Chapter 10 provides.³⁴

Completeness holds at both levels. Clause-level coverage is the construction guarantee above. Obligation-level coverage is the substantive test: the four categories of SDA obligation each have a complete representational pathway — dimensional and performance requirements through has_quality assertions with the appropriate subgroup, presence requirements through serves_role and part_of, and categorical requirements through context and is_a — and the two marginal cases are handled within the existing specifications, cross-space adjacency through the Dwelling module’s relation with located_at_level, and conditional “where provided” requirements through the optional-element mechanism. No clause is left without a pathway. Internal consistency holds: three checks over the twelve boundary pairs — that no entity is typed differently at different boundaries, that every propagating change one module declares is acknowledged by its neighbour, and that no verification trigger runs backward through the sequence except the legitimate design-category cascade from the Dwelling module — all pass, so the semantic, transformation, and verification contracts contain no contradiction. Interoperability holds: the governed kernel satisfies Chapter 7’s formalisation preconditions, since the vocabulary and module types are finite and non-recursive, the constituent specifications express as production rules, and the interaction rules express as well-formedness constraints; and it satisfies Chapter 9’s generation preconditions, since the system is decidable over a finite entity and relation inventory, the constituent specifications implement as precondition checks, and the verification sequence implements as a topological sort over the module dependency graph.

Five preliminary demonstrations establish that the engine’s mechanisms are operational, while leaving their comparative magnitude — and the decisive fork — to Chapter 10. For Proposition 2, two demonstrations span the relevant cases. A contained change, raising the Sanitary turning circle from 1500 to 1600 mm, touches no shared boundary entity, so under the localisation principle it triggers two within-module constraint checks and no cross-module re-checking. A propagating change, widening the Entry door from 860 to 1000 mm, modifies a shared Entry–Circulation boundary entity, so it triggers a bounded cascade of two Circulation constraints that terminates at Circulation, since no other module’s contract references the entry opening. A monolithic representation faced with either change can establish that it does not propagate only by re-checking, because it pre-declares no scope; the module system makes non-propagation a derivable property of the interface contracts. For Proposition 4, two demonstrations span both accommodation classes. A regulatory revision — a new requirement for height-adjustable kitchen benches — is absorbed by superseding KIT-FA-01 with KIT-FA-02, using only existing primitives and relations, leaving the governed kernel untouched. A design-configuration variant — an open-plan kitchen–living layout — is absorbed by two variant entries that mark the dividing boundary absent and share a transition space, again leaving the kernel untouched. For Proposition 3, the verification interface contracts make a verification claim checkable by a determinate procedure with a fixed termination condition: confirming that SAN-FA-01 satisfies the Fully Accessible bathroom requirements means enumerating the Sanitary module’s six hard constraints, evaluating each against the entry’s listed quality assertions, and confirming the context match — whereas a monolithic representation reconstructs the applicable constraint set at each verification request and so offers no comparable structural fixity, and two verifications of the same plan against the same standard may reach different conclusions because each reconstructs a different set. Each demonstration shows the mechanism in the architecture; none quantifies the burden difference, which is Chapter 10’s contribution.

The three validation criteria are satisfied and the module system is ready for handoff. On this basis, Section 6.5 consolidates the chapter’s contribution, states its limitations, and specifies the formal handoff contracts to Chapter 7.³⁵

This chapter transformed the governed triplet substrate of Chapter 5 into a compositional module system, through a derivation that ran from vocabulary to taxonomy to constituent specifications to interaction rules to a packaged library, with each stage grounded in the SDA corpus and each producing a specification layer the downstream artefacts inherit rather than reconstruct. The contribution is best stated as one architectural claim rather than a list. The module system is the thesis’s modularity engine, a three-layer Governed Kernel Architecture: a nine-type governed kernel with bounded interfaces and Rule-4 instance variation, an architecture whose variation lives in the governed instance library while the kernel stays fixed for any given configuration yet remains revisable through a governed promotion path. The five results below are not five independent contributions competing with the five-artefact suite; they are the five evidence-bearing layers through which that single claim is specified. The claim’s decisive empirical demonstration — a single dwelling forking at one state into two regulatory pathways, both absorbed in the governed instance library without the kernel moving — is the work of Chapter 10, and this chapter does not pre-empt it; the chapter’s task is to make the engine inspectable, buildable, and ready to be demonstrated.

The five layers are these. A corpus-derived stratified vocabulary — seven schematic primitives and seven elaborated composites, related through a ten-operator layer — supplies the engine’s semantic layer; it is compact, covers the corpus completely, is grounded in independently developed schemas for sixty-four per cent of its terms, and extends into accessibility-domain semantics through five thesis-specific terms justified by ablation necessity. The accessible-housing classification frameworks alongside which it sits — the SDA’s own section-based organisation, the AS 1428 suite, the NCC Volume One performance requirements, the UK Building Regulations Part M category structure, and ISO 21542 — organise requirements by administrative convention; what the Governed Kernel Architecture adds is a vocabulary derived from corpus evidence and validated against it. A primitive-profile taxonomy of nine module types supplies the spatial layer; its functional-geometric distinction — type fixed by primitive profile, not dimensions — severs the monolithic-representation rigidification that Chapter 2 identifies as the root of documentation friction in accessible housing. A constituent specification of thirty-two hard composition constraints and cardinality bounds across the nine types supplies the completeness layer, enabling module-level evaluation without re-reading the full standard for each instance, and avoiding both the over-specification that treats every element as required and the under-specification that leaves completeness unassessable. A three-interface-type governance framework supplies the interaction layer, with an empirically verified interaction differential (13.2 to 34.1 across the twelve boundary pairs) confirming that the taxonomy’s boundaries are genuine high-cohesion, low-coupling modularity boundaries, and a verification sequence derived from the planimetric triad’s dependency structure. A governed library architecture supplies the deployment layer, its platform-separated governed kernel and governed instance library, governed by six explicit rules (including the no-leakage and promotion rules), providing a maintainable structure for absorbing regulatory revision without rebuilding the semantic foundation — the structural basis for Proposition 4, the home of the Rule-4 complement-variation mechanism, and the discharge of DC-1 and DC-3. This is the first operationalisation, in this thesis, of platform modularity at the artefact level for accessible housing representation.

Limitations

Six limitations bound the chapter’s claims, and they are declared rather than concealed.

Single-corpus derivation. The vocabulary and taxonomy are derived from the Australian SDA corpus; the holdout of Section 6.1 tests generalisation across partitions of that corpus, not across independent standards. Cross-corpus validation against a comparator such as the New Zealand or ISO/IEC accessibility provisions is post-submission future work, not a pre-submission completion requirement, and the vocabulary’s closure rule does not prevent cross-corpus extension — it prevents arbitrary extension without corpus evidence.

Intra-artefact validation only. The validation of Section 6.4 confirms completeness, consistency, and interoperability within the system’s own specifications; it does not establish that the system produces lower verification burden than a monolithic comparator under matched conditions, which is Proposition 2’s claim and requires the controlled evaluation of Chapter 10. The structural demonstrations show the mechanisms operating but do not quantify the difference.

Deferred relation decomposition. The has_quality relation carries 67.1 per cent of corpus triples across four semantic subgroups; the case for retaining a single annotated relation rather than decomposing it rests on clause-boundary preservation and contract simplicity, and is accepted for the present scope, with the decomposition question left genuinely open for cross-corpus evidence.

Minimum library only. The library specifies twenty-five baseline entries; full population across the range of non-standard configurations observed in practice is a scope decision, not a structural gap, since the governance rules suffice for any future population and the twenty-five baselines suffice for the Chapter 7 formalisation and Chapter 10 demonstration.

Single-pass derivation. The vocabulary, taxonomy, constituents, and interaction rules were derived in a single forward pass with no stage revised on the basis of downstream evaluation, which is structurally appropriate for a corpus-derived artefact whose corpus is fixed ground truth but would be a limitation for an artefact evaluated against user utility; the full iterative cycle is Chapter 10’s contribution, not the derivation pipeline’s.

Differential from corpus, not practice. The interaction differentials measure how often relations cross module boundaries in the governing text, not in actual design workflows; real practice — open-plan designs especially — may produce different boundary-interaction patterns. The differential establishes that the boundaries are low-coupling in the regulatory specification; whether they remain so under varied design scenarios is a field-research question.

Handoff to Chapter 7

Four contracts govern the handoff. HC-6A (Governed Kernel Transmission) transfers the governed kernel as the object of formalisation — fixed for the duration of formalisation, though itself revisable through the promotion path; Chapter 7 may formalise it in any notation that preserves semantic equivalence with the present specifications but may not modify a primitive, type, or cardinality bound, and an irresolvable ambiguity discovered in formalisation is returned as a specification defect rather than resolved unilaterally in the grammar. HC-6B (Governed Instance Library) transfers the twenty-five baseline entries, all with satisfied constraint status, as the instantiation scope against which the notation’s expression rules are validated. HC-6C (Verification Sequence Constraint) transfers the planimetric-triad ordering as a hard structural property the grammar must encode, making it syntactically impossible to place a configurative-plane module expression before a primitive-plane one, or the Dwelling expression before the space-specific ones. HC-6D (Interface Type Expressibility) transfers the three interface contracts as expressibility requirements on the grammar — the semantic interface’s shared-entity rule as a cross-reference constraint, the transformation interface’s containment–propagation distinction as a scoping rule, and the verification interface’s localisation and cascade rules as evaluation-order constraints — which is the basis for Chapter 7’s realisation of the three governed-kernel interface types through its four interaction types.

The module system is ready for formalisation. Chapter 7 receives it and develops the formal notation grammar that makes the compositional structure precisely expressible, enabling unambiguous machine-readable assertion, verification, and generation; the present chapter’s contribution is complete when its specifications are formalised without reinterpretation, and Chapter 7’s task is to achieve exactly that.³⁶

Next chapter: Chapter 7: A Formal Notation for Floor Plans →