What a decision log actually is
A decision log is a numbered, dated, structured record of every significant decision made during a project — who made it, what alternatives were considered, what information it was based on, and what authorized it. It is not a meeting summary. It is not a Slack archive or a collection of email threads. It is a single governed document that makes the decision-making history of a project legible to anyone who needs to understand why things are the way they are. Its primary value is not historical — it is operational. When a scope question arises mid-project, the log resolves it without a meeting. When a stakeholder challenges a prior commitment three months later, the log answers without a search.
What each entry contains
Each entry has six elements. A sequential ID — DL-[YYYY-MM-DD]-[number] — that makes the entry citable in any downstream document. The decision itself, stated in one sentence: not the discussion, not the context, just the decision. The alternatives considered and why they were rejected. The information or constraints that drove the decision. Who made it, in what capacity, and under what authority. Whether the decision is final or subject to review under named conditions. An entry missing any of these six elements is incomplete — and an incomplete entry produces the same downstream ambiguity as no entry at all, because when a challenge arises, the partial record cannot answer it.
How it prevents scope drift without blocking scope evolution
Scope drift is the accumulation of undocumented decisions that expand a project beyond its original definition. The expansion itself is not always the problem — scope evolution is sometimes legitimate and commercially correct. The problem is undocumented expansion, because an undocumented change cannot be evaluated against budget, timeline, or quality standards. A decision log prevents drift not by blocking changes but by requiring every change to be explicit. A client who requests an additional feature must have that request logged — with the scope impact, the cost impact, and the authorization required to proceed. When the log exists, the conversation about changes moves from assumption and memory to record and accountability.
Its role at the point of release
Release authorization — the confirmation that the output matches what was scoped, what was agreed, and what was built — requires a documentary record, not a reconstruction from memory. The person authorizing a release cannot evaluate whether every decision made during the build aligns with the original scope unless those decisions are documented and accessible. Without the log, release authorization is a judgment call: a confident assertion that the build matches intent, based on familiarity with the project. Familiarity and accuracy are not the same thing — and that distinction matters when a stakeholder challenges a deliverable, when a mid-project scope change compounds into a missed requirement at handoff, or when a client returns months later with a question about why something works the way it does. With the log, release authorization is a verification: a check against a documented record that confirms the decisions made were the decisions that were authorized. That shift — from judgment call to verification — is what makes accountability possible rather than assumed, and what allows a release to be defended if it is later challenged.