Building a Single Source of Truth: Decision Logs and Operating Docs

Takeaway: Record important decisions where people can find them, connect those decisions to the documents they change, and give every maintained document an owner and review date.

A leadership team agrees to move a launch by two weeks. The next morning, Sales is still using the old date, Support hasn't seen the new plan, and one executive remembers the change as tentative. Three weeks later, the team holds the same debate again because nobody can find the original reasoning.

The meeting wasn't the problem. The decision never became durable.

A single source of truth gives a team one maintained place to answer a defined question. For leadership operations, that usually means a decision log connected to the small set of documents that describe current goals, ownership, cadence, and policy.

Record the reason while it is still available

The software field offers a useful model. Michael Nygard proposed the Architecture Decision Record as a short document containing a decision, its context, and its consequences (Cognitect). Martin Fowler's description of the practice emphasizes the value of preserving why a decision was made, especially after people and circumstances change (martinfowler.com).

That logic transfers cleanly to organizational decisions. The date or vendor name is easy to remember for a while. The rejected options, constraints, and tradeoffs disappear faster. Once the reasoning is gone, a later question can reopen the entire debate.

Writing also tests the decision. Amazon's use of narrative memos reflects the idea that full sentences make gaps in reasoning harder to hide (Amazon 2017 Letter to Shareholders). If the team can't state what it decided, who owns it, and why, the agreement may not be ready to execute.

Define the source narrowly

"Single source of truth" is useful only when the noun is clear. One document won't hold every fact in an organization. Instead, assign one authoritative home to each kind of information:

• The decision log holds significant decisions and their history.
• The goals document holds current priorities and measures.
• The roles map holds current decision rights and ownership.
• The operating-cadence document holds recurring meetings, inputs, outputs, and owners.
• Policies hold the current rules for defined situations.

Other documents can link to that information. They shouldn't maintain a second copy that can drift.

The system also has to be maintained. A page declared authoritative but left stale is simply a more convincing source of error.

Start with a decision log

A decision log is a chronological record of decisions that are significant, cross-functional, costly to reverse, or likely to be questioned later. It doesn't need every routine choice.

Capture these fields:

• Decision: the call in one or two sentences
• Date: when it became effective
• Approver: the single person with final authority
• Driver: the person coordinating the work
• Context: the problem, constraints, and relevant facts
• Options considered: the viable alternatives and why they were rejected
• Consequences: commitments, tradeoffs, and follow-up work
• Status: proposed, accepted, or superseded
• Links: the memo, meeting notes, and operating documents affected

Atlassian's DACI framework separates the Driver from the Approver and calls for one Approver (Atlassian Team Playbook). That distinction is useful in the log. The person running the process may not be the person with final authority.

Follow one decision through the system

Suppose the leadership team decides to move a product launch from October 1 to October 15 so a required integration can complete.

The meeting notes capture the discussion. The decision log then receives this entry:

Decision: Move the launch to October 15 and keep the integration in scope.

Approver: Chief Product Officer

Driver: Product Operations Lead

Context: The integration failed acceptance testing on September 18. The team considered launching without it or moving the date.

Consequence: Sales and Support need revised customer communication by September 22.

Status: Accepted

The launch plan links to that entry and changes its current date. The company roadmap updates once, in its authoritative field. Sales and Support receive the recap because the decision affects their work.

A few days later, the integration recovers and someone proposes moving back to October 1. The original entry isn't deleted. If the team changes course, the old entry becomes "Superseded" and links to the new decision. The history shows why each version existed.

This is the practical meaning of a connected source of truth: one decision moves from meeting capture into a durable record, then updates the documents that govern current work.

Make capture part of the meeting

The log will fail if updating it is optional cleanup. Capture the draft decision during the leadership meeting, read it back before the room closes, and publish the final entry with the same-day recap.

Ask four questions aloud:

1. What did we decide?
2. Who approved it?
3. What changes because of it?
4. Who needs to know?

The chief of staff often stewards the process, but that doesn't make every decision theirs. The approver remains accountable for the call, and each affected document should have its own owner.

Keep operating documents current

The decision log records change. Operating documents describe the current state. Useful examples include the goals and metrics view, decision-rights map, leadership operating cadence, and policies people routinely consult.

Give each core document:

• A named owner
• A visible last-reviewed date
• A stated review trigger or cadence
• A link to the decisions that changed it

An outdated operating document can direct people toward a decision the team has already changed. Ownership and review dates make that risk visible. If a page is no longer maintained, archive it or mark it clearly rather than leaving readers to guess.

Design for retrieval

A precise record has little value if people can't find it. Keep the system simple:

• Choose one home and use consistent names.
• Make the decision log searchable by date, owner, topic, and status.
• Keep each entry short enough to scan.
• Link to detail rather than copying it.
• Refer to the log in meetings until using it becomes normal.

When someone asks, "Didn't we already decide this?" open the entry and review the context. The goal isn't to end discussion by authority. It is to distinguish a forgotten decision from a meaningful change in facts.

Frequently asked questions

What is the difference between a decision log and meeting notes?

Meeting notes capture one meeting. A decision log collects significant decisions across meetings in a consistent structure and preserves their status and reasoning.

What belongs in a decision log?

Include decisions that cross functions, create meaningful commitments, are costly to reverse, or are likely to be revisited. Routine choices can remain in ordinary project records.

Who owns the single source of truth?

The chief of staff may steward the overall system because the role sits near leadership decisions. Each document still needs a named owner responsible for keeping its content current.

How do I keep people using it?

Capture decisions inside the existing meeting workflow, send direct links in recaps, and use the log when questions return. Adoption follows reliability and usefulness more than a launch announcement.

Use the free Decision Log and Single Source of Truth template to start with the core fields, ownership, and status already defined.