Technical Guides · 2026-08-31
AIMeetingsReviewAutomation

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:

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:

Optional automation boundaries

Automation can help with:

Automation should not:

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