Tracking decisions, commitments, and risks after meetings

Ask a leadership team what last month's operations meeting decided and you will usually get three different answers and one person scrolling a notes doc. The meeting worked; the memory of the meeting failed. What decays is not the summary — it is the three specific outputs that were supposed to outlive the call: what was decided, what was promised, and what could still go wrong.

Three objects, three lifecycles

The reason a single notes document fails is that these outputs age differently:

• A decision is an event. Once made, the questions are only "does it still stand?" and "where is the wording?". Its lifecycle is logged → confirmed (or revisited, when circumstances change — which is legitimate, as long as revisiting is explicit rather than by amnesia).
• A commitment is a promise with a person and usually a date. Its lifecycle is open → kept or open → missed, and the honest version records "missed" instead of silently extending. A commitment that can never be marked missed is not being tracked; it is being decorated.
• A risk is a condition, not an event. It stays open until someone either mitigates it or consciously accepts it. Risks are the output most often lost, because they are nobody's promise and everybody's problem.

Give each type its own lane with its own small status vocabulary. The moment all three live in one "notes" blob, the statuses disappear and everything regresses to prose.

Provenance is the whole game

Every tracked outcome should carry a pointer to the meeting that produced it. This is not bureaucratic tidiness — it is what settles the inevitable dispute. When two directors remember a decision differently, the resolution is not whoever speaks last; it is the sentence in the transcript. An outcome without a source is just an opinion with a timestamp.

The provenance rule also protects privacy: whoever can see the meeting can see its outcomes, and someone who could not see the meeting should not learn its contents through a status board side door.

Review the deltas, not the lists

The failure mode of outcome tracking is the fifty-row spreadsheet nobody reads. The fix is to stop reviewing lists and start reviewing changes. A useful weekly operating review asks exactly three questions:

1. Which commitments changed state? Kept ones get closed with credit; missed ones get a conversation, not a quiet date edit.
2. Which risks moved? A risk that was mitigated is a win worth naming. A risk unchanged for a month is either mis-stated or being ignored.
3. Which decisions are being relitigated in hallways? If a decision keeps reopening informally, put it back on the agenda formally and either confirm it or revisit it once, in the open.

This takes ten minutes when the objects have statuses, and two hours when they live in prose.

Anti-patterns worth naming

• The mega-document. One running doc per team, appended forever. Searchable in theory, reviewed never.
• Assigning risks like tasks. "Owner: Miguel" on a risk usually means Miguel gets blamed, not that the risk gets mitigated. Risks need a decision (mitigate or accept), and decisions need the group.
• Extraction without curation. Automated extraction is a starting point. If nobody prunes duplicates and confirms wording in the first day, the board becomes noise with provenance.

Where DayMarshal fits — honestly

DayMarshal promotes every analyzed meeting's decisions, commitments, and risks into exactly this structure: three tracked lanes with per-type statuses (confirmed/revisited, kept/missed, mitigated/accepted), every item linked to its source meeting, every status change logged with who and when. Visibility follows the meeting itself — share the meeting and its outcomes appear to the team; a private 1:1's outcomes stay private. What stays yours is the review: the tool remembers, but only the room can decide.