Knowledge centre · Reviewed 16 September 2026

Decision tracking and decision history

Decision tracking records what was decided, when, by whom, why, and what later changed. A useful decision history preserves the original context and links superseding decisions instead of overwriting them, allowing teams to distinguish a current decision from a proposal, rejected option, or obsolete direction.

What should a meeting decision record contain?

A decision record should contain a concise decision statement, status, decision date, decision-maker or accountable group, relevant conditions, source context, and links to affected work. It should also distinguish the selected option from proposals and capture later corrections or superseding decisions without erasing the original record.

Role frameworks such as Atlassian's DACI model can clarify who drives, approves, contributes, and is informed. The chosen model should match the organisation's decision rights.

How should changed decisions be recorded?

Create a new current decision and link it to the superseded record. Preserve both statements, evidence, dates, responsible actors, and the reason for change. Mark the earlier decision as superseded rather than deleted so later reviewers can reconstruct what guidance applied at each point in time.

What is contradiction review?

Contradiction review compares a candidate decision with relevant earlier records to identify statements that may no longer agree. It is a prompt for human review, not proof of conflict: scope, timing, conditions, terminology, or changed circumstances may explain why two statements appear inconsistent.

Example

An August review approves a September release. A later risk review recommends October. A reviewer links both records, confirms the newer direction, and marks the September decision as superseded.

Contradiction review works best as a lightweight prompt rather than an automated verdict. The system can surface that two records touch the same topic and appear to disagree; a person still has to judge whether the newer statement genuinely replaces the older one, whether both can be true under different conditions, or whether the apparent conflict is really a terminology mismatch between teams describing the same thing differently.

Worked example: recording a decision from proposal to supersession

A product steering group is deciding whether to launch a feature region-by-region or in a single global release. The discussion produces several statements before landing on a decision. Recording it well means capturing the whole arc, not just the final line:

  1. Log the proposals considered — region-by-region and global — as candidate options, each with the reasoning given for and against.
  2. Record the selected option as the current decision, with the decision-maker, the date, and the stated condition ("global release, provided the payments team confirms capacity by the 20th").
  3. Link the source passage where the condition was stated, so a later reviewer can see it was conditional rather than absolute.
  4. When the payments team later reports they cannot meet the date, record a new decision reverting to region-by-region, and link it to the original as a supersession with the reason for change.
  5. Keep both decisions visible with their dates, so anyone checking "what did we decide about the launch" during the intervening window can see exactly which decision applied at that time.

This produces a short, honest history: two decisions, a clear reason for the change, and no ambiguity about which one was current at a given date.

Decision history checklist

  • Use one clear decision statement per record.
  • Record conditions and effective dates.
  • Identify the decision authority.
  • Attach direct source context.
  • Link affected actions, risks, and documents.
  • Preserve correction and supersession history.

Common mistakes in decision tracking

  • Overwriting instead of superseding. Editing a decision record in place to reflect the latest thinking destroys the ability to answer "what was decided at the time" for anything that happened in between.
  • Recording the conclusion without the condition. A decision made "provided X happens" is a different commitment from an unconditional one; dropping the condition when writing the record removes the information needed to judge whether the decision still holds.
  • Confusing a proposal with a decision. An option raised in discussion is not the same as the option the group actually chose; conflating the two in the record misleads anyone reading it later.
  • Treating an apparent contradiction as settled without review. Two records that look inconsistent may both be correct under different scope or timing; flag the conflict for a person to resolve rather than silently picking one.
  • Leaving out the decision authority. Without recording who had the right to make the call, a later dispute about whether the decision was properly authorised has no record to point to.

Limits and authorship

A complete history does not prove that a decision was lawful, informed, or successful. Decision rights, retention duties, and approval requirements depend on organisational and legal context.

Written and reviewed byRagu Mantatikar, Founder of Groundnote

View LinkedIn profile · Published 4 September 2026 · Last reviewed 16 September 2026 · Groundnote is an interested vendor.