Target state architecture

The architecture narrative, split by the domains SOW Schedule "A" enumerates. Together these pages are the body of deliverable D2.1 — Target state architecture document.

Each document pairs with the diagrams in diagrams/src/: prose carries rationale and constraints, diagrams carry structure. Neither should try to do the other's job.

Documents

Per SOW Schedule "A" WS 2, activity 3 and the WS 2 deliverable list. Written as each area is worked, not up front.

Page	Covers	Status
vision-and-objectives.md	Architecture vision, objectives, success criteria	⚪
guiding-principles.md	Scalability, security, integration, reuse, maintainability, extensibility	⚪
overview.md	Target state architecture overview — the shape of the whole	⚪
portal.md	Portal architecture — shell, composition, navigation	⚪
application-and-platform.md	Application and platform architecture	⚪
integration-and-api.md	Integration and API architecture	⚪
data.md	Data architecture considerations	⚪
identity-and-access.md	Identity and access management	⚪
security.md	Security posture and controls	⚪
infrastructure.md	Hosting, environments, resilience	⚪
content-management.md	CMS and content operations	⚪
analytics.md	Analytics and measurement	⚪
design-patterns.md	Architectural design patterns applied across the above	⚪
risks-and-considerations.md	Risks, constraints, mitigations	⚪

Progress against these is tracked as WS2-A3 sub-tasks.

Conventions

• Decisions live in the decision log, not inline. These pages describe the target state; the ADRs record why it is that and not something else. A page cites the ADR rather than summarising the trade-off away.
• Unresolved items go in open questions. The SOW requires surfacing what needs client decision or validation. Flagging a real gap is more useful than a plausible guess.
• Where a position came from a recommendation, cite it. The recommendation carries the concern and the argument; the domain page states what the target state is. Restating the argument here is how both pages get worse.
• Cite the source. Where a statement comes from client material, link the relevant client resource page.
• Diagrams are linked, not restated. If a page is describing a topology in prose, it probably wants a diagram instead.

Where to start

Three domains carry disproportionate weight and are worth writing first — identity and access, integration and API, and portal architecture. The reasoning is in the WS 2 task notes.