A decision log your AI can use: what to write down
Published .
Most decision log templates are built for an audit. They have an ID, a date, an owner and a status, and they answer one question well: who approved this, and when?
An AI that reads your log needs something else. To make the next call the way you would, it needs your reason and the condition that would have changed your mind. So does a new colleague. This guide covers which fields carry that, and how to fill them.
What the usual templates record
- The project log. ID, date, owner, decision, status. It is good for accountability and thin on reasons.
- The architecture decision record. Michael Nygard’s 2011 format has five parts: title, context, decision, status, consequences. Context is “the forces at play”, which is close to what an AI needs.
- The decision journal. A personal notebook: what you expected, how confident you were, what happened. It is built for learning from outcomes.
Investors have started to call such records “decision traces”. A Foundation Capital essay from December 2025 describes them as “the exceptions, overrides, precedents, and cross-system context that currently live in Slack threads, deal desk conversations, escalation calls, and people’s heads.”
Five fields an AI can reason from
- The situation. What was on the table, in general terms. No client names.
- The decision. What you did, stated so that someone could check it.
- The reason. Why, the way you would say it to a colleague. “The team agreed” does not count.
- What you gave up. The option you turned down, and what it would have bought.
- What would have changed it. The condition under which you would have gone the other way.
Three more are worth adding when you have them: the date, what happened afterwards, and whether you would decide differently today.
A worked entry
An illustrative entry, not taken from a real company:
A candidate with a strong portfolio asked for 20% above our pay band. We held the band and offered a salary review at six months. Paying one person above the band reprices the whole team on the day it becomes known. If the role had been open for more than three months, we would have moved it to the next band instead.
Read against the five fields:
- Situation: a strong candidate asks for more than the band allows.
- Decision: hold the band, offer a review at six months.
- Reason: one exception reprices the team.
- Given up: possibly this candidate.
- What would have changed it: a role open for more than three months.
An assistant that reads this can handle a case the entry never mentions. Asked about a candidate who wants more equity, it knows to ask how long the role has been open.
Recalling decisions you never wrote down
Ask an expert for their rules and you get the textbook. Michael Polanyi put the reason in one line in The Tacit Dimension: “we can know more than we can tell.”
The psychologist Gary Klein got around this by asking about events. His Critical Decision Method is “a retrospective interview strategy that applies a set of cognitive probes to actual, non-routine events”. You can run a short version on yourself. Pick one real case and answer:
- What did you notice first?
- What did you consider and drop, and why?
- What would someone with two years in the job have done?
- Which single fact, had it been different, would have changed your call?
For the cases themselves, look where you explained yourself: sent mail, review comments, proposals you declined, and the answer you give every time someone asks the same thing.
Four mistakes that make a log useless to an AI
- Only the dramatic calls. Ordinary decisions show your usual practice. A log of exceptions teaches the exceptions as the rule.
- Outcome in place of reason. “It worked” says nothing about why you chose it.
- Rules with no case behind them. “Never discount” reads as absolute. The case shows where it bends.
- Names and deal figures. They add nothing an AI can reuse, and they are not yours to share. A threshold you apply is fine.
From a log to something an AI reads
Ten or twenty entries fit in a system prompt or a project file. Paste them in, then test the assistant on a case that is close to one of them without matching it.
A larger log, or one that other people’s assistants should read, needs its own home. Skill, system prompt or MCP compares the options. In avva Studio your own assistant drafts entries like these from your history, and you approve each one before a Decision Model is built from them.