Decisions and action items

Meeting language can look similar while representing different states:

• Idea: “We could add a setup checklist.”
• Proposal: “I recommend adding the checklist this sprint.”
• Intention: “I would like us to add it.”
• Decision: “We approve the checklist for this sprint.”
• Action: “Nora will draft the checklist by Thursday.”

Only the last two change the operational record. A proposal does not become a decision because nobody objected. An intention is not an assignment. Ask AI to classify candidate statements, but verify the classification against explicit language, authority, and context.

When the group uses vague language, the facilitator should close the loop live: “Is that a decision or an option to investigate?” This is more reliable than asking a model to infer the answer afterward.

A useful decision entry contains:

1. Decision: the selected course of action;
2. Decision owner: the person or body with authority;
3. Date and meeting: where it was made;
4. Rationale: the main criteria or evidence;
5. Alternatives: material options rejected or deferred;
6. Conditions: assumptions, limits, or dependencies;
7. Review trigger: when the decision should be revisited;
8. Source: transcript timestamp or approved artifact.

Not every lunch-planning choice needs this detail. Use it for decisions that affect budget, customers, delivery, safety, policy, or multiple teams. The rationale matters because a later team may face changed assumptions. “Use vendor A” is less useful than “Use vendor A for the six-month pilot because it meets residency requirements and stays under the approved £20,000 ceiling.”

Record dissent when it affects risk. Do not rewrite “Security objected because penetration testing is incomplete” as “The team discussed security.” Minority concerns can be essential to later review.

An action item needs at least:

• an observable verb;
• one accountable owner;
• a due date or explicit scheduling rule;
• a deliverable or completion condition;
• dependencies or blockers when material.

“Engineering to investigate performance” is weak. Prefer: “Ishan will compare p95 checkout latency before and after release 4.2 and post the analysis in the project workspace by 16:00 UTC on 9 April.” The action says what to produce, where, and when.

One accountable owner does not mean one worker. A team may contribute, but a named owner closes the loop. Never assign a task to someone merely because the model predicts they are the likely owner. Ownership must be accepted or confirmed through the organization’s normal process.

If the owner or date is missing, preserve the gap:

Owner: unassigned. Due date: not agreed. Follow-up owner: meeting chair by tomorrow.

Visible incompleteness is safer than fabricated precision.

Ask the assistant to extract candidate decisions and actions with evidence:

Return separate lists of candidate decisions, candidate actions, proposals, and unresolved questions. Include exact supporting words and timestamps. For every action, extract owner, due date, deliverable, and dependency. Use missing when a field was not stated. Do not promote suggestions or silence to agreement.

Then review false positives and false negatives. AI may miss an action expressed indirectly—“Could you send that after lunch?”—or treat a rejected option as approved because it appeared repeatedly. It may attach the nearest person’s name to a task that another speaker accepted.

Use deterministic checks after extraction. Flag actions with no owner, no due date, dates in the past, multiple accountable owners, or non-observable verbs such as “consider,” “support,” and “keep in mind.” These checks improve completeness; they cannot determine whether the underlying commitment is real.

Automatically creating tickets, calendar reminders, or customer commitments turns a note error into a side effect. Use a human review gate. Show the proposed record, source passage, destination, and exactly what will happen after approval.

For routine internal meetings, the chair may approve the full action list. For cross-functional or consequential work, ask individual owners to confirm assignments. If a tool sends tasks automatically, keep the permissions narrow and allow cancellation or correction.

Do not send reminders for sensitive tasks through broad channels. A harmless-looking title can reveal a personnel issue, acquisition, security investigation, or health matter.

After publication, records change state:

• a decision may be active, superseded, reversed, or expired;
• an action may be proposed, accepted, in progress, blocked, completed, or canceled.

Do not silently edit the original record when circumstances change. Link the new decision to the one it supersedes. Record who changed an owner or date and why. This prevents an AI-generated weekly summary from presenting an obsolete decision as current.

At the next meeting, review open actions by exception: overdue, blocked, owner changed, or decision assumptions no longer true. AI can prepare that view from trusted systems, but it should not declare completion based only on upbeat conversation. Completion should use the defined evidence.