Decision Record Template

Copy the template below to record any decision, technical or not. It follows the shape of architecture decision records (ADRs), the short text files software teams keep next to their code, and adds the parts that let a later reader check the decision: the premises it rested on, what was expected to happen, and what was deliberately left open.

The Template

# [Short title of the decision]

- Status: Proposed | Accepted | Rejected | Superseded by [link]
- Date:
- Written: at the time | reconstructed on [date]
- Decided by:
- Consulted:

## Need (the problem this decision solves)
What had to be true, stated sharply enough to test afterward.

## Alternatives
1. [Option]: why it was chosen or ruled out
2. [Option]: why it was chosen or ruled out
3. Do nothing: why it was chosen or ruled out

## Premises (the facts it depends on)
The facts this decision rests on: budget, contract terms,
regulations, team capacity, deadlines.

## Decision
What was decided, and the argument that tipped it.

## Expected Outcomes
- [What should happen], checked by [how], by [when]

## Open Questions
What this decision deliberately does not settle.

## Supersedes
[Link to the earlier record this one replaces, if any]

How to Fill It In

• Need: write the problem before you write any option. "Improve onboarding" cannot be tested; "new customers complete setup within two days" can
• Alternatives: keep the options you rejected and the reason each one lost. They are what stops a dead end being proposed again a year later
• Premises: list the facts separately from the reasoning, so when one changes you can see which decisions stood on it
• Decision: state the choice and the argument that decided it, not only the outcome
• Expected outcomes: commit to something measurable at the moment of deciding. It is what lets you tell a bad decision from a good one with bad luck
• Open questions: name what the decision leaves unsettled on purpose, so nobody reads it as covered
• Decided by and consulted: record who committed and who gave input while everyone still remembers

A Worked Example

# Raise the starter plan price from €19 to €24 per month

- Status: Accepted
- Date: 2026-09-15
- Decided by: Head of Revenue
- Consulted: Finance, Customer Success

## Need
Gross margin on new starter accounts must reach 70% without
raising churn above its current level.

## Alternatives
1. Raise the price to €24: chosen, it closes the margin gap on its own
2. Cut the included support hours: ruled out, support is the top
   reason customers give for staying
3. Do nothing: ruled out, margin stays at 63%

## Premises
- Cost to serve one starter account is €7 per month
- Existing customers keep their price for 12 months

## Decision
Raise the starter price to €24 for new customers from November 1,
because it reaches the margin target without touching the support
customers value most.

## Expected Outcomes
- Starter gross margin on new accounts at 70% or above by the
  end of Q1
- Starter churn no higher than today, checked monthly

## Open Questions
- Whether existing customers move to the new price after their
  12 months, or keep the old one

## Supersedes
None

Reconstructing a Past Decision

A decision made before you started recording can still be written down. The record is less exact than one written at the time, and far more useful than rebuilding the reasoning from scratch every time someone asks.

1. Gather the traces: emails, meeting notes, tickets, chat threads, contracts, and the version history of any document the decision changed
2. Talk to the people involved while they still remember: who raised it, who decided, and what else was on the table
3. Fill in the template from what you found, and leave a part empty rather than guessing
4. Write the expected outcome as it was expected then, if anyone can say; otherwise leave it out and say so
5. Mark the record as reconstructed, with the date you wrote it, so readers know it was not written at the moment of deciding

Rules That Keep a Record Honest

• Never edit a record once it is accepted or rejected. If the decision changes, write a new record that supersedes the old one and link the two. An edited record tells you what someone believes now, not what was decided then
• Write the expected outcome before you know the result. Written afterward, it only describes what happened
• Mark a reconstructed record as reconstructed. A decision written up months later is useful, as long as readers know it was not written at the time
• Record rejected decisions too. Deciding not to do something is a decision, and the reasons matter just as much

From a Template to a Platform

A template in a file or a wiki is a good way to start. It asks everyone to keep the discipline by hand: to update the status, to come back to the expected outcome, to notice when a premise changes.

Memolok is the Decision Record platform that keeps the same shape for you. It captures the decision inside the conversation where it is made, in Claude, whether you use Claude chat, Claude Code, or Cowork. Each approved record is sealed, superseded instead of edited, checked against what actually happened, and queryable by your team and your AI agents. See how to choose a Decision Record platform for the criteria, or how Memolok works for the full flow.

Try Memolok Today

Memolok is in early testing, and we're inviting people to try it now. Sign up today and start recording your decisions. Sign-ups are read by a person, not a mailing system, so there's no automatic confirmation email.

Common Questions

What to Read Next

• How to choose a Decision Record platform: eight criteria for when a template is no longer enough.
• What you use today: how Memolok compares with ADRs, business decision records, decision logs, and wikis.
• Glossary: plain definitions for need, premise, supersession, and the rest.