What is a decision log?
A decision log is a running record of the significant decisions an organisation makes — what was decided, who decided it, why, what alternatives were rejected, and when. It is the difference between a company that remembers and one that re-litigates.
The definition
At minimum, a decision log is a chronological list of decisions with enough context that someone who wasn’t in the room can understand each one later. It answers four questions for every entry: what was decided, who made and approved the call, why it was made (including what was considered and rejected), and when it takes effect.
Engineering teams have kept a narrow version of this for years as Architecture Decision Records (ADRs). A decision log generalises the idea to every kind of organisational decision — vendor choices, pricing changes, policy calls, hiring structures, build-vs-buy.
Why keep one
- The why survives the people. Teams change. Without a log, the reasoning leaves with whoever made the call — and the next person either guesses or re-litigates.
- Decisions stop being re-made. “Didn’t we already try this?” has an answer, with the original reasoning attached.
- Onboarding compresses. A new lead can read the last year of decisions instead of reconstructing them from meeting archaeology.
- Audits get cheaper. When a reviewer asks who approved something and on what basis, you produce a record instead of a search party.
What to capture per entry
| Field | Why it matters |
|---|---|
| Title & ID | One line, findable later. An ID makes decisions citable (“per D-214…”). |
| Status | Draft, in review, approved, superseded. A decision’s life doesn’t end at approval. |
| The decision itself | The call, in plain language — written so it can be acted on without the meeting. |
| Context / why now | What forced the decision at this moment. This is the field people miss most later. |
| Alternatives considered | What was rejected and why. Prevents the rejected option being “discovered” again next year. |
| Roles | Who drove it, who approved it, who was consulted. Frameworks like RACI, DACI, or RAPID name these; the log records them. |
| Date & review date | When it took effect — and when it should be revisited, if it was a “for now” call. |
| Links | The strategy it serves, the work it triggers, the records it touches. |
Want the full field-by-field version? See our decision record template.
Where decision logs fail
- No owner. A log that everyone may edit and no one must maintain decays in a quarter.
- No enforcement. A spreadsheet can’t require an approver to actually approve. Entries say “decided” without anyone accountable having signed.
- No integrity. Docs are editable after the fact, which is exactly what an auditor will ask about.
- No connection. A standalone list can’t tell you what a decision touches — the strategy above it or the work below it.
- Capture friction. If writing an entry takes longer than the meeting, entries stop being written.
From log to system of record
These failure modes are why a decision log eventually wants to be a system: capture that starts from the conversation you already had, approval routing that won’t mark a decision approved until the accountable person signs, a tamper-evident history, and links that connect each decision to the goal it serves. That is the gap Traceway is built to close.
Stop losing the why.
Traceway is the system of record for decisions — AI capture, real governance, an audit-grade trail, and a chain from strategy to the work. Coming 2026.
Join the waitlist →