Decision log template for remote teams: one page per decision, with an owner and the rejected options

Why async teams keep decisions in writing

Co-located teams make most decisions out loud, and everyone who matters hears them. That stops working across time zones: the people who were awake decide, the people who were asleep find out later, and the reasoning is already gone. Writing the decision down before it is final does three things:

• It makes the decision findable. New hires, contractors and your future self can search for it instead of asking.
• It records the alternatives. The choice you made is rarely the interesting part. The options you turned down, and why, are what stop the same debate restarting every quarter.
• It gives the decision an owner. A decision nobody owns gets quietly reversed. One with a name on it gets defended or deliberately changed.

The software world has had a format for this since 2011, when Michael Nygard published "Documenting Architecture Decisions". His architecture decision record (ADR) has five parts: title, context, decision, status and consequences, with status values of proposed, accepted, deprecated and superseded. The template below keeps those bones and adds the fields a general-purpose team needs: an owner, the rejected options as their own section, a review date, and who was consulted.

The decision log template

Copy this into a new page for every decision. Keep the headings; delete any prose you do not need.

Title: Short noun phrase. "Use Postgres for the events store", not "Database".
ID: DEC-014
Status: Proposed | Accepted | Superseded by DEC-0xx | Deprecated
Owner: One name. The person who can change this decision.
Date decided: 2026-10-28
Review on: 2027-04-28 (or "never" for one-way doors)
Consulted: People whose input was asked for before deciding
Informed: People or channels told after deciding

== Context
What situation forced a choice. Facts, constraints and deadlines,
not opinions. Two to six sentences.

== Decision
The choice, in one or two full sentences, active voice:
"We will ...".

== Options rejected
1. Option A: why it lost.
2. Option B: why it lost.
3. Do nothing: what that would have cost.

== Consequences
What becomes easier, what becomes harder, what we now owe
(migrations, training, a follow-up decision).

== Confirmation
How we will know the decision held: a metric, a date, a check.

Numbered IDs (DEC-001, DEC-002) matter more than they look. They let a chat message, a commit or a task say "see DEC-014" without a link that will break, and they make "superseded by DEC-021" unambiguous.

What each field is for

Status. Proposed means the owner has written it up and is waiting for comments. Accepted means the comment window closed and the decision stands. Superseded points to the newer decision that replaced it. Deprecated means it no longer applies and nothing replaced it. Never edit an accepted decision's body; write a new one and supersede the old.

Owner. Exactly one person. Not a team, not two co-owners. The owner is the one who proposes the decision, closes the comment window, and is asked first when someone wants to change it. If you cannot name an owner, the decision is not ready.

Context. The forces at play: the deadline, the budget, the integration that broke, the customer who asked. Write it so a reader a year from now understands why "do nothing" was not acceptable. Leave out the arguments; those go in the options.

Options rejected. This is the section most templates skip and the one that pays back most. Each rejected option gets a line and a reason. "Too expensive" is not a reason; "$450 a month at our seat count versus $39" is.

Consequences. Both directions. A decision that only has upsides has not been thought through. Include the debts: the migration you now owe, the skill you now need to hire for, the follow-up decision you have deferred.

Confirmation. How you will check, later, that the decision did what you expected. This is borrowed from MADR, the Markdown Architectural Decision Records template at adr.github.io, which added a Confirmation section alongside its Context and Problem Statement, Decision Drivers, Considered Options, Decision Outcome and Pros and Cons of the Options. A confirmation line turns the review date from a calendar reminder into a question with an answer.

Decision log vs ADR vs MADR

If every decision your team makes touches code, keep ADRs in the repository and skip the rest of this post. If your decisions include "which payroll provider" and "do we offer a yearly plan", they need a home people outside the repository can read.

How to document a decision asynchronously

The template is the easy part. The process is what makes it async rather than a meeting with extra typing.

1. Open the entry as Proposed before you have decided. The owner writes Context, a draft Decision and at least two rejected options. Writing the alternatives first is what forces real thinking; a decision written after the fact is a press release.
2. Name the comment window. Say in the entry: "Comments until Thursday 17:00 UTC." Forty-eight hours covers every time zone twice. For a reversible decision, twenty-four is enough.
3. Post one message, in one channel. Link the entry, state the window, tag the consulted people by name. Do not paste the whole decision into chat; the page is the record, the chat is the notification.
4. Comment on the page, not in the thread. Inline comments stay attached to the sentence they are about. A chat thread is gone in a week.
5. The owner closes the window. Either the decision becomes Accepted, possibly edited to reflect comments, or the owner writes why it was changed and reopens a shorter window. Silence is consent; say so in the entry so nobody is surprised.
6. Set the review date when you accept. Six months is a sensible default for tooling and process decisions. For a decision that cannot be undone cheaply, write "never" and say why.
7. Tell the informed list. One line in the team channel: "DEC-014 accepted: we will use X. Review April." That is the whole announcement.

