# Technical Documentation Standards · DOC-03

## Standard Metadata

- Area: Documentation
- Owner: Technical Leadership group
- Last reviewed: 2026-09-09
- Next review due from: 2026-12-01
- Enforcement: Code review
- Status: Active

## The architecture of a system must be documented · DOC-03.1 · **MUST** · **DEV**

This should be documented in the form of one or more architecture diagrams.

## Architecture decision records (ADRs) must be written to record key technical decisions · DOC-03.2 · **MUST** · **DEV/TEST**

ADRs can be included in the main project wiki or in the same repo as the source code (and linked to from the main wiki).

## The hosting location and access must be documented · DOC-03.3 · **MUST** · **DEV**

Possible hosting locations include:
- Audacia CSP hosted
- Client hosted
- Third-party hosted (the third-party must be specified)

Some examples of access that should be documented are:
- Guest accounts in an external Azure tenant
- Separate client-provided accounts
- Any specific access requirements, like a VPN or white-listed IP address

## Environments and system URLs must be documented · DOC-03.4 · **MUST** · **DEV**

**NOTE** This information must be recorded in Olympus.

## Non-functional requirements must be documented · DOC-03.5 · **MUST** · **DEV/TEST**

Examples of non-functional requirements are:
- Performance and response times
- Accessibility
- Device testing requirements (these should be captured in the [Test Strategy](/standards/engineering/engineering-principles/2-quality/test-strategy))
- Logging and observability

## Deployment and release processes must be documented · DOC-03.6 · **MUST** · **DEV**

The kind of processes that should be documented include:
- CI/CD pipelines
- Health checks
- Release windows, i.e. any days/times agreed by the client
- Manual processes (where applicable)
- Rollback procedure

## The branching strategy must be documented · DOC-03.7 · **MUST** · **DEV/TEST**

This should include the overall strategy, the reasoning behind it, and any specific details such as naming conventions, e.g. `release/<yyyy-mm-dd>`.

## Disaster recovery processes must be documented · DOC-03.8 · **MUST** · **DEV**

The following items must be included:
- Agreed Recovery Time Objective (RTO) and Recovery Point Objective (RPO), or if none has been agreed a statement to this effect together with a reference to when this decision was made
- Details of any processes to follow beyond restoring data to a known point, e.g. any manual failover tasks or fallback to paper-based processes
- Details of what backups are taken, at what frequency, to what location, and who owns them

## External resources must be listed and signposted · DOC-03.9 · **MUST** · **DEV/TEST**

For example, Postman collections or JMeter scripts.

## The use of feature switches must be documented · DOC-03.10 · **MUST** · **DEV**

**NOTE** This is only applicable if feature switches are actually in use.

## A regression testing guide must be provided · DOC-03.11 · **MUST** · **TEST**

This should be some signposting to the relevant resources, e.g. an automated test repo and/or Azure DevOps test plan.

A 'state of play' of the automated tests must be documented, covering things like test coverage, which system areas have been targeted and where there are known gaps.

## A troubleshooting quickstart guide must be provided · DOC-03.12 · **MUST** · **DEV**

Include information that will be useful for anyone triaging or debugging an issue, such as where logs are located in each environment.