Appendix D: Requirements, Grounding, and Traceability

Sub-appendices

D.1 Environmental Grounding Dossier
D.2 Environment-Derived Requirements Register
D.3 Requirements-Design-Evaluation Traceability Matrix
D.4 Evaluation Workbench

Assembled Appendix

D.1 Environmental Grounding Dossier

Environmental Grounding Dossier

Six environment-grounded requirements are derived from the housing access and representation problems diagnosed in Chapter 2 and Chapter 3. Each requirement card records the problem observed in practice and the affected stakeholder groups. Consequence, cost dimension, derived requirement, and acceptance criterion are declared for each entry. Requirements established here provide the evaluative basis for Chapter 4 and the demonstration cases in Chapter 10.

— | — | — | — | — | — | — | — |

ER-01 | Diachronic needs are managed by synchronous artefacts and approvals | Households, disability residents, certifiers | Adaptations trigger repeated reinterpretation of prior intent | Time | Representations must carry change-validity conditions across handovers | Change event can be evaluated through declared checks without full artefact rediscovery | High |

ER-04 | Accessibility intent is not reliably transportable in delivery chains | SDA participants, assessors, policy actors | Feature-level compliance can still fail integrated usability | Physical | Semantics must be encoded as first-class objects, not only geometry annotations | Demonstration cases show route-level and relation-level checks, not only dimensional checklists | Medium |

ER-06 | Platform governance fails when complements evolve without shared rules | Governance teams, toolchain maintainers | Drift, incompatibility, and non-comparable revisions | Time | The governed kernel and the governed instance library must be explicitly versioned and auditable | Evaluation workbench records versioned rule compliance and exception budgets | Medium |

Evidence grounding for each requirement is provided by Chapter 2 (Sections 2.3-2.6) and Chapter 3 (Sections 3.2-3.4). Full traceability is documented in Appendix: Requirements-Design-Evaluation Traceability Matrix. Five cost dimensions are covered, spanning the study’s cost model: real, physical, time, skill, and cognitive. Together, the requirements define a complete problem specification against which the thesis artefacts are evaluated. Therefore, this dossier establishes the evidentiary basis for the evaluation framework in Chapter 4.

D.2 Environment-Derived Requirements Register

Environment-Derived Requirements Register

Six environment-derived requirements are recorded here. Each is grounded in the environmental diagnosis from Chapter 2 and Chapter 3. Each traces directly to the evaluation protocol in Chapter 4 and the demonstration evidence in Chapter 10. Full problem-statement derivations are in Appendix: Environmental Grounding Dossier. Full traceability chains are in Appendix: Requirements-Design-Evaluation Traceability Matrix.

Requirement ID | Environment Derivation Summary | Derived Requirement | Acceptance Criterion |

— | — | — | — |

ER-01 | Diachronic demand versus synchronous artefact governance | Encode lifecycle-validity conditions with each transformation unit | Re-verification can be executed from declared conditions without global reinterpretation |

ER-02 | Cognitive burden from tacit cross-document inference | Publish machine-queryable invariants and interfaces | At least one invariant breach path and one pass path are reproducibly detectable |

ER-03 | Rework/delay from late conflict detection | Shift checks upstream and define baseline comparator | Baseline and artefact workflows are compared with explicit units and thresholds |

ER-04 | Accessibility intent loss in delivery transitions | Preserve semantic intent as first-class representations | Case evidence demonstrates relation-level accessibility checks |

ER-05 | Hidden coupling inflates verification scope | Require finite trigger-to-check mapping per local edit | Each transformation event traces to a bounded check set with escalation rule |

ER-06 | Interface drift and ungoverned complements | Enforce versioned rule compliance with exception governance | Every exception is typed, bounded, and justified against a rule set |

Each requirement row is traceable to a source anchor in Chapter 2 or Chapter 3. Each row links to at least one design feature and one evaluation measure in Chapter 10. Five cost dimensions are covered, spanning the study’s cost model: real, physical, time, skill, and cognitive. Requirements defined here establish the minimum problem scope the artefact suite must address. Therefore, the register functions as the authoritative source of requirement identifiers across the traceability matrix, evaluation workbench, and demonstration evidence appendices.

D.3 Requirements-Design-Evaluation Traceability Matrix

Requirements-Design-Evaluation Traceability Matrix

Full traceability is documented here from environment-derived requirements through design features to evaluation measures. Requirements are drawn from Chapter 2 and Chapter 3. Design features are instantiated in Chapters 5 to 8. Evaluation measures are operationalised in Chapter 4 and tested in Chapter 10. Governance structures are provided by the Environment-Derived Requirements Register and the Environmental Grounding Dossier. Every requirement maps to at least one design feature and one evaluation measure. No orphaned requirement, feature, or measure exists in this matrix. In summary, the matrix links all three tiers of the thesis’s design science logic (problem, solution, and evaluation) into a single auditable chain. Requirement and feature specifications in the first two tables are extended in the final section by evaluation measure specifications.