The review cadence that keeps the log alive

Logs die because nobody reads them. Two recurring checks fix that, both done by one person.

Weekly, five minutes. The owner of the log (usually whoever runs operations) filters for Status = Proposed and checks that each one has a comment window that has not quietly expired. Expired windows become Accepted or get a nudge.

Monthly, twenty minutes. Filter for Review on within the next 30 days. For each decision, the owner answers the Confirmation line in a single comment: held, held with changes, or did not hold. A decision that did not hold gets a new Proposed entry that supersedes it. This is the only meeting the log ever needs, and it can be a written round-up rather than a call.

Two numbers tell you whether the log is working. The first is the share of decisions with at least one rejected option written down; below 80 percent, people are logging after the fact. The second is how many entries are Superseded. Zero after a year means decisions are being changed in chat and the log has become fiction.

Keeping the log in Atrix

Any tool that can hold a page per decision and filter by a field will do: a folder of Markdown files in the repository, a Notion database, a Confluence space. We run ours as a page database in Atrix, which is a page whose sub-pages are rows, and this is what that looks like in practice.

The database page gets seven properties, which is well within the limit of twenty: Status as a select with Proposed, Accepted, Superseded and Deprecated; Owner as a person; Decided and Review on as dates; Consulted as text; Supersedes as text holding the older ID; and Confirmed as a checkbox the monthly review ticks. Each row is a full page, so the template above lives in the row body and the properties live in the table. Property types available are text, number, select, date, checkbox, person and URL, so there is no formula or rollup; if you need those, keep a spreadsheet alongside.

Two things make this better than a folder of files for a non-engineering team: comments sit on the sentence they are about, and the page history keeps every edit, so "who changed the decision after it was accepted" has an answer. Docs and whiteboards has the full list of what pages can do.

The part we did not expect to use daily is the MCP server. The Atrix MCP server exposes 85 tools, including pages_create and pages_append, so an AI assistant connected to the workspace can draft a decision entry from a chat thread and append it to the log without anyone leaving the conversation. The pages_append tool merges with anyone editing the page at the same time rather than overwriting them, which matters when the owner is mid-sentence. The assistant drafts in Proposed; a person still sets the owner, closes the window and marks it Accepted. Setup is one claude mcp add command and an OAuth sign-in; the MCP docs cover scopes, and Claude and the other listed assistants work the same way.

The limits are worth stating. There is no free plan, so a workspace is $39 a month on Builder for 5 seats or $149 on Studio for 15, after a 7-day trial that needs a card. The database has no formula columns, and there is no automatic "review is due" reminder on a page property yet; we use the monthly filter instead.

FAQ

What is the difference between a decision log and a decision register?

Nothing meaningful. Project managers tend to say register, software teams say log, and both mean one entry per decision with a status and an owner. Pick one word and use it everywhere so search works.

How detailed should a decision log entry be?

Long enough that someone who was not involved can understand why the decision was made and what was rejected, and no longer. Most entries fit in 150 to 400 words. If an entry runs past a page, it is probably two decisions, or it is a design document that the decision should link to.

What is an architecture decision record?

An ADR is a short document that records one architecturally significant decision: the context, the decision, its status and its consequences. The format comes from Michael Nygard's 2011 post "Documenting Architecture Decisions" and is usually kept as numbered Markdown files in the repository. MADR is a more structured ADR template with sections for considered options and their pros and cons.

Who should own the decision log?

One person owns the log as a whole, usually whoever runs operations or the engineering lead, and runs the weekly and monthly checks. Each decision has its own owner, who is the person able to change it. These are different roles and should usually be different people.

Should we log small decisions too?

Log a decision if reversing it would cost more than an hour, if it affects more than one person's work, or if someone is likely to ask "why" in six months. Which linter rule to enable does not need an entry; which linter does.

How do we handle a decision that turns out to be wrong?

Write a new entry. Set the old one to Superseded by the new ID and leave its body untouched. The log is a history, and a record of a wrong decision with the reasoning intact is more useful than a corrected one that hides what was known at the time.

Next step

Create a page called "Decisions", turn it into a database with Status, Owner and Review on, and paste the template into its first row. Docs and whiteboards shows the editor, and the pricing page has the plan limits if you want to try it with your own team.