A decision log is the single artifact that lets next quarter's team understand why this quarter's team chose what it chose. Most decisions live in Slack threads and meeting notes that evaporate when people move on, so the same debates get relitigated and no one can trace what a choice rested on. The Stratenity decision log captures four things per row: the decision and rationale, the evidence cited, the owner and date, and the implications. Used well, it turns scattered memory into an auditable record that survives turnover and holds up under scrutiny.
What a decision log actually is
A decision log is a running, structured record of the consequential choices an engagement or program makes, held in one place and written so that a reader who was not in the room can understand what was decided and why. It is not a meeting minutes archive and it is not a task tracker. It captures decisions specifically: the moments where the team closed off options and committed to a direction. Everything downstream, from workstream plans to hiring to spend, flows from those commitments, so the log is the spine that connects intent to action.
The reason this matters is that decisions decay faster than any other kind of knowledge. A choice made in March feels obvious in March and inexplicable in September, once the people who made it have rotated off and the context has faded. Without a log, teams relitigate settled questions, reverse decisions without knowing they are reversing them, and cannot answer the board when it asks why a particular path was taken. A decision log fixes the record while the reasoning is still fresh, so the commitment holds even as the people around it change.
A decision log is also a governance instrument, not just a memory aid. Under any serious oversight regime, someone will eventually ask who authorized a choice, what evidence they relied on, and whether the risks were understood at the time. A log answers those questions in seconds rather than sending the team back through months of email. It converts a defensive scramble into a clean paper trail, and in doing so it changes the behavior of the team that keeps it, because a decision written down for the record tends to be a decision made more carefully.
Four fields that make a decision auditable
Every entry in the Stratenity decision log carries four fields. Each one exists to close a specific failure mode, and an entry that is missing any of them is not yet a usable record. The discipline is to fill all four at the moment of decision, not to reconstruct them later.
| Field | What it captures | Failure it prevents |
|---|---|---|
| Decision and rationale | The specific choice made and the reasoning that justified it, stated plainly | Choices that later look arbitrary because the logic behind them is lost |
| Evidence cited | The data, analysis, or source documents the decision rested on | Debate that reopens because no one remembers what the choice was grounded in |
| Owner and date | The named person accountable for the decision and when it was made | Diffuse ownership where a decision belongs to everyone and therefore no one |
| Implications and follow-on | What the decision commits the operation to and the work it triggers | Decisions that are recorded but never converted into action |
One row per decision keeps the log usable. The temptation is to bundle several related choices into a single entry, but that hides accountability and makes the reopen logic impossible, because two decisions in one row rarely share the same trigger. The discipline is to split them: if the team decided both the fulfillment model and the launch date, those are two rows with two owners and two sets of implications, even if they were agreed in the same meeting. A log with clean, atomic rows can be filtered, audited, and reopened decision by decision, which is what makes it an operating tool rather than a narrative record.
Worked example. A retail client is choosing a fulfillment model for a new market. The entry reads: Decision, launch with a third-party logistics partner rather than building an owned warehouse. Rationale, volume in year one does not justify fixed capital and a 3PL preserves optionality. Evidence, the demand model dated 14 March showing 12,000 units per month at steady state and the capital comparison memo. Owner, VP Operations, 18 March. Implications, triggers a 3PL selection workstream, defers the warehouse capital request to the year-two review, and sets a reopen trigger at 25,000 units per month. Anyone reading that in September knows exactly what was chosen, why, and what to watch.
Notice how the four fields interlock in that single row. The rationale explains the choice, the evidence lets a skeptic test it, the owner gives it an accountable author, and the implications turn it into scheduled work with a defined trigger to revisit. Strip any one field out and the entry loses its power. Drop the evidence and it becomes an assertion. Drop the reopen trigger and a forecast-based bet quietly hardens into a permanent assumption no one remembers to question.
Where the log lives matters as much as its structure. A decision log buried in a document no one opens is only marginally better than no log at all. The best versions sit where the team already works, whether that is the engagement workspace, the program tracker, or a shared table the operating cadence reviews on screen. It should be searchable, so that when a new question arises someone can check in seconds whether it was already settled, and it should be owned by a single person who is responsible for keeping it current, because a log that everyone can edit and no one maintains decays into an unreliable record faster than an untended inbox.
Running the log so it stays alive
A living decision log is maintained as decisions happen, not assembled in a burst before a review. The moment a group commits to a direction, someone captures the row while the reasoning is still in the room, because reconstructing rationale a week later produces a thinner, less honest record. The habit that keeps a log healthy is small and consistent: a standing minute at the end of every decision meeting to ask, out loud, what did we just decide, who owns it, and what does it commit us to. That thirty-second ritual is what separates a log that reflects reality from a document that gradually diverges from the choices the team is actually living with.
- Introduce the log in the engagement proposal or the first week, so the client is committed to operating with it before the first hard decision arrives, not after.
- Log a decision at the moment it is made, in the meeting, rather than reconstructing the reasoning days later when the context has already softened.
- Assign one named owner per decision. If a decision genuinely belongs to a committee, name the individual accountable for carrying it, not the committee.
- Link the evidence directly, using a document name, date, or retrieval ID, so a reader can pull the source rather than take the rationale on faith.
- Review the log at each operating cadence checkpoint and mark the reopen triggers, so decisions that were made under assumptions get revisited when those assumptions break rather than quietly ossifying into permanent constraints.
Where decision logs go wrong
- Logging discussion instead of decisions. If an entry does not close off options, it is a note, not a decision. The fix is to record only the moments where the team committed to a direction.
- Rationale written as a conclusion with no reasoning. "We chose the 3PL model" is not a rationale. The fix is to state the tradeoff that made the choice preferable to the alternatives.
- Evidence cited as a vague reference. "Based on the analysis" is untraceable. The fix is to name the specific document, date, or dataset so it can be retrieved.
- No owner, or an owner that is a team. Shared ownership means no one is accountable when the decision needs to be defended. The fix is to name one person per row.
- The log is written and then never reopened. Decisions made under assumptions rot when the assumptions change, and a stale log is worse than none because it lends false authority to choices that no longer hold. The fix is to attach reopen triggers and review them on cadence.
Ship a working log this week
- Create the log with the four columns before the first consequential decision of the engagement.
- Backfill the two or three decisions already made, so the log starts complete rather than partial.
- Confirm every existing entry names one owner and links one dated piece of evidence.
- Add a reopen trigger to any decision that rests on a forecast or assumption.
- Put a five-minute log review on the recurring operating cadence agenda.