# AI Meeting Notes to Action Items: Validation-First Workflow

> Build an AI meeting notes workflow that turns explicit commitments into reviewed tasks without treating suggestions or invented details as facts.
> Author: Roman Belov · Published: 2026-08-14 · Source: https://futurecraft.pro/blog/meeting-notes-actions/

A meeting transcript usually contains three different kinds of language:

- “I will publish the checklist by Wednesday.”
- “We could redesign the import screen next week.”
- “Someone should look at the failed imports.”

Only the first sentence is a complete commitment. A weak meeting-notes prompt can
turn all three into tasks, invent an owner for the third, and quietly choose a date
for the second. The resulting tracker looks organized, but it no longer represents
what the team agreed.

A safer workflow does not ask an LLM to “summarize and create tasks.” It separates
transcription, extraction, validation, approval, and task creation. Each stage has a
small contract and a visible failure mode.

## The workflow in one diagram

![A synthetic meeting transcript produces eight candidates; validation accepts two and rejects six with explicit reason codes](/artifacts/meeting-action-validation/meeting-action-validation-2026-08-27.svg)

The diagram comes from a [downloadable TypeScript fixture](/artifacts/meeting-action-validation/).
It uses a synthetic transcript and performs no external API calls. Twenty tests cover
the evidence gates, malformed inputs, stored JSON, generated SVG, and license files.

The production shape is:

```text
recording
  → timestamped transcript
  → candidate decisions and actions
  → deterministic validation
  → human review
  → task tracker and notifications
```

Do not collapse the review and write steps. That boundary is what prevents a plausible
model output from becoming an unauthorized external action.

## Define the contracts before choosing tools

The vendor is replaceable. The data contracts are not. Define them first.

| Stage | Required input | Output | Failure that must stay visible |
|---|---|---|---|
| Capture | recording permission, meeting ID | audio or video reference | missing consent or recording |
| Transcribe | recording | timestamped speaker segments | low-confidence or missing audio |
| Extract | transcript segments | action candidates with quotes | malformed or incomplete output |
| Validate | candidates, transcript, participant list | accepted and rejected candidates | reason code for every rejection |
| Review | evidence-linked candidates | approved, edited, or rejected items | reviewer and decision timestamp |
| Write | approved items | task IDs and notification IDs | API error or duplicate attempt |

An action candidate should contain at least:

```json
{
  "id": "candidate-02",
  "title": "Export the failed-import sample",
  "owner": "Jon",
  "dueDate": "2026-09-03",
  "commitmentStatus": "accepted",
  "evidenceQuote": "I will export the failed-import sample by 2026-09-03",
  "sourceSegmentId": "segment-02"
}
```

The quote is not decoration. It is the shortest path from a proposed task back to the
record that supposedly supports it.

## Stage 0: permission, retention, and access

Meeting audio and transcripts can contain names, customer details, commercial terms,
health information, or credentials spoken aloud. Decide how the recording is handled
before adding transcription or an LLM.

At minimum:

1. Tell participants when recording or automated notes are active.
2. Document the purpose and applicable legal basis for processing.
3. Set retention periods for the recording, transcript, model input, and review log.
4. Restrict access to the people and services that need it.
5. Redact secrets and unnecessary personal data before model processing.
6. Provide a way to correct the record and remove an incorrectly attributed action.

The exact legal requirements depend on jurisdiction and context. This is an engineering
checklist, not legal advice. For sensitive meetings, involve the person responsible for
privacy or compliance before recording begins.

## Stage 1: produce evidence-friendly transcript segments

A plain text transcript is difficult to audit. Keep stable segment IDs, timestamps, and
speaker labels:

```json
{
  "id": "segment-02",
  "speaker": "speaker-1",
  "startMs": 7100,
  "endMs": 13900,
  "text": "I will export the failed-import sample by 2026-09-03."
}
```

