Design¶

This section contains the engineering design artefacts that bridge architectural decisions to buildable modules. It is the layer between what we decided (Architecture) and what we built (code repositories).

Design artefacts are produced at two levels of granularity:

Level	Contents	Audience
System design	Cross-domain data models, domain event catalogue, synchronous interface contracts	Architects, tech leads, AI agents doing cross-module work
Module design	Per-module technical design, APIs, fixtures, config, execution plans, drift reports	Module engineers, AI coding agents

How design artefacts relate to the wiki¶

Every design artefact in this section traces back to a canonical wiki entity:

A data model table traces back to the system domain (SD0x) that owns it and the modules that write to it
An event in the catalogue traces back to the emitting module (MOD-xxx) and the capability (CAP-xxx) it satisfies
A contract traces back to the pair of modules it connects and the FRs it satisfies
A module technical design traces back to the module YAML (MOD-xxx) and its requirements list

The traceability chain is:

Business Goals → Capabilities → FRs ──┐
Regulations → Policies → FRs ─────────┼──→ Modules → Design artefacts → Code
System Goals → NFRs ───────────────────┘

See Methodology for the full traceability model.

Agentic development context¶

When an AI agent is assigned to implement a module, it should read in this order:

The module YAML + MD from the systems register (/systems/SD0x-*/MOD-xxx-*.md)
The relevant data model page(s) from System design / Data models
Any contracts the module is party to from Interface contracts
Any events the module emits or consumes from Event catalogue
The module design template to understand what artefacts it must produce
The test strategy to understand what test coverage is required

The module's own design artefacts (technical design, execution plan) are written to the module's code repository and fed back to this wiki via the handoff mechanism.