You came for a decision log template — the fields, the headings, something to paste into a doc. It's below; take it. But know what you're getting: a template is a fill-in-the-blanks format, and the instant you finish filling it in, it starts going out of date. Nothing in a Notion table or a markdown file connects a decision to the specs that depend on it, so when the decision changes, the log quietly becomes fiction. Draftlize gives you the same eight fields — and makes each one a card an AI agent reads and writes, where everything downstream flags itself stale the moment one decision moves.
This is the whole template. It works in a doc, a wiki, or a markdown file — it's the same shape as an architecture decision record (ADR). Use it as-is. The next section is about what changes when each field stops being text and becomes a card.
The call, stated in one line. "We charge per use, not per seat." If you can't compress it to a sentence, you haven't decided yet.
The situation that forced the choice. What was true, what was constrained, what pressure made this a decision rather than a default.
The alternatives that were real, not strawmen. The value of a decision log is mostly here — it stops you re-litigating a path you already rejected, with reasons.
Why this option won and the others lost. The single field your future self actually opens the log to read. Be honest about the trade you accepted.
The specs, decisions, and work that assume this holds. In a doc this is a list you'll forget to update. It's the field that decides whether the log stays true.
Proposed, accepted, superseded — or stale. A decision isn't permanent; the log has to be able to say "this no longer holds" without deleting the history of why it once did.
The person to ask when the rationale stops making sense. Not for blame — for the follow-up question six months out.
When it was decided. Cheap to record, and the thing that lets you read decisions in the order they actually happened.
That's the template. Below: why filling it in is the moment it starts to rot — and what we do about it.
The eight fields are good — that's why ADRs have used roughly this shape since 2011. But a format only captures the decision once. It has no idea when the thing it recorded stops being true, because a table of text can't watch the rest of the product change.
You dutifully list what depends on a decision. Then the decision changes, and updating those dependents is now manual archaeology — find every spec that assumed the old call, by memory. Nobody does it. The field that was supposed to keep the log honest is the first to lie.
The template is most accurate the minute after you finish it, and never that accurate again. By day ninety a real fraction of it is wrong, and you can't tell which fraction — so the whole log gets quietly distrusted, which is worse than not having one.
In Draftlize the template isn't a blank table — it's a typed card with those exact fields: Decision, Context, Options, Rationale, Dependencies, Status, Owner, Date. Structured, addressable by ID, and citable from a spec or a thread instead of buried in a wiki page.
Because Dependencies is a real link and not a list of nouns, changing a decision turns every card that rested on it stale automatically — the way a build system invalidates everything downstream of a changed file. The promise the template made, the substrate keeps.
Claude Code or Cursor, over MCP, reads every relevant decision before it drafts the next spec and writes new decisions back into the same shape. The log stops being a document for a reader who never returns and becomes context that gets read on every turn.
A template tells you what to write down. It can't tell you when what you wrote stopped being true.Keep the eight fields. Let the substrate keep them current.
A decision log is a running record of the significant choices a team made, why they made them, and what was decided against — so the reasoning survives past the meeting and nobody re-litigates a settled call six months later. Each entry typically captures the decision, context, options considered, rationale, dependencies, status, owner, and date.
An architecture decision record (ADR) is a decision log specialised for engineering choices — same eight-field shape, narrower scope. A decision log covers product, pricing, and strategy calls too. If you already write ADRs, a decision log is the same discipline applied to the decisions upstream of the architecture.
Decision (the call in one line), context (why now), options considered, rationale (why this won), dependencies (what rests on it), status (proposed / accepted / superseded / stale), owner, and date. The rationale and the rejected options are the fields your future self actually opens the log to read.
Anywhere text lives — a wiki, a markdown file, a Notion table. They go stale because nothing connects a logged decision to the specs that depend on it, so when the decision changes the log quietly becomes fiction. Draftlize keeps the same eight fields as cards and auto-flags every dependent stale the moment a decision moves, so the log updates itself instead of rotting.
Take the template above, or spin up a project and let the agent fill it in from your existing docs — then keep every decision, and everything that depends on it, current for you.
Start free with $5One click creates a project with these exact sections as typed, linked cards. Answer them with the agent — and when a decision changes later, every dependent section flags stale instead of silently drifting. $5 free credit on signup, no card required.