build.allanninal.dev

Part 4 of 7 · Meeting notetaker series ~5 min read

How the notes stay grounded

The model wrote a draft — a summary, some decisions, a list of action items. Now the question that matters: can you trust it? A wrong owner on an action item, a date that was never said, a decision that sounds firmer than it was — any of those, in an email everyone reads, is worse than no notes at all. So the draft never goes straight to the recap. Four small checks sit between the model’s output and the recap, and each one’s job is to catch a different way notes can go wrong.

Key takeaways

  • Cite-or-drop: every decision and action item must point to a real transcript line, or it’s removed.
  • Owner resolution: a spoken name is matched to a real person from the roster, or flagged.
  • Date sanity: a fuzzy date (“next Friday”) becomes a real date, or it’s flagged.
  • Needs-confirm queue: anything the checks can’t settle is held for the organizer.
  • Every check is plain code, not another model — predictable, and free.

Four checks on every draft

Four checks between the model's draft and the recap A horizontal flow diagram. On the far left, a "Draft notes" box: the model emitted a summary, decisions, and action items, each carrying the transcript line it claims to come from. Four check gates sit in a row to the right, each drawn as a vertical bar. Gate 1: Cite-or-drop — for every decision and action item, confirm the cited transcript line actually exists and actually supports the claim; if it doesn't, the item is dropped, not kept. Gate 2: Resolve owner — match the spoken name on each action item to a real person in the roster; if there's one clear match, attach their email; if there are zero or several, mark the owner needs-confirm. Gate 3: Date sanity — turn a fuzzy spoken date like next Friday or end of month into a real calendar date relative to the meeting date; if the date can't be pinned down, mark it needs-confirm. Gate 4: Final assemble — combine the kept summary, decisions, and action items into the draft recap, with every needs-confirm item collected into its own section for the organizer. After all four gates, the assembled draft goes to the recap step for the organizer to confirm. A note at the bottom: every check is plain code, not another model — nothing the transcript didn't support survives to the recap. Draft notes summary, decisions, action items Check 1 Cite or drop cited line really exists? really supports? if not, drop the item Check 2 Resolve owner match name to roster? zero or many, mark needs- confirm Check 3 Date sanity fuzzy date to a real date? if unclear, mark needs- confirm Check 4 Assemble the draft kept summary + decisions + actions, needs-confirm in its section Draft recap — goes to the organizer to confirm before anyone else sees it summary · decisions · action items · needs-confirm section every kept item still carries the transcript line and timestamp behind it Every check is plain code, not another model — nothing the transcript didn’t support survives.
Fig 4. Four checks between the model’s draft and the recap. Confirm every citation. Resolve every owner. Pin down every date. Assemble what survives, with the unsure items collected for the organizer. Then on to the recap step.

Check 1: cite-or-drop

In Part 3 the model was told to attach the transcript line behind every decision and action item. This check holds it to that. For each item, the code looks up the cited line in the saved transcript and confirms two things: that the line actually exists (the model didn’t invent a quote), and that the line plausibly supports the claim (the words line up). If an item cites a line that isn’t there, or cites a line that doesn’t say what the item claims, the item is dropped — not kept, not guessed at. Better to miss one real action item the organizer can add by hand than to ship one the meeting never produced.

This is the single most important check, because it’s the one that catches a model that’s drifted into making things up. Everything that survives this gate is anchored to a real moment in the recording.

Check 2: resolve the owner

An action item with no owner is a wish. So each action item carries a spoken name — “Maria,” “Sam,” “the design team” — and this check tries to turn that into a real person. It compares the spoken name against the roster (name, email, and the nicknames each person goes by). One clear match: attach that person’s email and move on. Zero matches, or several plausible ones (two people named Sam): the owner is marked needs-confirm and left for the organizer.

The roster is deliberately the only source for owners. The check never invents an email address or assigns an item to whoever was loudest. If the meeting genuinely didn’t name an owner, the right answer is “a human decides,” not a guess.

Check 3: date sanity

People say dates loosely. “By next Friday,” “end of the month,” “before the launch,” “in a couple of weeks.” This check turns the ones it can into real calendar dates, measured from the meeting date — “next Friday” in a meeting on the 22nd becomes a specific date. The conversions are plain rules, not a model: a small table maps common phrases to offsets. Anything the rules can’t pin down — “before the launch” when no launch date was set, “soon,” “sometime” — is marked needs-confirm with the original phrase shown, so the organizer can set a real date.

The reason for being strict here is the same as everywhere else: a confidently wrong date is more dangerous than an obviously missing one. “Due: needs-confirm” prompts a fix; “Due: May 29” when nobody said May 29 quietly becomes a deadline somebody trusts.

Check 4: assemble, with the unsure items collected

The last step builds the draft recap from what survived: the summary, the kept decisions, and the action items that have a real owner and a real date. Everything that got marked needs-confirm along the way — a dropped citation worth a second look, an unresolved owner, an unpinned date — is gathered into its own section at the top of the draft, so the organizer sees exactly what needs a human before anything else. Every kept item still carries its transcript line and timestamp, so the organizer can check any of them in one read.

None of these four checks call a model. They’re plain Python: look up a line, match a name against a list, convert a date phrase, sort items into buckets. That’s on purpose. The model’s job is to read the meeting; the checks’ job is to be utterly predictable about what’s allowed through. A predictable gate you can reason about beats a smarter gate you can’t.

Why grounding is the whole point

The reason people don’t trust automatic meeting notes is that they’ve all seen the bad version: a confident recap with an action item nobody remembers agreeing to, assigned to somebody who wasn’t even there. One bad recap and the team stops reading them. These four checks exist so that every line in the recap can be traced back to the recording, and so that the things the system isn’t sure about are shown as questions, not stated as facts. The notetaker would rather hand the organizer three clean items and two questions than five items where one is quietly wrong.

Next post: how the recap reaches everyone — how the organizer confirms the draft, fixes the needs-confirm items, and sends the clean version to the whole room.

All posts