appendix_d_traceability_flow — **Requirements-design-evaluation traceability: no orphan in any direction** The requirements-design-evaluation traceability matrix rendered as a left-to-right flow, so the no-orphan property is self-evident: six environment requirements connect through nine design features to seven evaluation measures and on to the five propositions (P1 interoperability, P2 transportability, P3 manipulability, P4 transformability, P5 integrated burden), following the nine linkage rows of the matrix below. Every requirement reaches a design feature, an evaluation measure, and a proposition, and every column is reached; no requirement, feature, or measure is an orphan in any direction. After Appendix D (Requirements-Design-Evaluation Traceability Matrix).

Requirement-to-Feature-to-Measure Linkages

— | — | — | — | — | — |

ER-01 | DF-05A-01 | EM-4W-01 | P1 | Ch5 schema serialisation; Ch4 evaluation strategy | EVID-P1-INTERPRETABILITY |

ER-01 | DF-07C-01 | EM-09-01 | P3 | Ch7 encoding/parsing; Ch10 interpretability results | EVID-P3-REPLAY |

ER-02 | DF-06B-01 | EM-4W-02 | P2 | Ch6 interaction rules; Ch4 validity/reliability | EVID-P2-CHECK-SCOPE |

ER-02 | DF-07C-02 | EM-09-02 | P3 | Ch7 formal core; Ch10 modular fit | EVID-P3-INVARIANTS |

ER-03 | DF-05A-02 | EM-09-03 | P5 | Ch5 ambiguity analysis; Ch10 workflow efficiency | EVID-P5-BURDEN |

ER-04 | DF-05A-03 | EM-09-01 | P1 | Ch5 standards schema; Ch10 standards interpretability | EVID-P1-SDA-TRACE |

ER-05 | DF-06B-02 | EM-09-02 | P2 | Ch6 module interfaces; Ch10 modular-fit | EVID-P2-LOCAL-GLOBAL |

ER-05 | DF-08D-01 | EM-4W-03 | P4 | Ch8 procedural pipeline; Ch4 data pipelines | EVID-P4-VARIATION |

ER-06 | DF-08D-02 | EM-09-04 | P4 | Ch8 pre-vetted library; Ch10 discussion of results | EVID-P4-EXCEPTION-BUDGET |

Two summative measures are shared by design, so they appear in two linkage rows each: EM-09-01 warrants both Proposition 1 (standards interpretability) and Proposition 3, which borrows it as replay evidence, and EM-09-02 warrants both Proposition 2 (modular fit) and Proposition 3. Proposition 3 carries no dedicated Chapter 4 formative measure and takes EM-09-01 and EM-09-02 as its two summatives, as recorded in the canonical Property-Proposition-Evaluation Map and the Evaluation Workbench. The repeated appearance is intentional shared warranting, not a cross-wire, and creates no orphan.

Design Feature Specifications

Each design feature below is located in the chapter indicated and satisfies the listed environment requirements. Artefact type and mechanism identify the design object category and primary addressing mechanism. Constraints and trade-offs columns record the design decisions that bound each feature.

— | — | — | — | — | — | — |

DF-05A-01 | 5 | Construct | Interface | ER-01 | Standards semantics must be serialisable and versionable | Higher modelling discipline required upfront |

DF-05A-02 | 5 | Method | Invariant | ER-03 | Ambiguity categories must remain stable across cases | Reduced flexibility for ad hoc labelling |

DF-05A-03 | 5 | Model | Interface | ER-04 | Accessibility semantics must bind to traceable entities | Additional schema complexity |

DF-06B-01 | 6 | Model | Interface | ER-02 | Module contracts must declare valid interactions | Contract maintenance overhead |

DF-06B-02 | 6 | Method | Trigger | ER-05 | Trigger logic must remain finite and explicit | Edge cases require escalation policy |

DF-07C-01 | 7 | Method | Transformation | ER-01 | Replayability must be deterministic within declared bounds | Stricter parser and test-harness constraints |

DF-07C-02 | 7 | Construct | Invariant | ER-02 | Formal core invariants must be executable | Harder onboarding for non-technical readers |

DF-08D-01 | 8 | Instantiation | Trigger | ER-05 | Generated outputs must preserve rule traceability | Throughput may reduce under heavy validation |

DF-08D-02 | 8 | Method | Interface | ER-06 | Library governance requires explicit exception classes | Governance friction for rapid experimentation |

Evaluation Measure Specifications

Each evaluation measure below is operationalised in the chapter indicated. The metric definition, baseline definition, unit, and threshold columns document the measurement protocol established in Chapter 4. The data source column identifies the evidence stream consumed in Chapter 10.

