# Architecture Decision Record — Template
**Source:** Routiine LLC FORGE methodology · published at routiine.io/forge
**License:** Use freely. Attribution appreciated, not required.

---

## ADR-NNNN: [Short, Descriptive Title]

**Status:** Proposed | Accepted | Deprecated | Superseded by ADR-NNNN
**Date:** YYYY-MM-DD
**Project:** [Project name or "Global"]
**Authors:** [Named authors — individuals accountable, not teams]

---

## Context

What problem prompted this decision. Three to five paragraphs maximum.

Include:
- The technical or product constraint that forced the decision
- The business constraint that shaped the range of acceptable answers
- The timeline pressure (if any)
- The people who will be affected by the decision and how

Context should be dense. A future maintainer reading this record — without the original team in the room — should understand the problem completely before seeing the decision.

---

## Decision

What was decided, stated as a clear one-to-three-sentence commitment.

Example:
> We will adopt PostgreSQL 16 with Drizzle ORM as the primary data layer for every Routiine engagement starting 2026-01-01. Legacy engagements may remain on Prisma until the next major refactor; no new engagements begin on Prisma.

The decision paragraph should be quotable standalone. If a teammate pastes this paragraph into Slack, the commitment is unambiguous without the rest of the ADR.

---

## Consequences

What this decision enables:
- [Specific capability unlocked]
- [Specific risk retired]
- [Specific velocity improvement]

What this decision costs:
- [Specific technical debt accepted]
- [Specific work that now has to happen]
- [Specific skills the team must learn or hire]

What is now off the table:
- [Specific alternative that was considered and rejected]
- [Specific future optionality that this decision forecloses]

---

## Alternatives Considered

For each serious alternative:

### Alternative 1: [Name]
**Pros:** [1-3 bullets]
**Cons:** [1-3 bullets]
**Why not:** [One-sentence dismissal that is honest, not dismissive]

### Alternative 2: [Name]
[Same structure]

### Alternative 3: [Name]
[Same structure]

An ADR with fewer than two serious alternatives considered is usually a weak ADR. The discipline of writing down what was rejected and why is the discipline of not being wrong in the same way twice.

---

## Implementation Notes

Non-architectural details that matter for the first engineer who has to implement this decision:

- [Migration path from the previous state]
- [Specific tools, libraries, or services involved]
- [Known gotchas discovered during evaluation]
- [Rollback plan if the decision proves wrong inside N months]

---

## Review Triggers

Under what specific circumstances would we reopen this decision?

- [Named condition 1 — e.g., "PostgreSQL 16 is deprecated by its maintainers"]
- [Named condition 2 — e.g., "Team size exceeds 50 engineers, at which point centralized schema management becomes a bottleneck"]
- [Named condition 3 — e.g., "A business pivot requires a vector-native data layer"]

An ADR without named review triggers is an ADR that will outlive its usefulness by years. Give a future maintainer permission to reopen.

---

## References

- [Link to the RFC or spike that preceded this decision]
- [Link to the PR or commits that implemented it]
- [External references — blog posts, papers, vendor docs]

---

*This template is part of the Routiine LLC Resource Hub at routiine.io/resources. The full FORGE methodology is published at routiine.io/forge.*