Decision Log Template: 10 Fields, a Filled Example and Change History

Choose the right record: decision log, minutes, action list or ADR

A decision log is an index of choices with enough context to interpret them later. Meeting notes organize a conversation. An action list organizes work. An architecture decision record, or ADR, documents a significant design choice. These records can reference one another without becoming interchangeable.

Microsoft’s ADR guidance describes preserving the reasoning behind architectural choices and linking superseding records. We apply that history-preserving discipline to an operational example, while adding separate effective and recording times. That extra timestamp model is our recommendation, not a claim that every ADR format requires it.

Not every routine task needs a long record. Log choices that change scope, allocate scarce resources, set a working rule, accept a meaningful tradeoff or are likely to be questioned later. “Send the agenda” is usually an action. “Limit the pilot to internal written notes until a named review” is a decision. If a single record tries to settle both customer-recording policy and internal note formatting, split the questions and identify their different approval paths.

Gather evidence before filling the template

Collect the source of the question, the actual decision statement, the authority reference, and the options or constraints considered. A chat message may be useful evidence, but its channel or confident wording does not tell you whether its author had the relevant authority. Where the source is ambiguous, record “proposed; confirmation requested” rather than finishing the sentence on somebody’s behalf.

Separate three times: when the decision was made, when the record was confirmed, and when the decision takes effect. A decision accepted on Sunday may become effective on Monday. A log written on Tuesday should not quietly present Tuesday as the decision date. Use an explicit timezone where handoffs cross regions; retain an unknown time as unknown rather than fabricating midnight.

Atlassian’s decision documentation template organizes context, roles, options, actions and outcomes. Its DACI playbook distinguishes the person coordinating a decision from the approver, contributors and people who need the outcome. Those distinctions help identify who to ask. If your organization requires a committee or multiple approvals, record that real rule instead of replacing it with a single-person model.

Evidence must also remain interpretable. Capture a document ID, version or dated passage and the access owner where available. A link that opens today may point to edited text tomorrow. Do not copy restricted material into a broadly shared log simply to make the record self-contained; use an appropriately controlled reference and state the limitation to readers who cannot inspect it.

The ten decision log fields, with filling guidance

1. Stable ID, state and distinct timestamps

Assign an ID once and keep it through ordinary corrections. Record the proposal date when relevant, the authorized decision date, record confirmation, effective time, review time and version. Keep lifecycle state separate from task status: a decision may be accepted but not yet effective, effective with open actions, or superseded with historical actions still visible.

For example, D078-03 is accepted at 16:00 UTC on August 30 but takes effect at 09:00 UTC on August 31. Before that boundary, display both facts. If you collapse them into a single “approved” label, readers cannot determine which instruction applies overnight. An empty approval field means no recorded approval, not permission to infer one from the latest edit.

2. One bounded decision question

State the choice in language that can be answered. Include the affected team, activity and relevant period. “Improve knowledge sharing” is an objective; “May OPS-A and OPS-B use draft assistance for authorized internal written meeting notes during this pilot?” is a decision question.

Do not use a broad title to hide narrower authorization. In the example, an internal drafting pilot does not cover customer calls, recording permissions or personnel discussions. If a proposed extension introduces a new audience or data category, create a separate question instead of rewriting the old title so the expansion appears to have been included all along.

3. Authorized decider, coordinator and consulted roles

Identify who can decide this question and where that authority comes from. Separately identify who maintains the record, who supplied specialist advice and who needs to be informed. Use named people in an appropriately restricted real record, or unambiguous assigned roles where your operating process supports that.

The fictional operations lead can authorize the internal pilot but cannot approve customer-meeting processing under the case’s authority memo. “Operations reviewed it” therefore does not approve that extension. Record required additional review as outstanding. If a contributor dissents, neither their presence nor silence should be rewritten as their consent. A role model helps organize the discussion; it does not grant authority.

4. Context, constraints and the cost of doing nothing

Describe the problem as it was understood at the decision date. Include constraints that could change the answer: permitted inputs, review capacity, dependencies and the acceptable fallback. Separate an observed condition from an expected benefit. “We hope drafting reduces preparation effort” is not evidence that it already does.

In this case, manual notes remain a workable fallback. The team is investigating a narrower drafting method, not rescuing an operation that cannot continue without AI. That distinction matters when a later issue appears: reverting to manual notes is a viable option, not an admission that all meeting documentation must stop. Avoid retrospectively making the initial problem sound more severe to defend the chosen option.

5. Genuine alternatives and comparison criteria

