DraftlizeVOL. 1 · 2026 EDITION
Start free →
Guide · Decision Logs

Most decision logs rot.
Here's the living kind.

A decision log is supposed to answer one question six months later: "why did we decide this?" Most never do. They get written once, buried in a doc, and quietly go stale while the product moves on. The problem isn't discipline — it's that a static document can't know when a decision it recorded no longer holds. Draftlize makes the decision log something an AI agent reads and writes, where every dependent decision flags itself stale the moment one upstream changes.

TL;DR

A doc vs a living decision log.

A decision log written in Notion, Confluence, or a markdown ADR is a snapshot. The moment a decision changes, the log is wrong and nobody knows. The fix isn't more discipline — it's a substrate that tracks the dependencies for you.

DraftlizeDoc / Confluence / markdown ADR
Recording a decisionTyped card: decision, rationale, alternatives, dependenciesA paragraph of prose
Findable six months laterAddressable by URL / IDBuried, you grep the wiki
A decision changes — do dependents know?They auto-flag staleNo link; it silently rots
Can an AI agent use it?Native read + write via MCPReads flat text at best
Who keeps it consistentThe substrate tracks itYour willpower
Conflict with an earlier decisionSurfaced automaticallyDiscovered in the next post-mortem

Why decision logs rot.

I

Written for a reader who never comes back

A decision log is written for "future us." But future us is busy, and the log lives in a doc nobody reopens. Architecture decision records have existed since 2011 and have always atrophied for exactly this reason — the audience is human, and humans don't re-read.

II

No link between a decision and what depends on it

You decide pricing in week 3. In week 7 you change it. The three specs that assumed the old price are now wrong — but nothing connects them to the decision, so nobody updates them until something breaks in a demo.

III

Maintenance is manual, so entropy wins

Every decision log dies the same death: it's perfect on day one and 40% wrong by day ninety. Keeping it current is a chore that competes with shipping, and shipping always wins.

What a living decision log does.

I

The AI agent is the reader who never forgets

When the log's primary reader is an agent — one that reads every relevant card before it drafts the next spec — the decision log stops being a graveyard and becomes ambient context. It gets read on every turn, not at the next post-mortem.

II

Change one decision, dependents flag stale

Each decision is a card with explicit dependencies. Change the pricing decision and every card that depended on it turns stale automatically — the same way a build system invalidates everything downstream of a changed file.

III

Every decision is addressable

A decision is a card with a stable ID, citable from a spec, a thread, or Claude Code via MCP. "Per decision c-04" becomes a real link, not a vague memory — and a decision log template or architecture decision record becomes a starter pack you clone, not a blank page you dread.

A decision log is only useful if something reads it back. Make that something an agent that never skips a card.
The discipline you couldn't sustain by hand, the substrate sustains for you.
FAQ

Common questions.

What is a decision log?

A decision log is a running record of the significant decisions a team makes — what was decided, why, what alternatives were considered, and when. Its job is to answer "why did we decide this?" months later, so the reasoning is not lost and old choices are not re-litigated every sprint.

What should a decision log include?

Each entry should capture the decision itself, the context and problem behind it, the alternatives you weighed, the rationale, the date, and the people or specs that depend on it. That last field is the one most logs omit — and it is exactly what lets you know, later, what breaks when the decision changes.

Why do decision logs stop being useful?

Because a static document cannot know when a decision it recorded stopped being true. It is written once, buried in a doc, and quietly goes stale while the product moves on — and since nothing links a decision to what depends on it, nobody updates the downstream work until something breaks.

How does Draftlize keep a decision log current?

Draftlize makes each decision an addressable card that an AI agent reads and writes. Every dependent card declares what it relies on, so when one decision changes, everything downstream auto-flags stale — the discipline you could not sustain by hand, the substrate sustains for you.

Start your decision log free with $5.

New accounts get $5 freePay only for what you useBalance never expires

Spin up a project, seed it from your existing docs, and let the agent keep your decisions — and everything that depends on them — current.

Start free with $5
Use this template

Open this template as live cards.

One 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.

Decision tracking