# Architecture Decision Record (ADR)
One decision, one page, signed and dated.

_A lightweight record of an architecture choice so the next engineer knows why the system looks the way it does. One ADR per decision._

Used in: Lesson expert/10 — https://vetslearn.com/lessons/expert/10
Source: https://vetslearn.com/resources/templates/engineering#t-adr

---

# ADR-[ADR-NUMBER]: [TITLE]

**Status:** [STATUS — proposed / accepted / superseded by ADR-XXX]
**Date:** [DATE]
**Author:** [AUTHOR]

---

## Context

*Fill this in: what forced the decision. The problem, the constraints, the deadline. Two short paragraphs max. Skip background the reader already has.*

## Decision

*Fill this in: what we are doing. One or two sentences. Start with a verb.*

We will [verb] [thing] using [approach].

## Consequences

### Positive
*Fill this in: what gets better.*
- [Consequence 1]
- [Consequence 2]

### Negative
*Fill this in: what gets worse or harder. Name the costs honestly.*
- [Consequence 1]
- [Consequence 2]

### Neutral
*Fill this in: side effects that are neither good nor bad but worth flagging.*
- [Consequence 1]

## Alternatives considered

*Fill this in: the other options on the table and why they lost. One paragraph each.*

### Option A: [name]
[Why we did not pick it.]

### Option B: [name]
[Why we did not pick it.]

## References

- [Link to design doc]
- [Link to RFC, ticket, or thread]
- [Link to vendor docs if applicable]

---

## How to use

Number ADRs in order in a `/docs/adr/` folder. Once accepted, do not edit the body — write a new ADR that supersedes it. Keep each ADR short. If you cannot fit it on one screen, you are explaining too much background. The point is the decision and why, not the tutorial.

## Check before you use it

- The negative consequences section is honest. If it is empty, the decision has not been thought through.
- Alternatives name real options that were on the table, with the real reasons they lost.
- Status and number do not collide with an existing ADR in the folder.