Decision Finder

Status: Accepted | Date: 2026-07-11 | Review: 2027-07-11

Use this page to find the right starting point for common delivery needs. Start with a reference architecture when one matches the project. Use ADRs directly when you need a specific decision or control.

Reference architectures display their status at the top of each page. Accepted architectures are active project-kickoff guidance. Proposed architectures remain evaluation aids and require explicit project approval, including approval of their Proposed dependencies.

Project Preflight

Before choosing a pattern, record:

• Users, service outcome, accountable owners, critical journeys, and non-goals
• Existing and legacy constraints, agency capability, support model, and budget
• Information classification, privacy, sharing, records, processing locations, suppliers, and offshoring requirements
• Accessibility and assisted-digital needs
• Criticality, service levels, RTO, RPO, degraded operation, and incident coverage
• Migration, interoperability, data/configuration export, rollback, and exit needs

Start by Project Type

Adoption Bundles

Use these bundles to start project discovery, not as universal control sets. Add or remove ADRs according to the preflight, selected architecture variant, and project risk. A Proposed reference architecture or ADR still requires explicit project approval.

Public Website or Content Service

Start with: Accepted Content Management.

Minimum ADR set: ADR 020: Frontend UI Foundations, ADR 016: Edge Protection, ADR 004: CI/CD, ADR 009: Release Standards, ADR 007: Logging, and ADR 014: Backups and Recovery. Add ADR 013: Identity Federation when users or editors sign in.

Kickoff deliverables:

• Service and content brief, audiences, critical journeys, content ownership, publication workflow, and selected architecture variant
• Accessibility and design-system assessment with representative user testing
• Content, media, URL, redirect, integration, records, and retention inventory
• Edge and origin design, release path, service objectives, support model, recovery test, migration plan, and export or exit plan

Agency-Controlled HTTP API

Start with: Accepted OpenAPI Backends.

Minimum ADR set: ADR 003: HTTP API Contract Standards, ADR 004: CI/CD, ADR 005: Secrets Management, ADR 007: Logging, and ADR 009: Release Standards. Add ADR 013: Identity Federation for user delegation, ADR 016: Edge Protection for Internet exposure, and ADR 014: Backups and Recovery for stateful services.

Kickoff deliverables:

• Version-controlled OpenAPI contract, named consumers, ownership, lifecycle, compatibility policy, and deprecation plan
• Exposure and trust-boundary diagram, authentication and operation or resource authorisation model, data classification, limits, and abuse cases
• Contract, behaviour, security, compatibility, and failure test plan
• Service objectives, monitoring, support and incident runbooks, recovery plan, consumer migration plan, and provider-exit record

Data Pipeline or Analytical Data Service

Start with: Accepted Data Pipelines.

Minimum ADR set: ADR 015: Data Pipeline Quality, ADR 018: Databases and Lakehouses, ADR 004: CI/CD, ADR 005: Secrets Management, ADR 007: Logging, ADR 010: Infrastructure as Code, and ADR 014: Backups and Recovery. Add ADR 017: Analytical Publications for bounded publications and Proposed ADR 021: Workload mTLS when approved for Kubernetes-hosted pipeline services.

Kickoff deliverables:

• Source, consumer, authority, purpose, classification, sharing, retention, and processing-location record
• Versioned data contracts, data-flow diagram, quality thresholds, lineage design, quarantine, replay, and reconciliation approach
• Freshness and service objectives, capacity and cost forecast, RTO, RPO, support model, and incident runbooks
• Representative quality, lineage, performance, recovery, migration, interoperability, and exit tests

AI-Assisted Service or Workflow

Start with: Proposed AI-Assisted Digital Services, with explicit project approval, and ADR 011: AI Tool and Agent Governance.

Minimum ADR set: ADR 011: AI Tool and Agent Governance, ADR 001: Application Isolation, ADR 005: Secrets Management, and ADR 007: Logging. Add ADR 004: CI/CD for released software and the ADRs required by the authoritative source service.

Kickoff deliverables:

• Bounded use case, excluded uses, risk tier, accountable human, human decision boundary, and non-AI fallback
• Information classification, privacy, records, supplier, processing-location, offshoring, retention, and threat assessments
• Representative evaluation set with quality, safety, accessibility, security, refusal, and human-review acceptance thresholds
• Prompt and model change controls, monitoring and incident runbook, usage and cost limits, data and configuration export, and provider-exit test

Federated Application Set

Start with: Proposed Federated Application Portal, with explicit project approval. Select only shared capabilities with demonstrated user or operational value.

Minimum ADR set: ADR 013: Identity Federation, ADR 003: HTTP API Contracts for shared APIs, ADR 020: Frontend UI Foundations, ADR 005: Secrets Management, and ADR 007: Logging. Add ADR 012: Privileged Remote Access for administration and ADR 016: Edge Protection for Internet-facing capabilities.

Kickoff deliverables:

• Selected shared capabilities, accountable boundaries, funding and support model, application inventory, direct-access paths, and degraded modes
• Cross-application journeys, accessibility and assisted-digital needs, identity assurance, claim definitions, and application-owned authorisation model
• Versioned API, message, SDK, component, and native-bridge contracts where used
• Trust-boundary and data-flow diagrams, service objectives, onboarding and offboarding checks, resilience tests, migration plan, and exit plan

Start by Capability

ADR Catalogue

This generated catalogue is the authoritative index of ADR status, review dates, and direct dependencies. Dependencies come from each ADR’s synopsis; update the source ADR and run just update-catalogue rather than editing this table.

Quality Checks Before Delivery

Before using a decision in a project kickoff, confirm that:

• The ADR or reference architecture is not superseded
• Accepted ADRs are used as active decisions; Proposed material has explicit project approval and does not silently establish a standard
• The review date has not passed, or the decision owner accepts the risk
• Compliance obligations are checked in Compliance Mapping
• Related ADRs have been reviewed together, not in isolation
• Project-specific deviations are documented in the project record