Architecture Decision Records (ADRs) help teams capture important technical decisions in a consistent format. Using a template ensures every ADR includes the essential context: what was decided, why, and what trade-offs were accepted.

Below you'll find three widely-used ADR formats. Each strikes a different balance between simplicity and detail. All templates are free to download and use — no signup required.

Nygard ADR (Classic)

Most Popular

The original ADR format introduced by Michael Nygard. Minimal structure, maximum clarity. Captures the essential elements of a decision without overhead.

Best For

  • Small to medium teams
  • Fast-moving projects
  • Simple decisions

Characteristics

  • Lightweight structure
  • Quick to write
  • Easy to adopt
adr-001-example.md Markdown
# ADR-001: Use PostgreSQL for Primary Database

## Status
Accepted

## Context
We need a relational database for our application. 
The team has experience with PostgreSQL and MySQL.

## Decision
We will use PostgreSQL as our primary database.

## Consequences
- Team can leverage existing expertise
- Strong JSON support for flexible schemas
- Need to manage database migrations carefully

MADR (Markdown ADR)

Comprehensive

A structured format that explicitly captures decision drivers, considered options, and detailed pros/cons analysis. Ideal when decisions require formal evaluation of alternatives.

Best For

  • Medium to large teams
  • Complex trade-off decisions
  • Formal documentation requirements

Characteristics

  • Detailed structure
  • Options comparison built-in
  • Decision driver tracking
adr-002-example.md Markdown
# ADR-002: Select Frontend Framework

## Status
Accepted

## Context and Problem Statement
We need to choose a frontend framework for our new 
customer portal. The decision impacts developer 
productivity and long-term maintainability.

## Decision Drivers
* Team familiarity
* Performance requirements
* Ecosystem and tooling

## Considered Options
* React
* Vue.js
* Svelte

## Decision Outcome
Chosen option: "Vue.js", because it offers the best 
balance of simplicity and team experience.

### Positive Consequences
* Faster onboarding for new developers
* Strong TypeScript integration

### Negative Consequences
* Smaller talent pool than React

Y-Statement ADR

Lightweight

An ultra-minimal format that captures a decision in a single structured sentence. Perfect for quick documentation when full ADRs feel like overkill.

Best For

  • Quick decision capture
  • Low-ceremony environments
  • Incremental documentation

Characteristics

  • Single sentence format
  • Forces clarity
  • Minimal overhead
adr-003-example.md Markdown
# ADR-003: API Authentication Method

## Status
Accepted

## Y-Statement
In the context of securing our public API,
facing the need for stateless authentication,
we decided for JWT tokens with short expiry
and against session-based authentication,
to achieve scalability across multiple services,
accepting the complexity of token refresh logic.

Need a Custom Format?

These templates are starting points, not constraints. Many teams adapt them to fit their workflow — adding fields like review date, owning team, or related decisions.

The best ADR format is one your team will actually use. Start with a template above, then evolve it based on what information proves valuable over time.

Common customizations:

  • Adding a Reviewers or Stakeholders field
  • Including Related ADRs or dependency links
  • Tracking Assumptions that could invalidate the decision
  • Setting a Review Date for periodic re-evaluation
  • Linking to Implementation PRs or tickets

Prefer managing ADRs collaboratively instead of static files?

Try ReflectRally →