Write a PRD

PRD: AI-Generated Meeting Summaries with Decisions and Action Items

Audience: Engineering and Design leads Status: Ready for build planning Owner: Product

1. Summary

Huddle records and transcribes meetings with speaker labels, and the attendee list comes from the calendar invite. Today, people write their own notes after calls, and those notes are often late, incomplete, or missing. This feature generates a summary after each meeting that lists the decisions made and assigns action items to attendees. Action items are emailed to their owners, with Sales' requirement for immediate delivery balanced against the accuracy limits described in Section 4.

2. Goals and Non-Goals

Goals - Produce a summary within 5 minutes of meeting end for 95% of meetings. - Every action item names an owner who was present in the meeting. - Every decision and action item links to the transcript moment that supports it. - Give Sales automatic, immediate delivery for high-confidence action items.

Non-Goals (v1) - Calendar write-back or task creation in external tools (Jira, Asana). Design for it, but do not build it. - Summaries for meetings without a transcript. - Sentiment, coaching, or participation analytics.

3. Definitions

• Attendee: A person present in the meeting, determined by the participant session log (the platform's record of who joined), not only by the calendar invite. The calendar invite is a hint, not proof of attendance.
• Identified participant: A participant tied to a Huddle account or a verified email address.
• Unidentified participant: A guest who joined by name only, with no verified identity.
• Action item: A task with an owner, a description, and optionally a due date, derived from transcript content.
• Decision: A statement that the group agreed on a course of action, with supporting transcript evidence.

4. Known Limits and Design Responses

5. Functional Requirements

FR-1: Roster resolution Build the attendee roster from the participant session log at meeting end. Merge in calendar invitees for context, but do not treat invitees who never joined as attendees. Each roster entry is tagged as identified or unidentified.

FR-2: Summary generation Produce a summary containing: - A 3–5 sentence overview. - A decisions list. Each decision has a one-sentence statement, a timestamp, and a transcript link. Decisions are not assigned to individuals unless the transcript clearly states who made them. - An action items list (FR-3).

FR-3: Action item extraction Each action item includes: description, owner (a roster member), due date if stated, timestamp, transcript link, and attribution confidence (high, medium, low).

FR-4: Hard constraint: no non-attendee owners (must-pass) Before any summary is stored or sent, a deterministic validator checks that every action item owner matches a roster entry from FR-1. If an owner does not match, the item is removed and logged as a pipeline error. This check does not depend on the model or on confidence scores. The model is never the final authority on membership.

FR-5: Unidentified owners If the model attributes an action to an unidentified participant, the item is kept, but the owner is shown as "Unidentified participant (Name as joined)." These items are never emailed. They appear in the organizer's review view only.

FR-6: Confidence gating for delivery Each action item is sent automatically only if all of the following are true: - Owner is an identified roster member. - Attribution confidence is high. - The supporting transcript segment has no overlapping speech flag. - The item's source is not a multi-person room device.

Items that fail any check go to the organizer's review queue. The organizer can confirm, reassign to another roster member, or dismiss. Confirmed items are then sent.

FR-7: Multi-person sources When an action item comes from a multi-person source, the owner field is set to "Confirm owner" and the item is held for review. The review UI lets the organizer or the item's likely owner claim it from the roster.

FR-8: Delivery - Auto-sent items go to the owner's email within 5 minutes of meeting end. - Emails contain: the meeting name, the action item, the due date if any, a link to the summary, and a link to the transcript moment. - Each meeting produces one email per owner, grouping that owner's items. - Emails go only to identified roster members. Admins can disable delivery to external email domains.

FR-9: Review queue Organizers see a summary page with held items, can edit or confirm them, and can see which items were auto-sent. Edits made after sending generate a correction email to the owner.

FR-10: Controls and privacy - Admins can turn summaries on or off per workspace and per meeting type. - Any participant can opt out of their own speech being summarized. Their items are excluded from the summary and their name is removed from the roster. - Summaries and transcripts follow the same retention and access rules as the source recording.

6. Sales Requirement: Immediate Auto-Send

Sales wants action items emailed as soon as the meeting ends. This PRD supports that for high-confidence items (FR-6, FR-8). It does not send low-confidence items immediately, because a wrong owner gets a task they didn't agree to, and an email that is later corrected erodes trust. Sales can see the auto-send rate in the admin dashboard. If the held rate is too high for their workflows, the threshold can be tuned with data from the pilot. It should not be lowered without evaluation.

7. Acceptance Criteria

• AC-1: Across a 300-meeting eval set, zero action items name an owner absent from the participant log. This is a hard gate for launch.
• AC-2: Every decision and action item has a working transcript link that lands within 10 seconds of the cited statement.
• AC-3: For a labeled eval set, owner precision on auto-sent items is at least 97%.
• AC-4: Summaries are generated within 5 minutes of meeting end for 95% of meetings with transcripts under 90 minutes.
• AC-5: An uninvited identified joiner appears in the roster and can receive items. An unidentified joiner never receives email.
• AC-6: Opt-out removes the participant's items and name from the output within one processing cycle.

8. Metrics

• Adoption: Percentage of eligible meetings with a summary delivered.
• Quality: Action items edited or reassigned by the organizer, by confidence band.
• Trust: Post-send corrections per 100 auto-sent items. Target: under 2.
• Usage: Percentage of owners who open the linked transcript from an email.

9. Open Questions

1. Should the review queue notify the organizer by email, Slack, or in-app only?
2. When an owner is an external email address, what is the policy under the admin domain setting?
3. How will we handle meetings where the transcript contains no clear owner for a decision or action?
4. Do we need a per-workspace setting to require organizer approval for all items?
5. Should multi-person room devices be fixed at the hardware or SDK level, which would change FR-7?

10. Phasing

• Phase 1 (pilot, 20 workspaces): FR-1 through FR-5, FR-8 through FR-10, with all items held for organizer review. This validates the constraint and attribution quality.
• Phase 2: Enable confidence gating (FR-6) and auto-send for Sales and other pilot workspaces, based on Phase 1 precision data.
• Phase 3: Multi-person source handling at scale (FR-7), and general availability.

PRD: AI Meeting Summaries — Decisions & Action Items

Sep 24, 2026 · @Martin Slaney

Summary

We will generate a summary after every recorded Huddle meeting that lists the decisions made and the action items, each with an owner who was verifiably in the meeting. The organizer reviews the summary and sends it in one click; nothing is emailed without that step in v1.

Problem. Today attendees write their own notes after the call. Notes are inconsistent, often missing, and action items lose their owners within a day. We already have what we need to fix this: a recording, a transcript with speaker labels, and the calendar attendee list.

Why this is not trivial. Two of those inputs are unreliable. Speaker labels are wrong about 8% of the time, mostly during crosstalk and when several people share a meeting-room device. About 15% of meetings include someone who joined without a calendar invite. A naive build would misassign owners often enough to lose trust in the first week.

Goals and metrics

The goal is summaries people send without rewriting, with zero actions assigned to non-attendees.

Goals

• Replace manual post-meeting notes for recorded meetings.
• Every action item has a correct owner or is explicitly marked unassigned.
• Get action items to owners within minutes of the meeting ending.

Non-goals (v1)

• Pushing tasks into Jira, Asana or Linear.
• Summaries for unrecorded meetings or live, in-call summaries.
• Improving diarization itself. We design around the 8% error rate, not fix it.

Success metrics

Owner precision is measured from organizer edits plus a weekly labelled sample of 200 meetings.

Users and core flow

The organizer owns the summary; attendees receive it.

• Organizer: reviews, fixes owners, sends. Usually the calendar invite's creator; can hand off to any attendee.
• Action owner: receives their items by email and in the app.
• Other attendees: receive the full summary once sent.

```mermaid flowchart LR A[Meeting ends] --> B[Transcript +<br/>join log ready] B --> C[Build verified<br/>roster] C --> D[Extract decisions<br/>and actions] D --> E[Roster filter +<br/>confidence check] E --> F[Organizer review] F --> G[Send to owners<br/>and attendees] ```

The roster filter runs as deterministic code after the model, never inside the prompt alone.² Target: summary ready for review within 5 minutes of meeting end for meetings up to 90 minutes.

Requirements

An owner can only be chosen from the verified roster: people who actually joined, not people who were invited.

Verified roster

1. R1. Build the roster from the join log, not the calendar invite.¹ Invited people who never joined are excluded. 2. R2. Each roster entry has an identity tier: - Verified: joined signed in to a Huddle account, or by a dial-in matched to a known number. - Guest: joined with a display name only (most of the 15% uninvited joiners). - Room: a meeting-room device; people behind it are unknown individuals. 3. R3. Match uninvited joiners to workspace accounts by signed-in account only. Never match on display name alone.

Summary content

1. R4. Decisions: a short statement of each decision, with a transcript timestamp link. No owner field.
2. R5. Action items: task, owner (or "Unassigned"), due date if said aloud, timestamp link, and confidence.
3. R6. Every item links to its evidence in the transcript so reviewers can check it in one click.

Assignment rules

1. R7. The model returns a proposed owner per item. Code then checks it against the roster. Any owner not on the roster is replaced with "Unassigned", and the named person is shown as a mention ("mentions: Dave, not in meeting").
2. R8. Owner comes from content first: a named request ("Priya, can you…") beats the speaker label of "I'll do it".
3. R9. Mark an owner low confidence when the evidence depends on a speaker label in an overlapping segment, a Room entry, or a Guest entry.
4. R10. Low-confidence items show as "Suggested: Priya" and need organizer confirmation before any email goes out.
5. R11. Room and Guest entries cannot receive email. The organizer can reassign to a verified person or leave it unassigned.
6. R12. Log every model proposal, filter result and organizer edit. This is our precision measurement.

Handling the known limits

Both limits hit ownership, not decisions, so we contain them at the owner step.

The error compounds per meeting. If each item's owner is wrong 8% of the time, a meeting with 5 action items has a 34% chance of at least one wrong owner (1 − 0.92⁵). That is why confirmation sits before email, not after.

Sales request: auto-email on meeting end

Decision: not in v1 as requested. We ship one-click organizer send now, and gated auto-send in phase 2 once measured precision earns it.

Why not now. An email to the wrong owner is the most visible failure this feature can have. With the error rate above, roughly a third of 5-item meetings would email someone a task that isn't theirs. With external guests, it may land outside the customer's company. Early trust is hard to win back.

What Sales gets instead.

• v1: the organizer gets a "Summary ready" notification within 5 minutes and sends with one click. Goal: sent within 30 minutes (see metrics).
• Phase 2: a workspace setting to auto-send at meeting end, but only items that are high confidence and owned by a Verified attendee. Everything else still waits for the organizer. It ships only when owner precision on high-confidence items is ≥ 97% for 4 consecutive weeks.
• Auto-send never emails Guest or Room entries, or anyone outside the customer's domain, unless an admin enables it.

Design notes

The review screen must make checking owners faster than writing notes.

• Decisions first, then action items grouped by owner, then Unassigned.
• Low-confidence owners look visibly different ("Suggested") and are editable inline from a roster picker, never free text.
• Each item plays its transcript clip on click.
• The Send button states who gets email: "Send to 4 owners and 7 attendees".
• Empty state: if no decisions or actions are found, say so plainly rather than inventing any.

Rollout

Open questions

• [ ] Is the join log's signed-in identity reliable enough to call "Verified"? Engineering to confirm.
• [ ] Who organizes when the invite creator didn't attend? Proposed: first Verified attendee from the invite.
• [ ] Do customers need to disable summaries per meeting for sensitive calls? Legal and Sales to confirm.
• [ ] Retention: how long do we keep drafts and the evidence log?

Huddle AI meeting summaries

Product requirements for engineering and design leads

Purpose and product decision

Huddle will generate a reviewable record of meeting decisions and actions from its transcripts. The host checks the draft, resolves ownership and publishes it. Approved actions can then be emailed to their owners.

Huddle serves 3,000 companies whose users currently write notes themselves. Speaker labels are wrong about 8% of the time, and roughly 15% of meetings include an uninvited participant. Calendar membership and transcript attribution therefore cannot establish attendance or ownership.

The MVP will not fulfil Sales’ request for immediate, unreviewed owner emails. It will generate drafts automatically after transcription and send emails automatically after explicit publication. Faster delivery does not justify assigning work to absent people. All requirements and numerical targets below are proposed product decisions.

Scope and intended outcome

Primary users are meeting hosts reviewing records and attendees receiving actions. Success means less time producing dependable notes, with no assignments to non-attendees.

MVP includes English transcripts, decisions, action extraction, attendance verification, host review, publication and owner emails. Exclude live summaries, recurring reminders, task-system integrations and automatic reassignment. Use existing meeting access and retention controls.

An action has one verified owner or remains unassigned. Split genuinely separate responsibilities into separate actions. Do not infer deadlines, commitments or decisions from tentative discussion.

Attendance is a release dependency

Engineering must first confirm whether Huddle retains authenticated participant identities and join/leave events. The supplied calendar list is insufficient. If these records are unavailable, build attendance instrumentation before enabling assignments; summaries may still launch with unassigned actions.

An eligible owner must have a stable person identifier linked to an authenticated, human participant session with a recorded join event for this meeting occurrence. Calendar invitees who never joined are ineligible. Bots and room devices are ineligible. Deduplicate reconnects by identity. Someone who left early remains eligible, although a later discussion does not prove they accepted work.

Uninvited users are eligible when their authenticated join is recorded. Guest display names, shared-room speaker labels and email addresses typed by a reviewer are not identity evidence. Unverified guests and people represented only by a room device remain ineligible in MVP; explain how they can join individually with verified identity for future meetings.

This deliberately sacrifices assignment coverage. The invariant is enforceable against verified participation records, not proof of physical human presence behind an account. If literal physical presence is required, that remains an unresolved product constraint and assignments must not launch under a stronger guarantee.

Ownership and extraction rules

The model extracts structured candidates with supporting transcript spans. Each decision contains its outcome and evidence timestamps. Each action contains a task, supporting spans, optional explicit due date and a nullable candidate participant identifier. Preserve the original date wording alongside any normalised date, using the meeting timezone; ambiguous dates stay unset.

Only explicit commitments or clearly agreed assignments qualify as actions. Suggestions, questions and rejected proposals do not. Where later discussion reverses a decision, present the final supported outcome. If the resolution is unclear, flag it for review instead of declaring a decision.

A model candidate is internal metadata, never an assigned owner. Server validation rejects identifiers outside the eligible attendance set before anything is displayed. The review UI starts every owner field as “Unassigned”; reviewers choose an eligible attendee after checking evidence. Do not preselect names from speaker labels, including for “I’ll do it”.

Render ownership only from validated structured fields. Generated task and decision wording must not embed owner claims that bypass these controls. Unsupported person-specific claims are withheld for review. A request that absent Alex should do something can become an unassigned “Confirm responsibility for…” follow-up only when that follow-up was actually agreed; otherwise omit it as an action.

Review and publication experience

The meeting page shows “Preparing summary” after the call, then “Draft needs review”. The host is the default reviewer; existing authorised meeting editors may also review. If no reviewer is available, retain the draft without sending owner emails.

Display separate Decisions and Actions sections. Each item links to its transcript passage and recording timestamp. Offer edit, delete and add controls. Actions show task, owner and due date. An attendance-only owner picker explains why invitees or unresolved guests cannot be selected. Provide a visible “Needs owner” state rather than silently dropping useful work.

Reviewers must confirm each chosen owner and can publish with unresolved actions. The publish dialogue shows recipients and unresolved-action count, with an explicit “Publish and email owners” control. Actions without owners remain visible but produce no email. Keyboard navigation, labelled controls and screen-reader status announcements are required.

Published records show their revision and approval time. Subsequent edits create a new revision. Ownership changes require the same validation and explicit publication, then notify affected owners with a correction. Never silently replace a published record with regenerated content.

Engineering contract and failure behaviour

Use meeting occurrence IDs, not recurring calendar series IDs. Store transcript version, attendance evidence version, model/prompt version, summary revision, item IDs, evidence spans, owner ID, approval actor/time and delivery status. Keep internal candidates separate from approved owner fields.

Process states are waiting for transcript, generating, needs review, published and failed. Trigger generation only after transcript finalisation. Transcript changes invalidate unpublished approvals and create a fresh draft; published revisions remain intact until a replacement is approved.

Enforce owner eligibility server-side on draft writes, publication, exports and notification dispatch. Manual edits and direct API calls cannot bypass it. If attendance evidence is missing, contradictory or unavailable, block ownership and sending rather than falling back to calendar data. Record rejection reasons for support without exposing transcript content in routine logs.

Use transactional publication and an outbox. Delivery keys combine meeting, published revision and recipient so retries do not duplicate emails. Email only approved actions owned by that recipient, with a permission-checked meeting link. Resolve addresses from verified identities, never model output. Block delivery if permissions or identity validation fail; show the reviewer the failure. Retry transient failures with backoff for up to 24 hours, then offer manual retry.

Treat transcripts as untrusted data: spoken instructions cannot change permissions, choose recipients or trigger tools. Generation has no email capability. Preserve tenant isolation and apply meeting deletion and retention policies to summaries and queued notifications.

Acceptance scenarios

1. Invited Pat never joins but is named in an action: Pat is absent from the picker; API assignment is rejected; no owner email is sent.

1. Uninvited authenticated Lee joins: Lee is eligible and can receive an action after reviewer confirmation and publication.

1. Several people join through one room device: no individual becomes eligible from its label; actions remain unassigned unless independent authenticated participation exists.

1. Overlapping speech mislabels a commitment: no owner is preselected; the reviewer can inspect evidence and choose a verified attendee or leave it unassigned.

1. No decisions or actions are supported: show explicit empty states rather than inventing content. Failed or incomplete transcription shows a retry state and sends nothing.

1. A forged owner ID, missing attendance record or duplicate publish event cannot create an invalid assignment or duplicate email. Revoked access blocks queued delivery.

Evaluation and release

Build a consented, de-identified evaluation set of at least 200 meetings, deliberately including overlap, shared rooms, absent invitees, uninvited guests, duplicate names, reversals and ambiguous commitments. Human annotators label attendance, final decisions, actions, ownership and evidence; adjudicate disagreements independently. Report each difficult slice separately.

Release gates: zero non-attendee assignments or deliveries across end-to-end and adversarial tests; at least 95% precision and 85% recall for supported decisions and actions, measured separately. Zero observed violations is necessary but insufficient: eligibility enforcement must also pass API and notification-path tests. Model confidence alone never permits assignment.

Pilot with ten opt-in companies before staged rollout. Target draft availability within two minutes of final transcript for 95% of meetings up to 60 minutes, and a 50% reduction in median note-preparation time against pilot baseline. Track owner corrections, unassigned-action rate, publication rate and delivery failures. Any non-attendee assignment disables assignments and sending pending investigation. Expand only after two weeks without a critical violation and acceptable review effort; do not reduce abstention merely to improve coverage.