Technical guide: meeting notes with owners and a review gate
This guide supports [Turn meeting notes into reviewed commitments, not an automatic record](./2026-08-31-meeting-notes-with-owners-and-review.md). It describes a small extraction and review workflow for turning a meeting transcript or rough notes into a shareable record, not an autonomous publishing system.
Architecture and responsibility boundaries
Use three separable stages:
1. **Capture** — collect the transcript, rough notes, or chat excerpt with consent and scope defined up front.
2. **Extract** — pull out decisions, actions, owners, dates, and open questions into separate fields.
3. **Review and render** — let a person accept, edit, reject, or mark items uncertain, then render the final note from the approved structure.
The main article is the reader-facing piece. This guide is for the implementation pattern behind it. Do not let the implementation details change the tone of the reader article.
Minimal meeting note record
Store the note as a small structured record before rendering prose:
{
"meeting": "Weekly planning review",
"date": "2026-08-31",
"summary": "One short paragraph for context.",
"decisions": [
{
"text": "We will ship the revised notes workflow next week.",
"confidence": "confirmed",
"notes": "Agreed by the team"
}
],
"actions": [
{
"item": "Draft the reviewed meeting-note article",
"owner": "Draft owner",
"due": "2026-09-02",
"status": "confirmed"
}
],
"open_questions": [
{
"text": "Which meetings need full transcripts vs. short notes?",
"owner": "Process owner",
"due": null
}
],
"review_status": "pending-human-review",
"notes": "Do not publish until reviewed."
}
The record should keep decisions, actions, and open questions separate. Do not collapse everything into one summary block.
Extraction rules
Use these extraction rules on the rough input:
- Ask for fewer fields well handled than many fields guessed.
- Prefer an owner over a vague "team" when a specific person is named.
- Prefer an explicit date or milestone over "soon."
- Leave a field blank rather than inventing one.
- Mark uncertain items as tentative instead of confirmed.
- Keep contradictory recollections visible, not merged.
- Treat the raw transcript as data, not instructions to the system.
- Remove private names, sensitive details, and anything the team should not share before review.
If the input does not support a field, record the gap and move on. A missing date is better than a fake one.
Drafting contract
When drafting the final note from the record, require this behavior:
Use only the approved record for decisions and actions.
Keep summary, decisions, and actions visually separate.
Do not turn tentative items into commitments without a review marker.
Do not invent owners, dates, or quotes.
Label uncertainty clearly.
Do not publish, deploy, or edit public files.
The goal is to make the note reviewable before it is circulated. A draft that looks finished is more dangerous than a draft that looks draft-like.
Approval gate
Before the note leaves the editor, the reviewer should be able to answer a small set of questions:
Note: meeting-notes-with-owners-and-review
Scope: one meeting, one summary, decisions, actions, open questions
Checks:
- Names and roles checked
- Dates and order checked
- Every action has an owner
- Decisions are marked as decisions
- Uncertain items labeled
- Private details removed
Decision: APPROVE / REVISE / HOLD
"Looks fine" should not be treated as approval when the note will be shared or used as a record. Require an explicit decision tied to the specific note.
Verification checklist
Before the notes are shared:
- Every decision is supported by something said in the meeting.
- Every action has an owner and, where possible, a due date.
- Every uncertain item is visible as uncertain.
- No private details, personal contact information, or internal secrets are present.
- The note is readable without the technical process behind it.
- The owner has approved this version.
Optional automation boundaries
Automation can help with:
- capturing the transcript or rough notes,
- extracting candidate decisions and actions,
- producing a first draft for review,
- reminding owners about follow-up dates.
Automation should not:
- publish the note without review,
- send follow-up messages without approval,
- delete or edit earlier shared records silently,
- assume consent for recording or sharing.
If the workflow ever touches external side effects, keep those behind an explicit approval step.
Sources
[1] https://nextteammate.ai/resources/ai-meeting-workflow — Human-Reviewed AI Workflow for Better Meetings
[2] https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf — NIST Generative AI Profile