AI decision log template that keeps itself

Most decision logs are empty by week three, not because the decisions stopped happening, but because writing them down became one more thing to remember to do.

A decision log is worth almost nothing if it depends on you remembering, after the fact, to go write down what you decided. The decisions worth logging usually get made in the middle of something else: a call, a thread, a conversation you were not framing as "making a decision" at the time.

The version that actually stays current logs decisions as a side effect of the material you already generate, rather than a form you fill out afterward.

There is also a quieter reason most decision logs die: a blank template asks you to decide, up front, whether something is important enough to log, and that judgment call is exactly the kind of extra step that gets skipped under time pressure. A log built from what you already generate does not ask that question first. It logs the decision, and lets you correct it later if the system got the significance wrong.

What triggers it

A decision surfaces in a meeting transcript, an email thread, or a note, or you simply say what you decided out loud and it gets caught in the next pass.

What the system does

1. Recognizes a decision, not just a mention

It distinguishes an actual decision, a chosen path with something ruled out, from a passing mention of an option that was only discussed. Only the former gets logged as decided.

2. Writes one line, dated, with the reasoning

What was decided, when, and the one or two lines of why, so that six months later the log explains itself without you having to reconstruct the context.

3. Attaches it to the project it belongs to

The decision lives inside that project's own file, not in a separate decisions app disconnected from everything else about the project.

4. Never overwrites a decision, only adds to it

If a decision changes later, that is a new dated line, not an edit that erases what the earlier reasoning was. The log is a record, not a snapshot.

What lands in front of you

A dated line added to the right project's decision log each time something gets decided, and, on request, the full log for a project as one readable list rather than something you have to reconstruct from old meeting notes. Read straight through, that list is effectively the project's own memory of why it looks the way it does today.

What you still decide

Whether what the system flagged as a decision actually was one, versus an option that is still open. False positives are cheap to correct; a decision that never got logged is the expensive failure this workflow exists to prevent. You also decide when a logged decision has been superseded, which is itself worth a new dated line rather than a silent edit to the old one.

What a decision log is, and why decisions rather than tasks

This is build-list item three of the book: track decisions, not just notes and tasks. A task tells you what to do next. A decision log tells you why you are doing it, which is the part that actually saves you from relitigating the same question every quarter. It pairs directly with project status tracking that updates itself and with the weekly review workflow, where stale open decisions get surfaced.

The relitigating problem is the real cost most people underestimate. Without a record, a settled question comes back around every time the people involved change or memory fades, and each time it gets debated again from scratch, as if for the first time. A dated log with the reasoning attached ends that conversation in one line: here is what we decided, here is why, here is when it might be worth revisiting. That is exactly the kind of relitigating founders and investors run into most, since decision history is most of the value in those roles.