WhyVault
Sign indeStart for free

Template

A decision log that remembers why.

You usually remember what you decided. Why you decided it, and what you were assuming at the time, fades within months. Here’s the template we use to record decisions – ready to copy, with a worked example and a look at how Claude fills it in at the end of a conversation.

Reading time: 7 minutesUpdated:

01

Why write decisions down at all

Six months later someone asks, “Why do we do it this way?” And the honest answer is often: I don’t quite remember. The outcome lives in the code, the contract or the pricing page. The trade-offs behind it lived in a chat thread, a meeting or your head.

Without the why, one of two things happens. Either the same question gets argued again from scratch, with the same arguments. Or nobody dares touch an old decision, even though the reason for it disappeared long ago.

A decision log fixes both with very little effort: one short note per decision, always in the same shape, always in the same place. Not minutes of everything that was said. Just the question, the choice and the reason.

9_System/Templates/Template Decision.md
---type: decisiondate:room:context:decided_by:---# <YYYY-MM-DD> <What it was about>## QuestionWhat was there to decide? A question, not a topic.## Options| Option | For | Against ||---|---|---||  |  |  ||  |  |  |## DecisionWhat was decided, by whom, when.## ReasoningWhy this option – and why not the others.## What we assumedThe assumptions. The most important section: they're how you tell later when the decision needs to be revisited.-## ConsequencesWhat follows from it. No tasks; those belong in the task tool.

02

The template to copy

This is the decision template that ships with every vault using the WhyVault structure. It works just as well in Obsidian or any other Markdown editor.

  1. Frontmatter: type, date, room, context and decided_by make decisions easy to find – for you and for any agent searching for them later.

  2. Question: “How many pricing tiers do we launch with?” rather than “Pricing”. A real question forces you to say what was actually open.

  3. Options: At least two, or it wasn’t really a decision. The table shows later that you genuinely weighed alternatives.

  4. Decision & rationale: What, who, when – and why the other options lost. That second part is the one people skip.

  5. What we assumed: The conditions under which the decision is right. More on why this matters most further down.

  6. Consequences: What changes as a result. Tasks with due dates go in your task tool, not here.

03

When a decision deserves its own note

Not every choice needs a record. If you can answer yes to any of these, write it down:

  • Will someone need to understand it six months from now? Future you counts.
  • Did you weigh options against each other? Then there’s a why that will otherwise get lost.
  • Would it be expensive to reverse? Money, time, trust or a lot of rework.
  • Were several people involved, or did they disagree? Then it helps to record who decided what.
  • Does it rest on an assumption that could change? Market, price, team, tech – anything that might look different next year.

04

Where decisions live in your vault

A decision belongs to the room where it was made. The folder only appears with the first decision that carries weight.

3_Rooms/
└── Ventures/
    └── Flashcard app/
        ├── 00 Overview – Flashcard app.md
        └── 01 Decisions/
            ├── 2026-07-03 Web app instead of native.md
            └── 2026-09-12 One price instead of three tiers.md
9_System/
└── Templates/
    └── Template Decision.md
00 Overview – Flashcard app.md
Purpose, people involved and who decides what. This is where it says who gets to decide in the first place.
01 Decisions/
One file per decision. The name starts with the date, so the folder sorts itself into a timeline.
9_System/Templates/
The template lives in one central place. Agents find it here and stick to its shape. More on the structure

05

Claude writes the note for you

At the end of a discussion, one sentence is enough. Claude reads the template, asks about anything missing and files the note in the right room.

Claude

  1. You: Okay, let’s go with it: one price, $12 a month, no tiers. Log that as a decision.

  2. Tool: read_note · “Template Decision”

    Claude: Will do, using your template. One question first: what are you assuming that makes a single price enough?

  3. You: That almost everyone studies alone and nobody needs a team account. And that three tiers would create more questions than revenue at launch.

  4. Tool: create_note · “2026-09-12 One price instead of three tiers”

    Claude: Created in “01 Decisions” for the flashcard app. Question: how many pricing tiers do we launch with? Options: three tiers, one price, pay per deck. Decision: one price, $12 a month. Reasoning: one page, no comparison table, less support. Your two assumptions are under “What we assumed”.

  5. You: Three schools have asked for classroom accounts. Why didn’t we build a team tier back then?

  6. Tool: search_notes · “price tiers team”

    Claude: According to “2026-09-12 One price instead of three tiers”, because you assumed almost everyone studies alone. The school requests cut against that assumption – a good moment to revisit the decision.