List the alternatives actually considered and compare them on the same decision-relevant criteria. These might include input permissions, human review workload, reversibility and how source statements can be checked. Include the current approach or deferral where it is genuinely possible. Do not invent a weak third option to make the selected one look inevitable.

For D078-01, the feasible alternatives are continuing manual notes or starting a limited internal drafting pilot. Customer-meeting expansion is outside the present authority, so it is identified as excluded rather than scored as a ready-to-launch alternative. When it later becomes a proposal, it receives its own record. Keep proposed benefits and known costs visibly different from measured performance.

6. Evidence, assumptions and missing information

Attach references to the claims they support. Identify which source establishes authority, which reports a problem, and which confirms the decision itself. A meeting transcript can show that a proposal was spoken; it may not show that the proposal was adopted. Make unsupported assumptions visible and assign a person to resolve consequential gaps.

In the example, S06 reports that one reviewer could not open a cited source. It supports reviewing that access problem. It does not establish a whole-system failure rate, a data disclosure incident or a customer impact. The appropriate entry preserves that narrow observation and its uncertainty. Do not improve the apparent completeness of a log by inventing a root cause.

7. Decision, rationale and accepted tradeoffs

Write a direct choice statement, then explain why it was chosen over the viable alternatives. Include important costs or limitations accepted at the time. A useful rationale lets a later reader understand the decision even if they would choose differently with newer information.

D078-01 authorizes limited drafting with human review; it does not declare the draft reliable without checking. D078-03 later pauses that pilot because the source-access issue undermines the intended review process. These are compatible historical statements, not a contradiction to erase. For a proposal such as D078-02, write “no decision recorded” in the outcome field rather than presenting its requested option as the outcome.

8. Dissent, unresolved risks and conditions

Preserve a material objection in neutral language, including its basis and whether the decider accepted, deferred or acted on it. Distinguish dissent about a choice from uncertainty about a fact. Neither is resolved merely because the document has been circulated.

The pilot has no established effort-saving result in this fictional packet. That remains an uncertainty, not a benefit to assert. A source-access problem creates a review trigger with an owner and deadline. It does not automatically cancel the earlier decision unless the operating rule explicitly says so. If a condition genuinely blocks effectiveness, state that condition and the evidence required to satisfy it rather than hiding it in a paragraph of caveats.

9. Actions, communication and completion evidence

Give each follow-up a deliverable, one responsible owner, a due time and a verifiable completion condition. Link the action to the decision that created it. Separate “notify the two teams of the pause” from “investigate the source-access issue”; they have different outcomes and deadlines.

An accepted decision can still have overdue communication. That is a follow-through failure to expose, not a reason to change the decision date. Also distinguish cancellation from completion: a task made unnecessary by a replacement decision was cancelled, not successfully delivered. If your completion metric excludes cancelled work, say so and preserve the excluded rows for inspection.

10. Review triggers, replacement links and correction history

Specify when to revisit the decision and which new evidence should trigger a review. Identify the reviewer and expected response. Link a replacement in both directions: the new record names what it supersedes; the old record points to its successor and effective boundary.

Do not rewrite an accepted rationale to make it appear that later evidence was already known. Use a dated correction for a transcription error and a new decision for a changed instruction. Where restricted or personal information must be corrected, redacted or removed, follow the organization’s authorized process; preserving decision history is not a blanket requirement to retain every source forever. Leave an appropriate record of the change without redisclosing the removed material.

Filled example: one pilot, three records and two different clocks

Read the three decisions together

Everything in this case is fictional. The source packet contains all eight short decision-source documents, the three ten-field records, the event timeline and the five-action ledger. Snapshot: August 31, 2026, 12:00 UTC. It does not contain real customer data or observations of OpenMax execution.

D078-01’s rationale is a reversible trial with review before internal distribution. Its limits are two teams, authorized written notes and a scheduled review; the initial end was September 9 at 09:00 UTC. D078-03 replaces it earlier. D078-02 never becomes an authorization merely by appearing between those two records in chronological order.

The choice in D078-03 is to pause rather than continue unchanged or expand. The access issue is still uninvestigated; the case does not establish a technical cause. Manual notes provide a practical interim method. Restart is not implied by completing the investigation task: another authorized decision must address the evidence and define its effective time.

Reconstruct what applied at a particular moment

At 18:00 on August 30, it is inaccurate to answer “the pilot has already been paused” from these decision records. The pause is approved for the following morning. At 10:00 on August 31, the pause is the current instruction, but the log still cannot prove that everyone has received or implemented it.

