Architecture Decision Records
ADRs capture decisions between alternatives. Each ADR is short, focused on a single decision, and can be included inline in a FUN using AsciiDoc include::.
States
| State | Description |
|---|---|
proposed |
Under consideration, not yet decided |
accepted |
Decision has been made |
superseded |
Replaced by a newer ADR |
deprecated |
No longer relevant |
Groups
ADRs are categorized by architectural layer:
-
cross-cutting— decisions that affect multiple layers -
hardware— bare-metal provisioning, node OS, GPU -
networking— CNI, load balancing, IPv6, DDoS/WAF -
storage— distributed storage, object storage, backup/DR -
cluster-management— cluster lifecycle, tenant isolation, organizational hierarchy -
platform— API architecture, identity, authentication, authorization, database -
managed-services— plugin lifecycle, upgrade policy -
deployment— GitOps, development tooling -
frontend— framework, styling
How to add an ADR
-
Find the next number by checking existing files in
docs/adr/ -
Create
docs/adr/XXXX-short-name.adocusing the template -
If the ADR relates to a FUN, add an
include::in the FUN at the relevant location
Dependencies
ADRs can depend on other ADRs via the Depends-on field. This forms a directed acyclic graph (DAG) — a decision may depend on multiple prior decisions, and multiple decisions may depend on the same predecessor.
When reconsidering a decision, check which ADRs depend on it to assess the impact.