Extracting Decisions Made From a Set of Meeting Minutes

Ask a model which sentences in a set of minutes record a decision and it will do something reasonable and wrong: it will pick the sentences that sound consequential. The reliable signal is much narrower and much duller. Minute-taking has a small reporting vocabulary, and the verb tells you what was committed to.

Why this is not a judgement call

Minutes are written in a register that has barely moved in a century, because their purpose is evidential. Robert’s Rules of Order, the dominant parliamentary authority in North American practice, is explicit that minutes are a record of what was done, not of what was said; the same principle drives company-secretarial practice elsewhere. That constraint is what makes automated extraction possible: the secretary has already separated action from discussion, and marked the difference with a verb.

So the extraction question is not “is this important?” but “which reporting verb governs this sentence?” That is a question with a checkable answer in the text, which means you can require evidence, audit disagreements, and get consistent results across a hundred meetings from different secretaries. Asking a model for significance gives you none of those things, and it drifts between documents in a way you cannot see.

The reporting verbs and what each commits to

The vocabulary sorts into three tiers, and only the first is a decision.

Decisive

• RESOLVED THAT — the strongest form, usually capitalised, and in company minutes it is the formal resolution whose exact words matter. Extract it verbatim; do not paraphrase a resolution, because the wording is the thing that was passed.
• The Board approved / the Committee agreed — decisive, with a named deciding body. The body matters: a committee agreeing to recommend something is not the board approving it.
• It was agreed that — decisive but passive and unattributed. Common in less formal minutes, and it is the wording that most often has no identifiable owner attached.
• Carried / passed / adopted / defeated — the outcome half of a motion. A defeated motion is still a decision, and it should be in your output with the outcome recorded, not filtered out for being negative.

Not decisive, and deliberately so

• NOTED — a term of art. It means the item was put before the body and the body is not deciding anything about it. Secretaries use it precisely to avoid recording a decision.
• Considered / discussed / reviewed — the record that a thing was before the meeting, with no outcome.
• It was suggested / proposed that — a proposal, not its fate. If the fate is not recorded in the next sentence, nothing was decided.
• Deferred / tabled / adjourned — these deserve their own outcome value rather than being dropped, and tabled is genuinely ambiguous across dialects: in American parliamentary usage it means to set aside, in British usage it usually means to bring forward for discussion. Do not normalise it; record the word.

Directive, which is a different output

“X to do Y by Z” is an action item, not a decision, even though it is just as binding. Keep the two extractions separate and link them by agenda item, because a single item routinely produces one decision and three actions, and the action record needs fields the decision record does not.

Motions, seconds and the vote line

Where a formal motion is minuted, it comes with structure you should capture in full, because it is the most self-checking thing in the document. The canonical shape is a mover, a seconder, the text of the motion, and the result — often with a vote count, sometimes with abstentions and recorded dissent.

What a decision record needs

Everything in the motion — mover, seconder, outcome, counts — gets its own field rather than being folded into the decision text, because each one is separately queryable and separately checkable.

{
  "decisions": [
    {
      "agenda_item": "6.2",
      "decision_type": "resolution",
      "text": "RESOLVED THAT the Company adopt the revised expenses policy with effect from 1 October.",
      "reporting_verb": "RESOLVED",
      "deciding_body": "the Board",
      "moved_by": "T. Boateng",
      "seconded_by": "R. Patel",
      "outcome": "carried",
      "votes_for": 6,
      "votes_against": 1,
      "abstentions": 1,
      "dissent_recorded": ["A. Lindqvist"],
      "evidence": "RESOLVED THAT the Company adopt the revised expenses policy..."
    }
  ]
}

The vote counts give you an arithmetic check that costs nothing: for and against and abstentions should not exceed the number of voting members recorded as present, and where the minutes say “unanimously” the against count should be zero. A total that exceeds the attendance is either a misread digit or an attendance block you extracted incompletely, and either way it is worth stopping for. This is the one place in a set of minutes where the document can contradict itself in a way you can detect mechanically.

Sentences that look like decisions

• A report of somebody else’s decision. “The CEO reported that the Frankfurt office would close in March.” Something was decided; this meeting did not decide it. The reporting verb is reported, and the deciding body is not the one whose minutes you are reading.
• A conditional. “It was agreed that, subject to legal advice, the contract would be signed.” This is a decision with a condition attached, and dropping the condition inverts its meaning. Give the schema a nullable condition_text and require it to be filled whenever the sentence contains “subject to”, “provided that” or “on condition that”.
• A recommendation. A subcommittee recommending something to a board has decided to recommend, not decided the thing. The deciding body field is what stops this collapsing.
• A restatement under matters arising. Last month’s decision, mentioned again. Same carry-forward problem the action extraction has, same fix: an origin field.
• The approval of the previous minutes. Almost every meeting opens by resolving that the previous minutes are a true record. It is a genuine resolution and it is noise in every downstream report, so classify it rather than discarding it — a decision_type of procedural keeps it out of the way without losing it.

A useful discipline for the whole cluster: make the model report the reporting verb as its own field, and audit your run by grouping on that field. If a verb you did not expect is producing decisions, you have found a house style you have not accounted for, and you found it without reading a single document end to end.