Someone changes the handoff format, and the next person sees two instructions without knowing which one applies. Give each recorded decision an ID, a clear outcome, its reason, and a link to any decision that replaces it. Keep the old record readable so the change has an explanation.
Consider this original fictional exhibit project. The team initially chooses a printed volunteer brief, then changes the delivery arrangement after receiving a revised route. These records illustrate a document structure; they are not approvals from a real project.
Open the complete example · Download the full HTML source
D01 — Printed route brief. Recorded choice: use the printed route brief for the supplied volunteer session. Reason: the exercise initially assumes the route is fixed. Consequence: corrections require a revised paper copy. In the fictional later snapshot, D02 replaces D01.
D02 — Revised maintained brief and session paper. Recorded choice: use the revised maintained route brief for preparation and provide the session’s required paper copy at check-in. Reason: the exercise now includes a route change. Consequence: the coordinator must check that the paper copy matches the accepted revision. D02 replaces D01; the preparation channel and real dates remain to be supplied.
D02 changes the delivery arrangement. It does not show that a coordinator has already distributed anything or that a volunteer received the correct copy.
Separate a choice from an action to carry it out
Write the outcome as a decision someone can interpret: “Use the revised maintained route brief for preparation.” Then list implementation work separately. “Coordinator checks the paper revision” is work created by that choice; checking a box beside the decision does not perform it.
The AWS guide to architectural decision records describes context, the decision, consequences, status, and a change history. Its subject is software architecture. This exhibit log borrows the explicit record structure as an authored project example; it is not an AWS event-management procedure.
Give the next reader the context that mattered
Use this blank scaffold for each entry:
Decision ID and title:
Scope and question being decided:
Context and supplied alternatives:
Outcome actually decided:
Reason and supporting record reference:
Consequences and separately assigned follow-up work:
Decision owner/authority and date, where confirmed:
Status and related earlier/later decision IDs:
Change note, author and date:
Leave an unconfirmed owner or date blank instead of promoting a draft into an accepted record. The fictional table supplies a later snapshot relationship, but no real decision authority or actual dates. Your project needs those facts from its maintained records.
If a choice changes, add the new rationale and connect the entries in both directions. Someone reading D01 should discover D02, and someone reading D02 should understand which earlier assumption changed. Do not silently replace the original reason with knowledge the team acquired afterward.
Ask for a log from the evidence you already have
Prepare one complete HTML decision-log review copy.
Project scope and source records: [PASTE]
Actual decisions, reasons, consequences and confirmed dates: [PASTE]
Authorities, statuses and replacement relationships: [PASTE]
Implementation actions and responsible people, if confirmed: [PASTE]
Keep decisions separate from proposals and follow-up actions.
Preserve stable IDs and connect replacing/replaced records.
Mark unavailable facts blank. Do not infer approval, receipt,
completed work or a decision from a discussion alone. Include
a blank entry scaffold and a clearly separated fictional example
only if requested. Use readable print and narrow-screen records,
local CSS, no network, save, approval or notification controls.
Return full HTML and any unresolved record relationships.
The decision matrix compares options before choosing. The RAID log separates risks, assumptions, issues, and dependencies. This log preserves the outcome and the explanation after a choice is recorded. Finish the review by checking the replacement links against the maintained decision records and assigning the resulting work through the team's usual process.