— | — | — | — | — | — | — |

Linkage coverage is complete: every environment requirement in the Requirements Register maps to at least one design feature and one evaluation measure. The full problem-statement derivation for each requirement is in the Environmental Grounding Dossier. Overall, the matrix confirms completeness: every requirement, feature, and measure is linked. No orphan exists in any direction. Evaluation results in Chapter 10 are therefore interpretable as direct evidence against the environment-derived requirements. Post-hoc performance claims are excluded by the pre-declared traceability structure.

D.4 Evaluation Workbench

Evaluation Workbench

Evaluation measure specifications and evaluation question contracts are consolidated here. These documents govern the empirical portion of the thesis. Each measure is defined at the metric, baseline, unit, and threshold level. Chapter 10 results tables are interpretable against these pre-declared expectations. Full traceability is in the Requirements-Design-Evaluation Traceability Matrix. Environment-derived requirements are operationalised here as measurable evaluation contracts. Each contract can be confirmed or refuted by the Chapter 10 demonstration evidence.

Evaluation Measure Specifications

Seven evaluation measures are operationalised across the thesis. The suffix “4W” (and the column label “Ch4w”) denotes the Chapter 4 workbench layer, the measures as defined and pre-registered in Chapter 4, as distinct from their execution in Chapter 10. Measures EM-4W-01 to EM-4W-03 are defined and pre-registered in Chapter 4; measures EM-09-01 to EM-09-04 are executed and reported in Chapter 10.

Measure ID	Chapter	Metric Definition	Baseline Definition	Unit	Threshold	Data Source
EM-4W-01	Ch4w	Interpretation divergence for matched regulatory obligations	Divergence under current synchronous artefact workflow	Divergence rate	Lower than baseline with practical significance	Annotation sheets; protocol logs
EM-4W-02	Ch4w	Local-to-global check scope ratio per transformation event	Scope ratio in baseline non-modular workflow	Ratio	Local scope majority in bounded edits	Change-trace logs
EM-4W-03	Ch4w	Rule-compliant variation yield with exception budget	Variation yield under ungoverned complements	Compliance proportion	Meets pre-registered budget and rationale coverage	Generation logs; exception register
EM-09-01	Ch10	Standards interpretability trace completeness	Baseline trace completeness	Index	Improved completeness over baseline	Ch10 case outputs
EM-09-02	Ch10	Modular-fit evidence with bounded verification signals	Baseline modular-fit without interface contracts	Composite score	Positive bounded-check trend over baseline	Ch10 results tables
EM-09-03	Ch10	Workflow burden delta across time, cognitive, and skill proxies	Baseline burden profile for matched tasks	Delta	Net reduction with stated confidence limits	Ch10 workflow outputs
EM-09-04	Ch10	Exception governance quality in discussion synthesis	Baseline exception handling quality	Quality score	Full typing and justification coverage	Ch10 discussion evidence

Evaluation Question Contract

The five evaluation questions below are defined to organise the measures into clusters that correspond to the propositions tested in the thesis. Each evaluation question maps to a primary proposition (EQ-01↔︎P1; EQ-02↔︎P2; EQ-03↔︎P3; EQ-04↔︎P4; EQ-05↔︎P5), following the property↔︎proposition↔︎EQ alignment established in Chapter 2 §2.9. Each evaluation question is linked to the environment requirements it addresses and the measures that provide the evidence. Overall, the seven measures span all five evaluation questions, and no requirement is addressed by a measure that cannot be observed in the demonstration evidence. Therefore, the evaluation question contracts documented here establish the interpretive framework within which the Chapter 10 results tables are to be read.

Evaluation Question	Requirement IDs	Measure IDs	Expected Chapter Output
EQ-01	ER-01, ER-04	EM-4W-01, EM-09-01	Standards interpretability evidence
EQ-02	ER-02, ER-05	EM-4W-02, EM-09-02	Modular-fit and bounded-check evidence
EQ-03	ER-01, ER-02	EM-09-01, EM-09-02	Round-trip replay + invariant-preservation evidence (EVID-P3-REPLAY, EVID-P3-INVARIANTS)
EQ-04	ER-06	EM-4W-03, EM-09-04	Governed variation and exception evidence
EQ-05	ER-03, ER-05	EM-09-03	Workflow burden comparison evidence (integrated utility)

Requirement identifiers used here are defined in the Environment-Derived Requirements Register and the Environmental Grounding Dossier. Each identifier traces to at least one design feature and one evaluation measure. In summary, the workbench constitutes the pre-registration record for the thesis’s evaluation. All measures, thresholds, and question-to-requirement linkages are declared before demonstration results are interpreted. Chapter 10 results can therefore be assessed against thresholds set independently of observed outcomes.