Recurring meetings create a familiar failure mode: the same promise appears every week, but nobody can tell whether it is the original commitment, a revised version, or a new task. A note says “send the draft Friday.” The next says “move it to Tuesday.” A third says “done,” without linking the completed work. The words changed, but the record did not preserve the change.
A commitment ledger gives every promise a stable identity and a visible history. It does not replace a task manager. It provides the evidence trail that connects what was said in one permitted meeting to what the team confirmed, changed, corrected, or closed later.
Action items are the starting point, not the full record
Atlassian’s action-item guidance emphasizes a clear task, an owner, and a target date, with a status check before the deadline. Those fields make an individual action useful. Recurring meetings add another requirement: the team must be able to distinguish a continuing commitment from a newly created one.
The GOV.UK Service Manual explains that agile plans change as teams learn and recommends making planning visible. A commitment ledger applies the same principle at a smaller scale: keep the current state visible, but preserve the earlier state that explains how it changed.
Give every commitment a stable ID
Create an ID when the commitment is first accepted, such as COM-024. Reuse that ID in every later meeting. Do not create COM-025 merely because the due date moved or the wording became more precise.
A useful ledger row contains:
- stable commitment ID;
- current commitment wording;
- named owner;
- current due date or review date;
- status and status evidence;
- source meeting and note location;
- change or correction history;
- closure evidence and closure date.
If the first meeting produced an unstructured list, use the action-item workflow to clarify the task before adding it to the ledger.
Use lifecycle states that mean one thing
| Status | Meaning | Minimum evidence |
|---|---|---|
| Proposed | A possible commitment was mentioned but not accepted. | Source note plus person who must confirm. |
| Open | The owner accepted the commitment. | Accepted wording, owner, and checkpoint. |
| In progress | Work started, but the completion condition is not met. | Specific progress update and source. |
| Changed | Scope, owner, or date changed. | Old value, new value, reason, and confirmer. |
| Blocked | A named dependency prevents progress. | Blocker, resolution owner, and next check. |
| Closed | The agreed completion condition was verified. | Output or confirmation linked to the row. |
A status word without evidence is only a label. “Done” should not close a row if the meeting agreed that another person must review the output first.
A fictional three-meeting example
The following example is fictional and exists only to show the continuity method.
| Meeting | Source note | Ledger update |
|---|---|---|
| Week 1 | “Lena will send the onboarding draft by Friday.” | COM-024 opened. Owner: Lena. Due: Friday. Completion: draft shared with the review group. |
| Week 2 | “Move the draft to Tuesday because the screenshots changed.” | COM-024 changed. Old due date retained. New due date: Tuesday. Reason and source added. |
| Week 3 | “Draft sent. Omar reviewed it and left two comments.” | COM-024 closed only after the linked draft and review confirmation were checked. |
The ID stayed the same because the underlying promise stayed the same. The ledger preserved the date change instead of rewriting Week 1 as if Tuesday had always been the plan.
Record changes without erasing the original
When a commitment changes, add a dated change event. Keep the previous owner, scope, or due date in history. This prevents later readers from blaming a person for missing a deadline that the team had formally moved.
If a previous note was factually wrong, mark it as a correction rather than an ordinary plan change. A correction says the earlier record misrepresented what happened; a change says the plan genuinely moved. The workflow for correcting shared meeting notes without erasing history explains how to preserve that distinction.
Define closure before the deadline
“Send the draft” can mean uploading a file, emailing a link, or obtaining approval. Write the completion condition when the row opens. Then closing the row becomes a check against evidence, not a debate about interpretation.
Useful closure evidence might include a permitted document link, an approval message, a delivered file, a recorded decision, or a confirmed handoff. Store only what the team is allowed to retain and share.
Copy-ready commitment ledger
| ID | Current commitment | Owner | Checkpoint | Status | Evidence | Source | Last change | Next review |
|---|---|---|---|---|---|---|---|---|
| COM-[number] | [observable output] | [accepted owner] | [date or condition] | [state] | [link or confirmation] | [meeting + section] | [old → new + reason] | [date + person] |
A five-minute recurring-meeting routine
- Filter the ledger to open, changed, and blocked commitments.
- Read the stable ID before discussing each item.
- Capture new evidence, not just a status word.
- Record any scope, owner, or date change as a separate event.
- Close only when the agreed completion condition is verified.
- Create a new ID only for genuinely new work.
Try it now: choose one permitted recurring-meeting note, create a stable commitment ID, and carry that same row through the next three meetings without rewriting its history.
