ADR Governance Patterns — Async Teams, Remote-First Decision Authority, and the RFC Loop

What ADR governance is — and what it isn't

ADR governance is the set of rules that determine: who can write an ADR, who must review it, who has the authority to mark it Accepted, and what the review window is. It is NOT the same as architecture governance (the broader process of evaluating and directing technical strategy). An ADR governance model can be extremely lightweight and still function correctly.

The minimum viable governance model for a team adopting ADRs for the first time is: anyone writes, at least one senior engineer reviews, the author merges after three business days if no objection. This works for teams up to about fifteen engineers. Beyond that, you need classification to distinguish the decisions that warrant broader review from those that don't.

The core tension in ADR governance is between velocity (decisions should be cheap to document and cheap to close) and legitimacy (cross-team decisions need input from affected parties). The patterns below resolve that tension by concentrating ceremony on the decisions that actually need it, and keeping the ceremony minimal for everything else.

Pattern 1: Announce-then-silence

The announce-then-silence pattern is the most widely used async governance ceremony. The steps:

1. Author opens an ADR as a pull request on the main branch.
2. Author posts a message to the relevant channel (e.g. #architecture, #adr-reviews, or the team channel for service-local decisions) with: a one-line summary of the decision, a link to the PR, and an explicit merge deadline in calendar terms ("Will merge next Wednesday unless there's a blocking objection").
3. No follow-up reminders. No synchronous meeting. The PR is open for review asynchronously.
4. If the deadline passes with no blocking comment on the PR, the author merges.
5. If a reviewer posts a blocking comment, the author either revises the ADR to address it, or escalates to the designated decision authority for a ruling.

Why the default is merge-if-silent, not block-if-silent

The critical design choice is the default. If the default is block-if-silent (PR stays open until explicit approval from a list of reviewers), you've created a consensus-required process — see the anti-patterns section. If the default is merge-if-silent (PR closes unless someone raises an objection), you've created a consent-based process where reviewers are empowered but not required to act.

In distributed teams where synchronous time is scarce, consent-based governance (merge unless blocked) dramatically reduces ADR cycle time. The psychological shift is significant: reviewers know their silence is a form of consent, which motivates actual review rather than passive non-engagement.

What counts as a blocking objection

Define this explicitly in your governance doc or ADR template header, or you'll have disputes. A blocking objection is:

• A factual error in the Alternatives Considered section that changes the Decision (the rejected alternative was not actually tried, or the rejection reason is wrong).
• A missing stakeholder — the decision affects a team that wasn't notified.
• A constraint violation — the decision conflicts with an existing foundational ADR or a non-negotiable architectural constraint.

What is NOT a blocking objection: a preference for a different choice, a minor wording disagreement, a request for additional sections. These should be raised as non-blocking comments and addressed in a subsequent ADR update if warranted.

Pattern 2: Async RFC round

The async RFC round is appropriate for cross-team decisions where the options aren't yet clear and you want structured input before committing to a direction. The structure:

1. RFC document: Write an RFC Markdown document in the format "Context + Options + Questions + Not-in-scope". Post it in the designated RFC channel or repository with a comment deadline (5–10 business days).
2. Comment window: Stakeholders post comments on the RFC document. The author collects input, updates the Not-in-scope and Options sections as the discussion refines the option set.
3. RFC closes: Author writes a brief "RFC decision" comment summarizing the chosen direction and the key inputs that shaped it. RFC is marked Closed.
4. ADR opens: Author writes the ADR with the RFC decision in the Decision section, the RFC thread as primary source material for Alternatives Considered, and a reference to the closed RFC issue/PR in the Context section.
5. ADR review: Announce-then-silence with a shorter window (3 business days) since consensus was already reached in the RFC round.

The RFC-to-ADR handoff is the critical step

The most common failure mode of the RFC-to-ADR workflow is stopping at the RFC. Teams write good RFCs but never write the ADR, leaving the decision record in a discussion thread that isn't searchable and will eventually be archived. The ADR is not a summary of the RFC — it's the decision record that survives after the RFC is forgotten. Write the ADR within 48 hours of closing the RFC, while the context is still fresh.

The WhyChose extractor helps here: if the RFC included AI-assisted reasoning (a ChatGPT thread exploring the options, a Claude session weighing the trade-offs), the extractor surfaces those sessions and produces structured output that maps directly onto the ADR's Alternatives Considered and Context sections — filling the sections most engineers leave thin because they can't reconstruct the reasoning from memory.

Pattern 3: Decision classification

Not all decisions warrant the same governance ceremony. Three-class classification is the standard approach for teams past fifteen engineers:

Class 1: Service-local

Decisions that affect a single service's internal implementation: technology choices visible only to that service, internal data model changes, refactoring approaches, tooling changes for a single team. Governance: team lead reviews, 3-business-day window, announce in team channel. The broader engineering organisation does not need notification for Class 1 decisions.

Examples: "Switch from REST to GraphQL for this service's internal API" (not exposed to other teams), "Use Redis for this service's rate limiting cache" (not shared), "Rename module structure from flat to layered" (purely internal).

Class 2: Cross-team

Decisions that affect a shared contract, a shared data store, a platform service interface, or any behaviour that other teams depend on. Governance: notify all dependent teams, 5-business-day window minimum (10 for complex decisions), announce in the broader architecture channel. The author is responsible for identifying all dependent teams and ensuring they're notified.

Examples: "Deprecate v1 of the payments API after a 60-day window", "Move the user service's read replicas to a separate connection pool", "Introduce a rate limit on the shared search service".

Class 3: Foundational

Decisions about shared infrastructure, security model, authentication strategy, data retention policy, or any cross-organisation standard. Governance: explicit sign-off from the decision authority (architecture guild, CTO, or equivalent), 10-business-day window, announce in all-engineering channel. These decisions should be rare (no more than a few per quarter at most companies).

Examples: "All new services must use JWT-based auth with the central identity provider", "No PII may be stored outside the EU-West-1 region", "Default branch protection requires two approvals for foundational ADRs".

Adding decision class to the ADR header

Add a Decision-Class field after Status in the ADR front matter:

# ADR-0043 — Switch payments service to async message queue

**Status:** Accepted
**Decision-Class:** Class 2 — cross-team (affects order service, notification service)
**Date:** 2026-06-04
**Deciders:** @alice (payments), @bob (orders), @caro (platform)
**Review-Window:** 5 business days (closed 2026-06-11)

Making the class explicit prevents the governance dispute — "did this need broader review?" — from becoming a post-merge retrospective.

Pattern 4: Decision authority by role

Who marks an ADR Accepted depends on who has the authority to close the decision for the team. This varies by organisation but the common model is:

The ADR decision authority matrix covers the RACI model in more detail, including the approval chain for organisations with a formal architecture board and the anti-patterns that emerge when the authority structure is ambiguous.

Timezone-aware windows in distributed teams

Business days are not the same as calendar days for globally distributed teams. A "5 business day" window that starts on a Friday in the author's timezone gives US West Coast engineers two working days before it closes if the author is in APAC. State the deadline as a calendar date and time with explicit timezone in the Slack announcement: "Will merge 2026-06-11 17:00 UTC unless there's a blocking objection". This is unambiguous for reviewers in any timezone.

Governance anti-patterns that stall ADR adoption

Anti-pattern 1: Consensus required

The most common governance failure: requiring explicit approval from all stakeholders before an ADR can be merged. In any team larger than five engineers, consensus-required governance produces one of two outcomes — ADRs that take weeks to close (killing the author's motivation to write the next one) or ADRs that are never written in the first place (because the author knows the ceremony will outlast the decision). Replace consensus-required with consent-based (merge unless blocked).

Anti-pattern 2: ADR committee

Creating a standing committee that reviews all ADRs. This concentrates the governance load on a small group, creates a queue that grows faster than the committee can clear it, and produces bottleneck-driven frustration on both sides. ADR governance should be distributed — each decision class has its own natural reviewers (team, adjacent teams, architecture guild) rather than a single central body.

Anti-pattern 3: Synchronous review required

Requiring a synchronous meeting to review an ADR before it can be merged. This is the remote-team killer: finding time that works across multiple timezones is hard, which means the ADR sits in a "pending meeting" state indefinitely. Async governance (PR + announcement + window) is always superior for distributed teams. If a meeting happens to occur during the review window and the ADR is discussed, that's fine — but the meeting should never be a requirement.

Anti-pattern 4: Veto without obligation

Allowing any reviewer to veto an ADR without requiring them to propose an alternative or a specific revision. This creates paralysis: a reviewer who prefers a different approach (but has no bandwidth to specify it) can block indefinitely by posting "I don't think this is right" without engaging constructively. The blocking objection definition (Pattern 1, above) prevents this — a veto must identify a specific factual error, missing stakeholder, or constraint violation.

Anti-pattern 5: ADRs for every decision

Requiring an ADR for every technical decision, including trivial ones. This produces ADR inflation — a repository full of low-signal records that dilute the value of the important ones, and a team that feels the ADR process is bureaucratic overhead. The when to write an ADR guide covers the decision signal thresholds in detail: ADRs are for decisions that are hard to reverse or have significant cross-team impact, not for routine implementation choices.

Tooling for async ADR governance

GitHub pull requests (recommended)

GitHub PRs are the best governance surface for most teams: the diff shows exactly what changed, inline comments thread on specific sections, the merge deadline is enforced by closing the PR or merging it, and the full review history is preserved in git. For teams using a Markdown ADR repository (the most common setup), the PR workflow integrates naturally — ADR governance is just branch protection + PR review policy on the doc/decisions/ directory.

Configure branch protection rules: require at least one review for Class 2 and Class 3 ADRs (use a code owner file to auto-assign reviewers for the decisions/ directory), and use a CODEOWNERS file to map decision class to reviewer groups.

Slack for announcements

A dedicated #adr-announcements channel (or a section in #architecture) is enough for the announcement step. The announcement should be a single message, not a thread: it goes into the channel so it's visible to everyone, and discussion happens in the PR, not in the Slack thread. Using Slack threads for ADR review creates a split discussion that's hard to archive — the PR is authoritative, Slack is the notification surface only.

Notion or Confluence for governance documentation

The governance rules themselves (decision classes, review windows, authority matrix) should live in a shared doc — Notion or Confluence, or a GOVERNANCE.md file in the ADR repository — not in individual ADR headers. Engineers should be able to look up the governance rules without having to read existing ADRs. Link to the governance doc from the ADR template so every new ADR author knows it exists.

Governance and the retrospective ADR problem

Governance patterns above assume contemporaneous ADRs — decisions documented at or near the time they were made. The retrospective ADR problem is different: decisions made before the team adopted ADRs, or before governance was defined, that need to be backfilled.

Retrospective ADRs have no reviewer — the decision authority who made the call may have left the team, or may not remember the specific trade-offs considered. The most common source of retrospective decision reasoning, for decisions made since 2022, is AI chat sessions: engineers who used ChatGPT or Claude to think through architecture choices during that period have the reasoning recorded in their conversation export. The WhyChose extractor processes those exports and surfaces the sessions where architectural decisions were deliberated — providing the Alternatives Considered and Context material that retrospective ADR authors struggle most to reconstruct.

Apply governance to retrospective ADRs with a lighter touch: use Class 1 governance for all retrospective ADRs regardless of original scope, since the decision is already made and the review is more about ensuring the record is accurate than about evaluating the decision.