> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plannotator.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture Decision Record Template

> Copy a concise architecture decision record template with status, context, drivers, options, decision, consequences, and confirmation.

Use an ADR for one architecturally significant choice that future people and agents will otherwise have to rediscover. Record the reason and consequences, not a complete project history.

```md theme={null}
# [NNNN] [Decision in active voice]

Date: [YYYY-MM-DD]
Status: Proposed | Accepted | Rejected | Deprecated | Superseded by [link]

## Context
[The forces, constraints, and problem that make a decision necessary.]

## Decision drivers
- [Quality, constraint, or requirement that changes the choice]

## Considered options
1. [Option]
2. [Option]

## Decision
We will [specific choice].

## Consequences
- [Positive or enabling consequence]
- [Cost, limitation, or new responsibility]

## Confirmation
[How implementation or operation will prove the decision is being followed.]
```

## Annotated example

```md theme={null}
# 0012 Store job leases in the database

Status: Accepted

## Context
Two workers can claim the same queued job after a process restart. In-memory locks do not survive or coordinate across processes.

## Decision
We will acquire a time-bounded lease with one conditional database update before work begins.

## Consequences
- Workers can recover abandoned jobs after the lease expires.
- Lease duration and renewal become operational settings that require monitoring.

## Confirmation
An integration test starts two workers against one database and proves only one performs the job.
```

This example preserves the hard-to-reverse choice and the proof that guards it. Implementation steps belong in a linked plan.

The [ADR community](https://adr.github.io/) defines an ADR as a record of an important architectural decision with its context and consequences. [MADR](https://adr.github.io/madr/) offers fuller and smaller forms, while Michael Nygard's well-known short form uses status, context, decision, and consequences. Our [ADR formats profile](/frameworks/adr-formats) explains the tradeoffs.

## Review prompts

* Is this a genuine tradeoff with durable consequences?
* Does the context explain why the decision was necessary at the time?
* Are rejected options represented fairly?
* Can a test, lint rule, review check, or operational signal confirm the decision?

This template is Plannotator-authored and does not reproduce a third-party template verbatim.

*Reviewed July 18, 2026. Written and maintained by the Plannotator documentation team.*