[OpenAI’s Whisper model card](https://github.com/openai/whisper/blob/main/model-card.md)
describes speech recognition and translation capabilities, but also says performance
varies by language and recommends evaluation in the intended domain. It does not give
you a verified mapping from voices to people. If speaker attribution matters, test it
separately.

Some transcription services return diarization labels. For example,
[Deepgram’s diarization documentation](https://developers.deepgram.com/docs/diarization)
describes word-level `speaker` labels and distinguishes batch and streaming behavior.
Those labels still mean “speaker 0” and “speaker 1,” not “Maya” and “Jon.” Map labels to
known participants through explicit introductions, meeting metadata, or human review.

Preserve the raw segment output. If a reviewer disputes a task later, the system needs
the original words and timestamps, not only a polished summary.

## Stage 2: ask for candidates, not final tasks

The extraction step should produce proposals for review. A useful instruction set is:

```text
Extract only explicit decisions and commitments.
Do not infer an owner or deadline.
Classify proposals and unclear statements separately.
Copy a short supporting quote exactly from one source segment.
Return structured data that matches the supplied schema.
If a field is absent, leave it empty rather than guessing.
```

Structured output reduces parsing failures, but schema compliance does not prove that
the content is true. A model can return perfect JSON with an invented quote. Treat the
schema as the beginning of validation, not the end.

For long meetings, process overlapping groups of segments and retain their IDs. Merge
candidates only after extraction. Do not summarize each chunk first: repeated
summarization removes the wording needed to distinguish “I will” from “we might.”

## Stage 3: validate every candidate against the record

The accompanying fixture applies five gates:

1. **Evidence:** the normalized quote occurs in the transcript.
2. **Source:** the quote occurs in the declared segment, not somewhere else.
3. **Owner:** the owner matches a known participant.
4. **Deadline and status:** the date is real and the statement is an accepted commitment.
5. **Deduplication:** equivalent title, owner, and date combinations appear once.

The reviewed synthetic run supplied eight candidates. Two passed. Six were rejected:

| Candidate problem | Reason code |
|---|---|
| suggestion presented as a commitment | `not_explicit_commitment` |
| quote absent from the transcript | `evidence_not_found` |
| owner absent from participant list | `owner_unknown` |
| impossible calendar date | `deadline_invalid` |
| repeated action | `duplicate` |
| real quote attached to the wrong segment | `source_segment_mismatch` |

You can inspect the
[manifest, source, tests, and exact rerun commands](/artifacts/meeting-action-validation/).
The code is MIT-licensed; the checklist and generated evidence are CC BY 4.0.

This fixture proves the validator’s behavior on supplied synthetic input. It does not
measure speech recognition accuracy, extraction recall, or model precision. Those need
a representative, human-labeled evaluation set from your own meeting types.

## Stage 4: make review fast enough to be used

A review screen should show one candidate at a time with:

- the proposed title, owner, and due date;
- the source quote and nearby transcript context;
- an audio link positioned at the source timestamp, when policy allows it;
- validation warnings;
- approve, edit, reject, and “not a commitment” actions.

Record the reviewer, decision, timestamp, and edits. Corrections are not just audit
data; they become examples for evaluating the next extractor version.

Do not force every candidate into a task. Decisions can become decision-log entries.
Open questions can become agenda items. Suggestions can remain suggestions. A single
“task” schema is the wrong destination for all meeting language.

For a wider discussion of approval boundaries, see
[human-in-the-loop patterns for AI agents](/blog/human-in-the-loop/).

## Stage 5: create tasks as a separate side effect

Only approved items should reach the tracker. The writer needs:

- a least-privilege service identity;
- server-side credentials loaded from environment or a secret store;
- an idempotency key such as `meetingId + candidateId + destination`;
- a durable mapping from that key to the created task ID;
- retries that check the mapping before writing again;
- an error queue instead of silent failure.

Linear exposes a GraphQL API and explicitly advises clients to inspect the GraphQL
`errors` array even when the HTTP response is 200. Check the current
[Linear API documentation](https://linear.app/developers/graphql) rather than copying a
mutation from an old blog post.

For notifications, Slack’s
[`chat.postMessage` documentation](https://api.slack.com/methods/chat.postMessage)
requires a destination and appropriate scopes. If you use Block Kit, include useful
top-level text for notifications and screen readers. Post the task link and the source
meeting reference; do not repost the entire transcript into a broad channel.

The model should never receive a tracker token or decide which credential scope to use.
Keep tool authorization in application code. OWASP describes unchecked model output as
[improper output handling](https://genai.owasp.org/llmrisk/llm052025-improper-output-handling/)
and recommends human approval and least privilege when an LLM can trigger consequential
actions in its guidance on
[excessive agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/).

## Measure the pipeline without inventing a success story

Start with operational measurements, not a promised percentage improvement:

- **candidate acceptance rate:** approved without edits divided by reviewed candidates;
- **correction rate:** candidates whose owner, date, or wording changed in review;
- **unsupported-candidate rate:** rejected for missing evidence or wrong segment;
- **duplicate prevention count:** valid duplicates stopped before task creation;
- **write failure rate:** approved items not written successfully;
- **review latency:** time from transcript completion to review decision;
- **action correction rate:** created tasks later corrected because the meeting record was wrong.

Segment these metrics by meeting type, language, transcription configuration, and
extractor version. A sales call, engineering incident, and weekly planning meeting do
not have the same vocabulary or risk.

Build a labeled evaluation set from meetings you are allowed to use. Include explicit
commitments, rejected proposals, sarcasm, interruptions, name ambiguity, missing dates,
and multilingual speech. Keep the set versioned and separate from prompts used in
production. If the system changes, rerun the same evaluation before rollout.

## A practical rollout order

1. **Review-only.** Generate candidates and compare them with manual notes.
2. **Evidence validation.** Require quotes, source segments, owners, and dates.
3. **Shadow writes.** Produce the payload but do not call the tracker API.
4. **Limited write access.** Let one team approve tasks into one project.
5. **Broader rollout.** Expand only after correction and failure rates are understood.

If reviewers routinely ignore the queue, do not bypass them. Reduce candidate volume,
improve evidence display, or narrow the workflow to explicit commitments. An unused
approval step is a product problem, not permission to remove the safety boundary.

## What this workflow does not solve

- A transcript can mishear names, numbers, or dates.
- Diarization can confuse speakers.
- A spoken commitment may still be inappropriate or unauthorized.
- A valid quote can lack the context that changes its meaning.
- Human reviewers can approve the wrong item.
- A task tracker cannot guarantee that work will be completed.

The goal is not perfect automated meeting memory. It is a traceable path from spoken
words to a proposed action, with enough evidence and control for a person to decide
whether the task should exist.