Skip to content

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

  1. Find the next number by checking existing files in docs/adr/

  2. Create docs/adr/XXXX-short-name.adoc using the template

  3. 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.