Requirements - Decision Making & Governance
-
DM07 - Decision Records
All architecture decisions should be documented with a lightweight Architecture Decision Record (ADR), including options considered and clear rationale (e.g. SEQF Any Decision Record Template).
Requirement description
This requirement is concerned with ensuring that significant architecture decisions are documented, understood and traceable.
Architecture decisions should not be stored solely in emails, meeting notes or individual knowledge. The reasoning behind decisions should be recorded, including the options considered, trade-offs assessed and rationale for the selected approach.
The objective is to ensure future teams can understand why decisions were made, challenge assumptions where necessary and avoid repeatedly analysing the same problems.
In simple terms:
Important architecture decisions should be documented in a consistent format that explains what was decided, what alternatives were considered and why the decision was taken.
Scoring rubric table – DM07 Architecture Decision Records (ADRs)
| Score | What it looks like | Typical evidence | Key gaps / risks |
|---|---|---|---|
| 0 | No evidence that architecture decisions are formally documented. |
No ADRs. No decision records. Decisions only reflected in conversations, emails or undocumented agreements. |
Significant service risk. Rationale is lost over time and decisions cannot be effectively reviewed, challenged or revisited. |
| 1 | Limited evidence of decision documentation. A small number of decisions may be recorded but there is no consistent approach. |
Informal notes. Meeting minutes. Incomplete decision records. Unstructured documentation. |
High-risk gaps. Important context is missing and decision history is difficult to reconstruct. |
| 2 | Some architecture decisions are documented and there is evidence of a decision recording approach, but coverage is incomplete and inconsistent. |
Partial ADR set. Some documented options and rationale. Decision logs missing key decisions. Inconsistent templates. |
Significant notable gaps. Many architecture decisions cannot be traced to documented reasoning. |
| 3 | Much of the significant architecture decision-making is documented. Most major decisions include rationale and supporting information. |
Maintained ADR repository. Documented decision rationale. Options considered for major decisions. Links to architecture artefacts and governance discussions. |
Notable gaps remain. Some important decisions may be missing, lack alternatives analysis or have outdated records. |
| 4 | Most significant architecture decisions are documented using a consistent approach. Records are maintained and provide sufficient context for future review. |
Comprehensive ADR library. Consistent ADR template usage. Documented options and trade-offs. Governance references. Architecture artefact traceability. Review dates where appropriate. |
Minor gaps only. Missing records are limited and do not significantly affect architectural understanding. |
| 5 | Comprehensive and exemplar architecture decision management. ADRs are embedded within delivery and governance processes and actively used throughout the solution lifecycle. |
Complete and maintained ADR repository. Consistent decision recording across teams. Clear options analysis and business rationale. Integration with architecture governance activities. Architecture decisions linked to roadmaps, standards and delivery outcomes. Periodic review and update of key decisions. |
Minimal or no significant gaps. Decision history is transparent, reusable and supports continuous improvement. |
What assessors should look for
- Decision coverage – Are significant architecture decisions formally documented?
- Options analysis – Do records show alternative approaches that were considered?
- Decision rationale – Is the reasoning behind decisions clearly explained?
- Consistency – Are decisions recorded using a repeatable format or template?
- Maintainability – Are decision records maintained and accessible to the delivery team?
- Traceability – Can decisions be linked to architecture artefacts, governance activities, requirements, risks or standards?
What separates a 3 from a 4 or 5
A score of 3 typically means that many significant decisions are documented and rationale is generally available, but coverage is incomplete or the quality of records varies between decisions.
A score of 4 requires a consistent and maintained ADR approach. Most significant decisions are recorded, alternatives are documented and decision records can be traced to governance and architecture artefacts.
A score of 5 requires ADRs to be embedded within the delivery lifecycle. Decision records are routinely created, maintained and actively used to support governance, future design work, technical debt management and architecture evolution.
Suggested evidence examples (not SAF-mandated artefacts)
- Architecture Decision Records (ADRs)
- SEQF Any Decision Record templates
- Decision logs or registers
- Architecture repository entries
- Design Authority outputs linked to ADRs
- Governance review records referencing decisions
- Solution Design Overview documents referencing ADRs
- Architecture roadmaps linked to decisions
- Technical debt records referencing prior decisions
- Knowledge repositories containing maintained decision records
Updated: 04 September 2026 (SAF Version 1.1)