From beb5f191470a9daef2383981a6bfd02232490ab4 Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Fri, 6 Nov 2026 19:56:27 -0600 Subject: [PATCH] Update the documentation policy to clarify the role of ADRs. --- docs/policy/documentation.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/docs/policy/documentation.md b/docs/policy/documentation.md index d7ab938..44c5934 100644 --- a/docs/policy/documentation.md +++ b/docs/policy/documentation.md @@ -161,8 +161,15 @@ Use sequentially numbered ADR filenames such as Treat the decision content of an accepted ADR as immutable. When a decision changes, create a new ADR and update the earlier ADR's status to superseded. -Rejected architectural alternatives belong in the ADR; rejected product ideas -belong in the roadmap. + +ADRs should be reserved for major architectural decisions, such as ownership +boundaries, large-scale architectural features, or invariants that rise to +the level of architectural significance. Routine choices, implementation +decisions, and rejected suggestions do not warrant an ADR unless they +otherwise represent a significant architectural decision. + +Roadmaps should preserve plausible future work, not rejected product +ideas. ## Maintenance