scientific-skills/markdown-mermaid-writing/templates/decision_record.md
Back to Markdown Style Guide — Read the style guide first for formatting, citation, and emoji rules.
Use this template for: Architecture Decision Records (ADRs), Requests for Comment (RFCs), technical design documents, or any decision that needs to be documented with its context, options considered, and rationale. Designed so that future teams understand not just what was decided, but why — and can evaluate whether the decision still holds.
Key features: Structured options comparison with explicit tradeoffs, decision matrix, consequences section that captures both benefits and risks, and status tracking for the decision lifecycle.
Philosophy: Decisions rot faster than code. Six months from now, someone will ask "why did we do it this way?" If the answer is "nobody remembers," the decision is as good as random. This template makes the reasoning permanent, searchable, and evaluable. It also forces the author to genuinely consider alternatives — if you can't articulate why you rejected Option B, you haven't done enough analysis.
docs/decisions/ or adr/ directory001-use-postgresql-over-mongodb.md[bracketed placeholders] with your contentEverything below the line is the template. Copy from here:
| Field | Value |
|---|---|
| Status | [Proposed / Accepted / Deprecated / Superseded by ADR-NNN] |
| Date | [YYYY-MM-DD] |
| Decision makers | [Names or roles] |
| Consulted | [Who was asked for input] |
| Informed | [Who needs to know the outcome] |
[Describe the situation that requires a decision. What changed? What problem emerged? What opportunity appeared? Be specific — include metrics, incidents, or user feedback that triggered this.]
[How things work today. What architecture, tool, or process is currently in place. Include a diagram if it helps.]
flowchart LR
accTitle: Current State Architecture
accDescr: How the system works today before this decision is implemented
a[⚙️ Current component] --> b[💾 Current dependency]
b --> c[📤 Current output]
This decision must:
Description: [What this option entails — 2–3 sentences]
Pros:
Cons:
Estimated effort: [T-shirt size or days/weeks] Estimated cost: [If relevant — licensing, infrastructure, personnel]
Description: [What this option entails]
Pros:
Cons:
Estimated effort: [Estimate] Estimated cost: [If relevant]
Description: [What this option entails]
Pros:
Cons:
Estimated effort: [Estimate]
| Criterion | Weight | Option A | Option B | Option C |
|---|---|---|---|---|
| [Criterion 1 — e.g., Performance] | [High/Med/Low] | [Score or ✅/⚠️/❌] | [Score] | [Score] |
| [Criterion 2 — e.g., Team expertise] | [Weight] | [Score] | [Score] | [Score] |
| [Criterion 3 — e.g., Migration effort] | [Weight] | [Score] | [Score] | [Score] |
| [Criterion 4 — e.g., Long-term cost] | [Weight] | [Score] | [Score] | [Score] |
| [Criterion 5 — e.g., Community/support] | [Weight] | [Score] | [Score] | [Score] |
We chose Option [X]: [Name].
[2–3 sentences explaining the core rationale. What tipped the decision? Which criteria mattered most and why?]
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| [Risk 1] | [Low/Med/High] | [Low/Med/High] | [How we'll handle it] |
| [Risk 2] | [Likelihood] | [Impact] | [Mitigation] |
flowchart LR
accTitle: Post-Decision Architecture
accDescr: How the system will work after this decision is implemented
a[⚙️ New component] --> b[💾 New dependency]
b --> c[📤 New output]
| Step | Owner | Target date | Status |
|---|---|---|---|
| [Step 1] | [Person/Team] | [Date] | [Not started / In progress / Done] |
| [Step 2] | [Person/Team] | [Date] | [Status] |
| [Step 3] | [Person/Team] | [Date] | [Status] |
| Date | Reviewer | Outcome |
|---|---|---|
| [Date] | [Name] | [Proposed / Approved / Requested changes] |
Last updated: [Date]