# How to keep a decision log that explains what changed and why

A decision made six months ago comes up again. People remember different versions of the outcome, and nobody can find why the rule changed. A short decision log gives the next person the choice, its reason and the record behind it.

Canonical: https://areinum.com/guides/decision-log-why-changed/
Language: en
Updated: 2026-10-31

## Separate the decision from the discussion

Write the question narrowly enough that someone can tell what the answer covers. Mark a recommendation or an unresolved question as pending. Once the authorized person decides, record the choice, decision maker, date and effective date.

Give a concrete reason for the choice. For example, a revision rule might change because the client and the team interpreted the previous wording differently. Link the note, agreement or other record that explains the choice.


## Keep the earlier decision when a rule changes

Create a new entry for the changed decision and identify the earlier entry it replaces. Record which work the new rule applies to and when. Existing agreements may continue on their previous terms unless a change is separately confirmed.

If you correct a factual mistake without changing the decision, label it as a correction and retain the earlier text or source reference. Someone reading the history can then tell a correction from a new choice.

1. Record the question, the authorized choice and its reason.
2. Link the evidence and state the effective date and scope.
3. When the decision changes, add a new entry that identifies the earlier one.


## A fictional change to a revision rule

In the fictional log, decision D-014 says one design revision is included. A later owner decision, D-022, defines one consolidated revision received within five business days for new proposals issued from June 20, 2026. It replaces the earlier proposal rule for that stated scope.

The sample keeps existing client agreements on their accepted conditions unless a separate change is confirmed. Another entry requires a capacity check before rush work is scheduled. These dates and rules are fictional, not suggested contract terms.


## Use the history when the question returns

Find the current entry and follow its reference to the prior decision. Check whether the reason and scope still fit before recommending another change. A leave brief or project handoff can point to the log without reproducing all its history.

A log records the decision; the business still needs to name who can make a new one. The original worksheet preserves the fictional decision history as a supplement.


## Prepare a decision summary with Areinum

Ask Areinum Assistant to organize the supplied decision notes into a timeline of current and replaced rules, with sources and open questions. Review the result and make any new decision through the appropriate owner.


## Questions you may have

### Should we record ideas that were never approved?

They can be useful context if labelled as options or pending recommendations, separate from the decision.

### Do new rules automatically change existing client agreements?

No. Record the rule's intended scope and check the existing agreement and any separately confirmed change.

### What if an old decision contains a factual error?

Mark the correction and retain the previous text or source so the record does not imply the decision itself changed.

## Sources and further reading

- [DACI Decision-Making Framework](https://www.atlassian.com/team-playbook/plays/daci): Atlassian describes Driver, Approver, Contributor and Informed roles and recommends documenting the final decision. The vendor playbook does not validate this adapted log or establish its effect on a particular team. Atlassian describes the Driver, Approver, Contributors, and Informed roles, and recommends recording and sharing the final decision for future teams. This is a vendor playbook, not evidence that the adapted log prevents repeated discussions or that this exact need has validated demand. No outcome statistic from the page is used. (2026-10-18)
- [Tried going off grid for 5 days to see if my business could run without me. It couldn't.](https://www.reddit.com/r/smallbusiness/comments/1r9x049/tried_going_off_grid_for_5_days_to_see_if_my/): A shop owner describes questions about a price adjustment and an earlier verbal purchase approval during an absence. This is one person's account. Identity, prevalence and publication date were not established; no result is attributed to the proposed log. The poster says a shop supervisor did not know how to handle a customer pricing change and an office manager could not identify who had approved an order because the owner said the approval was verbal and undocumented. This is a single self-report on Reddit. The poster's identity and account details are not independently verified, and the anecdote does not establish prevalence or demand. The post displayed a relative timestamp only, so no absolute publication date is inferred. (2026-10-18)

Download the original worksheet: https://areinum.com/guides/decision-log-why-changed/decision-history-log.csv

## Decision history log

The decision owners, dates, rules, and source references in the example are fictional.

| Decision ID | Question | Decision | Decision owner | Decided on | Effective from | Reason | Evidence reference | Supersedes | Status | Applies to |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| D-014 | How many design revisions are included? | One revision is included | Fictional owner: Maya Chen | 2026-02-01 | 2026-02-01 | Fictional starting rule for the sample service | Fictional scope note v2 | None | Replaced | Earlier proposal rule; existing client agreements keep their accepted conditions unless a change is separately confirmed. |
| D-019 | When can rush work be scheduled? | Only after capacity is confirmed | Fictional owner: Maya Chen | 2026-03-10 | 2026-03-10 | Avoid committing a date before the delivery team checks capacity | Fictional capacity review 2026-03-10 | None | Current | Internal capacity check before making a new rush-work commitment. |
| D-022 | How is a revision counted? | One consolidated revision received within five business days | Fictional owner: Maya Chen | 2026-06-15 | 2026-06-20 | The earlier wording was interpreted differently by the client and team | Fictional owner policy note v3 for new proposals | D-014 | Current | New proposals issued from 2026-06-20 only; existing client agreements keep their earlier conditions unless a change is separately confirmed with the client. |

1. Create a separate row for each decision. Use the same decision ID wherever another record refers to it.
2. Record a source link that lets a teammate verify the reasoning. A meeting note can be the source if no formal document exists.
3. When a decision changes, add a new row and fill in Supersedes. Preserve the old row and its effective period.
4. All names, dates, and policy examples are fictional.

### Limits of this method

- The selected class is M because a documented decision framework supports the roles and recordkeeping mechanism; demand for this exact guide was not measured.
- The Reddit post is one historical anecdote and should not be presented as representative evidence. Its page showed a relative timestamp only, so no absolute publication date is inferred.
- A decision log records a decision. It does not assign authority during an owner's absence, replace an active-work handoff, or describe one project's full current state.

## Related reading

- [What to document so decisions can continue while you are away](https://areinum.com/guides/owner-decision-boundaries/)
- [How to hand over active client work before taking leave](https://areinum.com/guides/hand-over-active-client-work-before-leave/)
- [What a replacement project lead needs to continue the work](https://areinum.com/guides/prepare-one-project-for-a-new-project-lead/)

Explore the demo: https://platform.areinum.com/

The demo is in English. Access may need to be arranged.