The two accepted decisions have owner-confirmed recording intervals of 90 and 60 minutes. Their median is 75 minutes. That is capture latency in this invented packet, not the duration of deciding, a speed improvement or an AI benchmark. The unapproved proposal has no acceptance-to-confirmation interval; exclude it rather than assigning zero. The owner’s new decision follows the access report by four hours, within the case’s 24-hour review rule.

Check follow-through without hiding cancelled or overdue work

Two of four non-cancelled actions are complete: 50%. Including all five rows gives 40%. Neither calculation proves that the current pause has been implemented. In particular, A04 is still open. An honest status summary says “pause effective; notification overdue,” not “pilot safely paused and all stakeholders informed.”

Maintain the log in five practical steps

1. Define the boundary before collecting everything. Choose one project or recurring decision forum, the consequential choices to capture, and the actual authority route. Agree where the authoritative record lives. Expected result: contributors know what belongs in the log and who can resolve ambiguity.
2. Draft from identifiable source material. Fill the ten fields and attach the smallest sufficient references. Keep proposed outcomes, accepted outcomes and missing evidence distinct. Expected result: a reviewer can trace a statement without searching an entire chat history. Stop and ask when authority or the decision itself is unclear.
3. Obtain confirmation without inventing consensus. Have the authorized decider confirm the outcome and the coordinator check dates and actions. Retain material dissent. Record confirmation separately from decision time. Expected result: the log describes a supported choice, not just the recorder’s interpretation.
4. Communicate and check effectiveness. Identify who needs the instruction and when. At the effective boundary, check any explicit prerequisites and inspect action evidence. Expected result: readers can distinguish the current instruction from implementation gaps. Escalate a missed notification instead of silently marking it done.
5. Review and link changes. Revisit scheduled dates and named triggers. Record the review outcome even when it is “continue unchanged.” For a changed instruction, create a replacement and check both links at its effective time. Expected result: a new colleague can reconstruct what applied before and after the change.

Test the process with a modest real decision that your team is authorized to document. Ask a colleague who missed the meeting to identify the current instruction, its source, its limits and the next open action. If the answers depend on a verbal explanation, fix those missing fields before expanding the log.

Select a maintenance method that matches the work

Manual spreadsheet or document. This is often enough for a small, low-volume register. Use stable IDs and a linked detail section when the rationale exceeds one row. Its weakness is drift between the summary and detail; assign someone to check both after a change. Do not buy automation solely because a template has ten fields.

Native wiki or repository workflow. Use the collaboration and history features your team already maintains, after verifying actual access and review settings. MADR provides a Markdown decision-record approach suitable for teams comfortable with files and review. A file history can show edits; it does not by itself show the editor’s authority to change a business rule.

No-code or scripted automation. A carefully configured workflow can copy confirmed fields into a register or remind an owner about a review date. Test duplicate events, failed writes, changed source IDs and timezone boundaries. A reminder sent is not a review completed. Reconcile a failed update before trusting a digest built from the destination.

Agent-assisted drafting. This becomes useful when source notes are unstructured and extracting candidate decisions takes repeated effort. Require sources beside proposed fields and an explicit “not found” result. The critical failure is confident promotion of discussion into approval. Keep a person responsible for accepting the record and a controlled destination outside the draft.

Scaled operation with monitoring and human approval. Multiple teams may need defined access, change queues, reconciliation and accountable exception handling. Those are operating requirements to implement and verify, not benefits guaranteed by choosing an AI tool. If no one owns overdue reviews or contradictory instructions, adding ingestion volume makes the backlog harder to inspect.

Where OpenMax fits: prepare a draft for a human-owned decision log

Start from the documented prompt use case

OpenMax’s operations documentation includes prompt examples for structuring supplied meeting notes and compiling a weekly decisions digest. They request decisions, actions and unresolved questions. That is a relevant starting point for drafting; it is not evidence that your workspace has a configured approval system, automatic lifecycle updates or immutable decision storage.

OpenMax is presented here on its own brand’s site, not as an independent recommendation. This article does not claim a live product test or import performance numbers from marketing examples. For a few clear decisions, manually filling the template may be simpler than introducing another processing step.

Ask for traceable candidates, not invented approvals

Use only material your organization authorizes for this purpose. Provide the authority reference and existing decision IDs along with the notes. A practical original request is:

Draft the ten decision-log fields from the supplied material. For each claimed outcome, identify its source ID and passage. Distinguish proposals from explicitly authorized decisions. Keep decision time, record confirmation and effective time separate. Write “not recorded” for missing approval, ownership or timing. Do not infer agreement from silence. List possible conflicts with existing decisions for a human to resolve. Do not send notifications, change tasks or update the authoritative register.

