Research Question
What is the appropriate granularity (the "unit") for a single Architecture Decision Record (ADR), and how should a large, multi-faceted architecture initiative be decomposed into individual ADRs?
[Note: Focus on decision-sizing heuristics and decomposition patterns. NOT about ADR file format/templating, naming, or tooling syntax.]
Context
We are a solo developer operating a Decision Review Pipeline (DRP) that gates every ADR through automated review: Triage → Blind-spot Detection → Body Generation → Scoring (N=5 self-consistency) → Cross-Validation → Consistency → Parallel multi-model review (Gemini/Claude/GPT). Monthly volume: 5–15 ADRs. Each draft must carry: problem, chosen approach, decision drivers, ≥2 alternatives, consequences, cost estimate, rollback threshold, verification KPI.
We are about to make architecture decisions for a new product (electronic voucher storage / Japanese e-bookkeeping "電子帳簿保存法" compliance, evolving into a multi-tenant SaaS, dogfooded internally first). The initiative spans several distinct concerns: record-of-truth storage location, compute/data platform, multi-tenant authentication, ingestion adapters (Google Workspace and Microsoft 365), data model, integrity/tamper-evidence method, and retention.
Problem: we are unsure how finely to slice these into ADRs. Too coarse (one big "product architecture" ADR) makes our automated reviewer produce unfocused, oscillating critiques (a goalpost-moving over-review loop). Too fine and we drown in low-value records and lose the bigger picture. We need principled criteria for ADR granularity and decomposition.
Questions
Granularity criteria: What concrete, testable signals define "one decision = one ADR"? Give heuristics for when to split a draft into multiple ADRs vs merge several into one (e.g., independent reversibility, distinct decision drivers, separate stakeholders, separate rollback conditions).
Decomposing a large initiative: How do practitioners slice a multi-layer architecture effort (storage, auth, ingestion, data model, retention) into ADRs without over- or under-fragmenting? Provide named patterns and worked examples.
ADR vs adjacent artifacts: What belongs in an ADR vs higher-level requirements (business/system requirements) vs detailed design specs (data definitions, API contracts)? Where is the boundary drawn in practice?
Granularity for AI-assisted review: How does ADR size affect the quality of automated/LLM review? Is there a theoretically or empirically supported "right size" that minimizes review oscillation while preserving context?
Sequencing interdependent ADRs: How should a set of dependent ADRs be ordered (foundation-first vs feature-first), and how should decisions blocked on open research be staged?
Output
Structured report with:
- Executive summary (3–5 key findings)
- Per-question analysis with concrete heuristics
- A decision matrix / checklist for sizing & splitting ADRs (signal → split or merge)
- Priority ranking (must-have / should-have / nice-to-have) of the criteria
- References with URLs