Every change an agent makes shows up in the history with its name and can be undone. [How that works](/docs/kontrolle)

06

Why assumptions are the section that matters most

A decision is rarely just wrong. It was right under certain conditions. As long as those hold, there’s nothing to reopen. The moment one of them breaks, you should – and that’s exactly what you miss without a record.

In the example above, “almost everyone studies alone” isn’t a reason, it’s a bet. When the schools show up, the bet is lost and the decision goes back on the table. Not because it was a bad call at the time, but because the world moved.

So write assumptions you can check: “Under 10% of requests come from teams” rather than “Teams don’t matter”. Then you can tell at a glance whether they still hold.

When an assumption breaks, write a new decision and link the old one with [[2026-09-12 One price instead of three tiers]]. The old note stays as it is. Later you can see how your thinking changed over time.

You don’t revisit a decision on a schedule. You revisit it when an assumption breaks.

07

Decision record or architecture decision record (ADR)?

Software teams know the idea as an ADR. The template here is its cousin for any kind of decision – tech, pricing, hiring or personal.

–Architecture decision recordDecision note in WhyVault
What it’s forTechnical choices: frameworks, databases, interfacesAny decision that carries weight, software or not
Where it livesIn the repository, usually under docs/adr/In the room under 01 Decisions/, next to the overview and meetings
StructureTitle, status, context, decision, consequencesQuestion, options, decision, rationale, assumptions, consequences
AssumptionsUsually buried in the contextTheir own section, easy to check
Who reads itPeople working in the repo, and coding agents thereYou, your team and every connected agent: Claude, ChatGPT, Cursor
What it’s for
Architecture decision recordTechnical choices: frameworks, databases, interfaces
Decision note in WhyVaultAny decision that carries weight, software or not
Where it lives
Architecture decision recordIn the repository, usually under docs/adr/
Decision note in WhyVaultIn the room under 01 Decisions/, next to the overview and meetings
Structure
Architecture decision recordTitle, status, context, decision, consequences
Decision note in WhyVaultQuestion, options, decision, rationale, assumptions, consequences
Assumptions
Architecture decision recordUsually buried in the context
Decision note in WhyVaultTheir own section, easy to check
Who reads it
Architecture decision recordPeople working in the repo, and coding agents there
Decision note in WhyVaultYou, your team and every connected agent: Claude, ChatGPT, Cursor

If your team already writes ADRs in the repository, keep them there. The vault is for everything that doesn’t sit next to the code – and for the why behind it.

?

Frequently asked questions

What’s the difference between a decision log and meeting notes?

Meeting notes capture what was said. A decision log captures what was decided and why – one note per decision, whether it happened in a meeting, a chat or alone at your desk. In the vault, meetings live under 02 Meetings/ and link to the decisions made there.

What do I do when a decision changes?

Create a new decision note and link the old one. The old note stays, so you can see what applied back then. In WhyVault every change is versioned anyway, so nothing gets lost.

Does the template work for personal decisions?

Yes. Moving, changing jobs, a big purchase: question, options and assumptions help there just as much. Many people call this a decision journal. Put the note in the room it belongs to, for example under 3_Rooms/Private/.

Can I use the template without WhyVault?

Of course. It’s plain Markdown and works in Obsidian, a Git repository or any editor. WhyVault adds the fixed place, the structure and agents that read and write the notes.

Can an agent delete or tamper with my decisions?

Agents can’t delete anything via MCP at all. Every change shows up in the history with the agent’s name and can be undone in one click. More on control

All guides

Log your next decision.

The template is waiting in your vault, and Claude fills it in at the end of the conversation. Free up to 20 notes, no credit card.

Start for free