Skip to content
Nodary
Start free

Decision log template with ADRs

A decision log and its records, in six linked documents: the log that lists every decision with its status, the way your team decides, a blank record to copy, and three example records, one of them superseded by the next. Download them as Markdown files: they open in any editor, sit well in a code repository, and import into Nodary as a map.

Download the templateOpen the live demo

6 Markdown files in a .zip, 6 kB

Free, no account, no email. Use it, change it, share it.

Decision logHow we decideDecision record templateADR-001 Keep decisions in this logADR-002 Store uploaded files on the application serverADR-003 Store uploaded files in object storage

Read every page before you download

The log is the page everyone opens: one line per decision, linked to its record. Records follow the architecture decision record (ADR) format, and work for any decision, technical or not. The examples follow one sample product deciding where to keep uploaded files.

Documents

File Decision log template/Decision log.md

Decision log

How to use this template: italic lines are guidance. Replace them with your own words, then delete them. Values in square brackets are yours to fill in. Each decision has its own record, linked from the table below; a record is never deleted, and a decision that changes gets a new record that supersedes it.

Decisions

NumberDecisionStatusDateDecided bySuperseded by
ADR-001Keep decisions in this logaccepted[date][names]
ADR-002Store uploaded files on the application serversuperseded[date][names]ADR-003
ADR-003Store uploaded files in object storageaccepted[date][names]
[ADR-004][Your next decision][proposed][date][names]

Statuses

  • ProposedAcceptedRejected
  • AcceptedSupersededDeprecated
How a decision’s status changesA Mermaid diagram in the file: Nodary, GitHub and Obsidian draw it.
Mermaid
flowchart LR
  n0["Proposed"]
  n1["Accepted"]
  n2["Rejected"]
  n3["Superseded"]
  n4["Deprecated"]
  n0 --> n1
  n0 --> n2
  n1 --> n3
  n1 --> n4
StatusMeaning
ProposedWritten and open for review, not decided yet
AcceptedDecided: the team works to it
RejectedDecided against, and kept so nobody has to ask again
SupersededReplaced by a later decision, whose number it gives
DeprecatedNo longer applies, and nothing replaced it

When to write a record

  • The decision is hard to reverse: [a database, a supplier, a public API, a price]
  • Several options were seriously considered
  • Someone will ask why in six months
  • It changes how another team works

The rest of the log

This template is free to use, change and share. It comes from Nodary, where these files import as a map of linked documents.

Download the template6 Markdown files in a .zip, 6 kB

How to use it

  1. Agree on who decides

    Fill in the process page first: which kinds of decision need a record, who proposes, who decides and who is consulted.

  2. Copy the record for each decision

    Give it the next number and the status proposed. Write the context and at least two options before anyone writes the decision.

  3. Decide, then list it

    Set the status to accepted or rejected, with the date and the deciders, and add a line to the log. A rejected decision stays: it saves the next debate.

  4. Supersede, never rewrite

    When a decision changes, write a new record that supersedes the old one, and mark the old one superseded with the new number. The history stays readable.

Import it into Nodary as a map

Nodary is an AI-native workspace where a team’s documents link instead of piling up. Import the .zip and the log arrives with its records filed under it and the links between them kept. Mark each record as canon, exploration, obsolete or superseded by the record that replaced it: the status shows on the document, and AI agents connected over MCP are told before they read a superseded one. When two documents disagree, Nodary shows both passages side by side.

  1. Open a project’s map and choose Import.
  2. Choose the Folder or ZIP tab, then Choose a ZIP.
  3. Pick the downloaded file, check the tree, and import.

The Free plan holds ten documents per workspace, the project’s own page included: the template’s six leave room for three more records. Nodary also has a one-page Architecture Decision Record template built in.

How AI agents connect to Nodary over MCP
A document in Nodary with a note saying what changed since the reader’s last visit and who changed it, and the version history comparing that version with now; the sample project shown is a game.

Keeping a decision log people trust

A decision log fails when nobody writes in it, or when what it says no longer matches what the team does. These habits prevent both.

One decision per record

A record that settles three things is reopened three times. Keep each one to a single decision with a single status.

Context before the decision

Write what is true today and what constrains the choice before the decision itself. Six months later, the context is what explains it.

Always name two options

A record with one option is an announcement. Name the alternatives you seriously considered and why you did not take them.

Supersede, never rewrite

An accepted record is never edited to say something else. A new record replaces it and both stay, so the log tells the true story.

Say who decided

Each record names its deciders and its date. A decision without a name has nobody to ask, and nobody to change it.

Link to what it changes

Link each record to the documents it changes, and those documents back to it. A reader of the design then finds the reason in one click.

Questions about decision logs

What is a decision log?

A decision log is a running list of a team’s significant decisions: what was decided, when, by whom, its status, and a link to the record that explains it. It lets anyone, including a new teammate or an AI agent, find out why things are the way they are without asking around.

What is an ADR?

An architecture decision record, or ADR, is a short document for one significant decision: its context, the options considered, the decision and its consequences, with a number and a status. The format comes from software architecture, and works for any decision a team wants to keep.

What does superseded mean?

A superseded decision has been replaced by a later one. It stays in the log, unchanged, with the number of the record that replaced it, and the new record says which one it supersedes. Nothing is deleted, so the history stays true.

When should a team write a decision record?

When a decision is hard to reverse, when several options were seriously considered, when it changes how another team works, or when someone is likely to ask why in six months. Small reversible choices do not need one.

Should decision records live with the code or with the documents?

Teams that only share decisions among engineers often keep them in the code repository. When product, design, support or clients need to read them too, a shared workspace makes them easier to find. The files in this template work in both places.

Can I use it outside Nodary?

Yes. The files are plain Markdown with relative links: put the folder in a repository, open it in Obsidian as a vault, or read it on GitHub, diagram included.

Read next

Keep every decision where the team works.

Import the template into Nodary and the log becomes a map that says which decisions still hold, for your team and your AI agents. Free with two members, one project and ten documents, no card needed.

Start freeOpen the live demoDownload the template