This is a proposed workflow, not a claim that a prompt creates enforceable access or action restrictions. Inspect the actual tool permissions and handling arrangements before use. Keep the first exercise to minimized, approved written material; customer recordings or personnel information require a separately authorized process and appropriate specialist review.

Compare the draft against the originals before using it

With the fictional source packet, check that the draft leaves D078-02 proposed, keeps D078-01 current at August 30 18:00, and identifies D078-03 as effective after August 31 09:00. It must retain A04 as open rather than treating the approved pause as proof of notification. Check that S06 remains one reported access problem, not a fabricated incident count.

These are expected answers to a teaching exercise; no OpenMax execution has been measured here. When a draft gets one wrong, retain the discrepancy, correct the source-to-field mapping and repeat the review. Only a person with the relevant responsibility should transfer the confirmed record to the authoritative log. Start with the editable template, then decide whether OpenMax is useful for preparing that draft.

Common failure modes and limits of the template

The newest row wins. Chronological order does not establish authority or effect. Filter by scope, supported acceptance, effective conditions and replacement links. A proposal can be newer than the current instruction without replacing it.

A review trigger is treated as an automatic reversal. A trigger may require a review rather than prescribe its outcome. State the rule explicitly. For safety-sensitive processes, follow the applicable authorized operating procedure; this general template does not set stop-work rules.

History becomes a place to store everything. Decision traceability does not require copying every transcript or private comment. Restrict access, minimize source material and follow authorized retention and correction procedures. Get qualified review for legal, employment, financial, privacy or security-sensitive decisions. A filled template is not professional approval or a compliance certificate.

A reconstructed record looks contemporaneous. If you are documenting an old choice, state the reconstruction date, sources available and what cannot now be confirmed. Do not backdate the record or invent participants’ agreement. An incomplete but clearly qualified history is more useful than a confident fiction.

A green task board substitutes for reasoning. Tasks can be complete while the choice rests on a false assumption; a sound choice can have overdue actions. Review both separately. For adjacent work, use the project risk register for unresolved risks and the AI product requirements document guide for detailed product requirements. Link their relevant IDs instead of copying whole documents into the decision log.

FAQ: frequently asked questions

Can I use this decision log template in Excel or Google Sheets?

Yes. Copy the ten groups into columns or use one summary row with a linked detail document. Keep long rationale and source references readable. Test filters for proposed, current and superseded records, and preserve an explicit timezone for date-sensitive decisions. The downloadable Markdown file is editable text, not an Excel workbook or a configured Google Sheets application.

Is a decision log the same as meeting minutes?

No. Minutes or notes record a meeting, while a decision log lets readers find choices across meetings and other authorized processes. Link the relevant meeting record as evidence. Do not treat every idea discussed as an approved decision, and do not assume a decision log replaces any formal minutes your organization requires.

Should I edit the old record when a decision changes?

For a new instruction, create a linked replacement with its own rationale and effective time. Keep the old reasoning identifiable. For a transcription correction, use a dated correction entry. Handle restricted information through the authorized correction or redaction process rather than claiming that preserving history means no content can ever be removed.

How do I handle a decision without an identifiable approver?

Record the source and the uncertainty, keep the outcome unconfirmed or proposed as appropriate, and ask the responsible governance owner to resolve authority. A senior-sounding message, a copied executive or an AI summary does not fill that gap. Do not mark the decision approved just to remove an empty field.

Can OpenMax approve decisions or maintain the log automatically?

The official prompt examples cited here support a supplied-notes drafting use case. This article does not verify native approval enforcement, automatic replacement tracking, reminders or immutable storage in your workspace. Review any proposed integration and permissions separately; keep authorization, effective-time checks and acceptance of the final record under accountable human control.

Sources, verification and editorial boundaries

Primary documentation checked September 5, 2026: Atlassian decision template, DACI playbook, Microsoft ADR guidance, MADR and OpenMax operations prompts. They support the identified documentation practices or prompt descriptions, not the invented case’s timings, ratios or business results.

OpenMax publishes this first-party educational guide. The ten-field arrangement, source packet and case calculations are editorial teaching material. No named customer, independent reviewer, professional certification or successful live workflow is asserted. Before adapting it to consequential real decisions, have the relevant authorized owner and qualified specialists review scope, authority and information handling. The intended result is a record another person can verify—not a longer document that only looks complete.