How to Update a Decision Log Without Losing History
- How do you update a decision log?
- Where does the replacement-record idea come from?
- Is this a correction, an observation, or a new choice?
- What belongs in the new record?
- What would two connected records look like?
- How should the old record point to the new one?
- What if a replacement is rejected or only partly accepted?
- How do you keep the history usable?
- Sources
How do you update a decision log?
Update a decision log by distinguishing a factual correction, an outcome note, and a changed decision. Date the addition and explain what changed. For a replacement decision, give the new record its own identifier, link it to the earlier record, and show which choice currently applies. Keep proposed changes separate from approved ones. Use your organization's authorized correction, access, and retention processes for protected records.
A log is most useful when you can read it without reconstructing a conversation. The question is not simply whether the note is up to date. It is whether you can tell what was believed then, what became known later, and what you are meant to do now.
This is a lightweight editorial method for ordinary personal and project notes. It is not a substitute for formal approvals, regulated records management, or professional advice. Start with the basic decision log if you have not yet recorded the original choice.
Where does the replacement-record idea come from?
Architectural decision records, or ADRs, document significant software-design choices. AWS describes an accepted ADR as fixed: a changed decision goes through a new proposal and acceptance process, after which the earlier record is marked superseded. That is a software-team workflow, not a rule governing every personal notebook. AWS's ADR process supplies the useful distinction between revisiting a choice and quietly rewriting it.
Microsoft likewise recommends a linked replacement when an accepted architectural decision changes. Its guidance includes status labels and keeping the reasons alongside the outcome. Microsoft's architecture-record guidance is specifically about workload architecture.
The worksheet below adapts that narrow idea. Its dates, labels, and examples are our editorial design, not a tested productivity intervention or a prescribed AWS or Microsoft personal-review system.
Is this a correction, an observation, or a new choice?
Use the smallest change that accurately describes what happened. In this proposed method, three kinds of update have different jobs.
| What happened | Suitable note | What it must not imply |
|---|---|---|
| You typed the wrong meeting date | Dated correction identifying the error and its verified replacement | That the original date was always recorded correctly |
| You learned how the choice worked out | Outcome addition with the observation date | That a new approach has already been chosen |
| You chose a different approach | Separate replacement record, with its approval and effective status | That merely discussing the alternative made it current |
A correction needs evidence. If you cannot establish which of two dates is right, record the discrepancy and the next verification step. Do not choose the one that makes the chronology look neater.
An outcome can be disappointing without requiring a replacement decision. “The summary arrived late” is an observation. “We will use a different summary format” is a choice. Keeping those statements separate leaves room to consider the cause instead of treating the first inconvenience as a verdict.
What belongs in the new record?
For a changed decision, make a short record containing:
- A stable identifier and a descriptive title.
- The earlier record's identifier or link.
- The date the replacement was proposed.
- The new information or changed constraint prompting review.
- The alternatives now being considered.
- The choice, its reason, and the tradeoff being accepted.
- Who may approve it, and whether that approval has happened.
- When the choice is intended to take effect.
- A later check that can establish whether implementation happened.
A stable identifier can be as plain as D-014. It is a reference, not a ranking. Keep it attached to the same decision even if you improve the title.
For an individual note, you may be the decision-maker. For shared work, do not infer approval from being the person who maintains the log. Identify the responsible person or process. Leave a missing approval marked unresolved.
Keep sensitive details out of a general-purpose worksheet. Use authorized storage and appropriate access restrictions. If a record contains information that should not be there, follow the applicable correction or incident process; do not create another unrestricted copy in the name of preserving history.
What would two connected records look like?
Here is a fictional example about an internal project-summary format. The identifiers, dates, observations, and decisions are invented to demonstrate the method.
D-014 — Use a paragraph for the project summary
The original choice was accepted on September 1, 2026. Its reason was to keep the weekly summary readable in one short passage. The note expected readers to find the current action within that paragraph.
On September 8, the writer adds an outcome note: the paragraph describes progress, but the current action is not consistently distinguished from background information. That observation does not itself change the agreed format.
D-021 — Separate the current action from background
The replacement is proposed on September 8. It would use two labeled fields: “Current action” and “Background.” The alternative is to retain the paragraph and put the action first. The proposed reason for choosing fields is to make the distinction explicit, accepting a more repetitive layout.
The example's authorized owner accepts D-021 on September 9, with an effective date of September 14. Until that effective date, D-014 remains the applicable format in this fictional workflow.
The date sequence is:
| Date in the example | What the record can honestly say |
|---|---|
| September 8 | A replacement is proposed; it is not approved |
| September 9 | The replacement is approved for September 14; it is not yet current |
| September 14 | The replacement takes effect under the recorded arrangement; implementation still needs checking |
| September 15 | A dated follow-up can record whether the new fields were actually used |
Approval, applicability, and implementation are three different facts. A September 9 approval does not prove that anyone used the new layout on September 14. If the effective date changes, record that change through the appropriate process rather than leaving the table to contradict current instructions.
How should the old record point to the new one?
Add a clearly dated status annotation where a reader will notice it. For the example, the September 9 annotation could read:
“D-021 accepted on September 9; scheduled to replace this format from September 14. D-014 remains current until then.”
When the replacement takes effect, the annotation can state:
“Superseded from September 14 by D-021. The original reasoning below describes the earlier choice.”
The replacement points back to D-014. The old record points forward to D-021. In a paper notebook, page references can do the same job. Check both directions; a reference to a renamed or inaccessible file is not useful simply because it is underlined.
Do not label the old record “wrong” merely because circumstances changed. A choice made for an earlier constraint may explain the work perfectly well. Its historical usefulness and its current applicability are different questions.
What if a replacement is rejected or only partly accepted?
A rejected proposal is not a replacement. In your note, record that it was not adopted and explain the unresolved concern. Do not change the current record's status to superseded just because you spent time drafting an alternative.
For a partial change, name the boundary. In the fictional example, the owner might accept the two-field layout only for one project while retaining paragraphs elsewhere. The replacement note should identify that limited scope, not announce a universal new format.
If two records appear current and conflict, flag the conflict for the responsible decision-maker. Do not silently select the newest file timestamp. That timestamp could reflect a typo correction rather than an authorized decision.
How do you keep the history usable?
Add the new record to the same index as the old one, with its status and the decision it replaces. Put unresolved approval or implementation checks into your weekly notes review. A review reminder is a prompt to look, not evidence that the change has occurred.
When a project finishes, link its current decision chain from the project closeout note. Keep detailed records in their canonical location rather than pasting slightly different versions into every summary.
Before finishing an update, ask:
- Can a reader identify the currently applicable choice?
- Can they distinguish proposal, approval, effective date, and observed implementation?
- Does each correction explain its basis?
- Can they find the previous reasoning without mistaking it for current instructions?
- Have access, correction, and retention requirements been respected?
You do not need a biography of the decision. You need enough of its history to change course honestly and enough clarity that the next reader knows where the course now leads.
Sources
- AWS Prescriptive Guidance: Architectural decision record process, read September 8, 2026. Software-specific acceptance and supersession process.
- Microsoft Learn: Maintain an architecture decision record, updated April 13, 2026; read September 8, 2026. Linked replacement records and architectural decision context.