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.

Product Requirements Document (PRD)

Feature: Automated Meeting Summaries, Decisions, and Action Item Attribution Product: Huddle Video Conferencing Target Audience: Engineering Leads, Design Leads, Product Ops Status: Ready for Review Target Release: Q3

---

1. Executive Summary & Objective

Today, Huddle’s 3,000 corporate customers rely on manual note-taking. This results in lost context, untracked deliverables, and administrative drag.

This project introduces an AI-powered pipeline that automatically generates: 1. A concise meeting summary. 2. A structured list of key decisions. 3. Assigned action items mapped strictly to verified attendees.

Key Objectives

• Reduce post-meeting admin time by 80%.
• Achieve $\ge 90\%$ user acceptance rate on action item assignments (measured by lack of manual re-assignment or deletion).
• Hard Rule Compliance: 0% assignment of action items to non-attendees.

---

2. Participant Verification & System Constraints

Our models must handle two structural data flaws: 1. Diarization/Labeling Error Rate: ~8% of transcript lines have inaccurate speaker tags (common during crosstalk or multi-person hardware rooms). 2. Ad-Hoc Joiners: ~15% of meetings feature participants who were not on the original calendar invite.

2.1 The "Eligible Assignee" Rule Engine (Non-Negotiable)

``` [Calendar Invite] [Client Telemetry Logs] \ / \ / v v +----------------------------------------+ | Participant Reconciliation Engine (PRE)| +----------------------------------------+ | v [Eligible Assignee Roster (EAR)] - Authenticated Users (User ID + Email) - Verified Guests (Session ID + Display Name) | v +----------------------------------------+ | LLM Extraction & Assignment Pipeline | +----------------------------------------+ | +--> Action assigned to User in EAR? --> ACCEPT | +--> Action assigned to External Party? | v Route to In-Room Proxy (or flag as Unassigned Dependency) ```

Constraint Definition: An action item can only be assigned to an entity present in the Eligible Assignee Roster (EAR) for that specific meeting session.

#### Step 1: Ingest Telemetry at Call Termination (`call.ended` event) Do not rely on the calendar invite as the source of truth for presence. Telemetry establishes physical attendance: * Calendar Attendees ($P{cal}$): Used only as an identity-matching fallback. * Connected Clients ($P{conn}$): Every participant with connection duration $> 60\text{ seconds}$ in the meeting telemetry logs. * Eligible Assignee Roster ($EAR$): Defined strictly as $EAR = P_{conn}$.

#### Step 2: Resolving the 15% Uninvited Attendees * Authenticated Joiners: If an uninvited joiner is logged into a Huddle account, resolve their `userid`, display name, and email directly into the $EAR$. * Guest Joiners (Unauthenticated): If a user joins via guest link without an account: * Capture their client display name and the session ID. * Tag them in the $EAR$ as `Guest: [Display Name]` with `userid = null`. * They are eligible for assignment in the UI, but will require an email address input if notifications are to be sent.

#### Step 3: Mitigating the 8% Diarization Noise Diarization errors mean the speaker label alone cannot be trusted for commitments (e.g., if Bob says "I'll take that," but the audio engine tags Alice). * The LLM prompt must cross-reference explicit verbal attribution ("Jane, can you take that?" $\rightarrow$ "Sure") against semantic context rather than relying exclusively on transcript speaker IDs. * When semantic confidence falls below threshold ($\tau < 0.75$), flag the action item as Unassigned rather than guessing.

#### Step 4: External Dependencies (Out-of-Room Third Parties) If a meeting participant says: "We need legal to review this, I'll have Sarah from Legal look at it," Sarah was not present and cannot be assigned the task. * Enforcement: The system assigns the task to the speaker (the in-room proxy) as: Assignee: Current Speaker (`[Speaker Name]`) Task: "Coordinate with Sarah (Legal) to review [X]." * If the speaker cannot be deduced with high confidence, set `assignee = UNASSIGNED` with a note: `External dependency: Sarah (Legal)`.

---

3. Product & Feature Specifications

3.1 LLM Processing Pipeline

Within 60 seconds of call termination, the processing service executes the following workflow:

``` [Call Ended] | v [Fetch Clean Transcript + Telemetry EAR] | v [LLM Context Construction] ├── System Prompt & Guardrails ├── Strict EAR List (Names + Emails + IDs) └── Diarized Transcript | v [Structured Output JSON Generation] ├── Executive Summary (Paragraph, <= 150 words) ├── Key Decisions (Bullet points) └── Action Items (Array: Task, Assignee ID, Due Date, Evidence Quote) | v [Deterministic Post-Processing Validator] ├── Cross-reference every Assignee ID against EAR └── Overwrite invalid assignments to "UNASSIGNED" | v [Summary Artifact Created & Persisted] ```

3.2 Action Item Post-Processing Validation Logic

Before writing to the database, run a deterministic verification function:

```python def validateactionitems(extractedactions, eligibleassigneeroster): validatedactions = [] for action in extractedactions: assigneeid = action.get("assigneeid") # Validation: Assignee must explicitly exist in the EAR if assigneeid and assigneeid in eligibleassigneeroster: action["status"] = "assigned" action["assignee"] = eligibleassigneeroster[assigneeid] else: # Fallback for hallucinated or external assignments action["status"] = "unassigned" action["assignee"] = None action["flag"] = "ASSIGNEENOTINROOM" validatedactions.append(action) return validated_actions ```

---

4. Sales Request Resolution: Auto-Email Notifications

The Conflict

Sales requested that action items be emailed automatically to assignees immediately when the meeting ends. However, because speaker labels fail ~8% of the time, immediately sending unreviewed emails will blast misattributed commitments to clients and internal executives, eroding trust.

The Solution: "Grace Period Auto-Dispatch"

We satisfy Sales' need for immediate execution while protecting data integrity through a time-delayed trigger and host bypass mechanism.

``` [Meeting Ends] │ ├─► AI Generates Artifacts (Target: <60 seconds) │ ├─► Start 5-Minute Grace Period │ │ │ ├─► Host edits/approves? ──► Send instantly with updates │ │ │ └─► Timer expires? ────────► Auto-dispatch without host intervention │ └─► (Workspace Setting Override: "Instant Send" with 0-min delay available) ```

1. Host Review Window (Default): * A 5-minute countdown starts the moment the summary finishes processing. * The meeting host gets a browser/desktop push notification: "Your Huddle summary is ready. Auto-sending in 5:00 minutes. Click to review." * If the host makes edits or clicks "Send Now", the countdown ends and emails dispatch immediately. * If the host takes no action, the emails dispatch automatically at the 5-minute mark. 2. Sales/Workspace Configuration Flag: * Enterprise Admins can toggle the grace window per team (e.g., Sales team can set Grace Period to `0 minutes` for true instant dispatch; default for other workspaces is `5 minutes`). 3. Safety Fallback: Action items marked as `UNASSIGNED` are omitted from individual assignment emails and instead bundled exclusively into the primary meeting recap sent to the host and organizer.

---

5. User Experience & Design Specs

5.1 Post-Meeting In-App Summary Tab

Located inside the Huddle desktop and web apps under the meeting historical detail view.

``` +-----------------------------------------------------------------------+ | Meeting Summary: Product Architecture Sync [Share] [Edit]| | Today at 10:00 AM • 42 mins • 6 Attendees | +-----------------------------------------------------------------------+ | EXECUTIVE SUMMARY | | The team finalized the data migration strategy for Q3. Key risks | | around API rate limiting were addressed by introducing Redis caching.| +-----------------------------------------------------------------------+ | DECISIONS MADE | | • Chose Redis over Memcached for distributed cache. | | • Deferred mobile client updates to Sprint 44. | +-----------------------------------------------------------------------+ | ACTION ITEMS Auto-sending in [ 04:12 ] [x]| | [ + Add Action Item]| | [x] Task: Implement Redis cache layer | | Assignee: [ (Avatar) David Chen v ] Due: [ Friday v ] | | Source: "David: I can set up the cluster by end of week." | | | | [ ] Task: Verify Legal compliance on data retention | | Assignee: [ Unassigned v ] Due: [ Set Date v ] | | ! Flag: External dependency (Sarah / Legal was not present) | +-----------------------------------------------------------------------+ ```

5.2 Key UI Components

1. Assignee Dropdown Menu: * Filtered exclusively to individuals in the $EAR$. * Section 1: Authenticated Attendees (1-click select). * Section 2: Ad-Hoc / Guest Attendees (Displays `[Guest Name] - prompt for email`). * Option to select "Unassigned". * Explicitly disallows searching the global company directory within the "Assignee" field to prevent violating the non-attendee constraint. 2. Context Tooltip ("Source"): * Hovering over an action item shows the transcript snippet that triggered the assignment, allowing the host to quickly verify ambiguous attributions caused by diarization errors.

---

6. Email Dispatch Specs (Sales Notification System)

6.1 Individual Assignee Notification

• To: Assignee email
• Reply-To: Host email
• Subject: `[Action Required] Action item from: {Meeting Title}`

``` Hi {Assignee First Name},

The following action item was assigned to you during {Meeting Title}:

Task: {Task Description} Due Date: {Due Date or "Not specified"} Context: "{Relevant transcript excerpt}"

View full meeting notes and recording: {Link to Huddle Meeting Record}

Did the AI get this wrong? Click here to reassign or remove: {One-Click Edit Link} ```

---

7. Telemetry, Edge Cases & Error Handling

---

8. Success Metrics

1. Attribution Precision: $\ge 98\%$ of assigned action items correctly reflect real commitments made by that person (measured via sampling and low manual-edit rates).
2. Zero-Hallucination Rate: $100\%$ compliance with the hard constraint: 0 automated emails dispatched to individuals outside the $EAR$.
3. Dispatch Velocity: 95th percentile of summary and action item deliveries completed within $< 90\text{ seconds}$ post-meeting (or exactly at the expiration of the chosen grace period).
4. Host Intervention Rate: $< 12\%$ of summaries require manual host corrections during the grace period window, indicating high trust in baseline accuracy.

Product Requirements Document: AI Meeting Summaries & Action Items

Product: Huddle Author: Product Management Target Audience: Engineering & Design Leads Status: Ready for Kickoff

---

1. Overview & Problem Statement

Huddle currently records and transcribes video meetings for 3,000 B2B customers. However, users still spend 10–15 minutes after every call reviewing transcripts or typing up raw notes to document decisions and action items.

We are building an AI-powered post-meeting summary feature that automatically extracts Key Decisions and Action Items (with assigned owners) from meeting transcripts.

The Core Tension: Speed vs. Accuracy

Sales has requested that we automatically email action items to their owners the moment a meeting ends. However, we have three strict operational realities: 1. Hard Constraint: We must never assign an action item to someone who did not attend the meeting. 2. Data Gap 1 (The 15% problem): 15% of meetings include uninvited guests (e.g., forwarded links, conference rooms) who are missing from the calendar invite. 3. Data Gap 2 (The 8% problem): Speaker diarization/labels are wrong 8% of the time, primarily due to crosstalk or multiple people sharing one room mic.

Product Decision: If we auto-send emails immediately after the meeting ends, the 8% speaker attribution error rate and the 15% calendar mismatch rate will inevitably cause us to violate our hard constraint or embarrass users by emailing the wrong people. Therefore, v1 will use a "Human-in-the-Loop" flow with a fallback auto-send. For high-confidence extractions, emails will send automatically after a 30-minute review window. For low-confidence extractions (crosstalk, unverified guests), we will hold the email until the meeting host approves the summary.

---

2. Goals & Success Metrics

---

3. System Architecture & The "Actual Attendee" Roster

Right now, Huddle relies on the calendar invite for the attendee list. To obey our hard constraint, Engineering must build a unified `Actual_Attendees` service that fires when a meeting ends.

Defining an "Actual Attendee"

A person is only eligible to be assigned an action item if they exist in the `Actual_Attendees` array for that specific meeting session. Calendar invitees who did not join the call are explicitly excluded.

1. Authenticated Huddle Users: Anyone who joins the call while logged into a Huddle account is added to `Actual_Attendees` (solves the 15% uninvited guest problem for logged-in users).
2. Unauthenticated Web Guests: Guests joining via link must type their display name in the pre-call lobby. They are added to `Actual_Attendees` with `email: null`.
3. Conference Room Hardware: When a room system joins (e.g., "4th Floor Conf Room"), the room itself is not an assignable person. (See Edge Cases in Section 4).

---

4. Functional Requirements (Engineering)

4.1 LLM Extraction Pipeline

* Trigger: Fires upon completion of the final meeting transcript. * Inputs: 1. Time-stamped transcript with speaker labels. 2. Diarization confidence scores per utterance. 3. The `ActualAttendees` JSON array (Name, UserID, Email, JoinMethod). 4. The `CalendarInviteesNoShow` array (Explicit negative constraint list). * Prompting & Guardrails: * Decisions: Extract 1–7 bullet points summarizing agreed-upon outcomes. Include timestamp citations. * Action Items: Extract tasks, deadlines (if mentioned), and the owner. * Assignment Logic: The LLM may only populate the `owner` field using an exact match from `ActualAttendees`.

4.2 Handling the Constraints & Edge Cases

• Scenario A: Someone on the call says, "Let's have Sarah do this," when Sarah is NOT in `Actual_Attendees`.
• System Behavior: The system must not assign the task to Sarah. Instead, it assigns the task to the speaker who volunteered Sarah (or leaves it "Unassigned") and rewrites the task text to: "Follow up with Sarah to [do X]."
• Scenario B: The 8% Speaker Label Error (Crosstalk / Low Confidence).
• System Behavior: If an action item is derived from an utterance where someone says "I will do X", the pipeline checks the diarization confidence score for that timestamp block. If confidence is `< 0.85` or overlaps with another speaker within 1.5 seconds, the system sets `owner: Unassigned`, sets `suggestedowner: [SpeakerID]`, and flags the item as `needs_review: true`.
• Scenario C: Multi-person Conference Rooms.
• System Behavior: Audio coming from a single hardware node containing multiple voices cannot reliably attribute "I'll take that" to an individual. If the speaker label is a Room Resource or has multi-voice flags, the LLM may only assign an action item if a name is spoken explicitly in the third person (e.g., "Thanks Dave, so Dave will pull the Q3 numbers" AND "Dave" is matched to a Huddle user via calendar invite + confirmation). Otherwise, set `owner: Unassigned` (`needs_review: true`).
• Scenario D: The 15% Uninvited Guest.
• System Behavior: If "Alex" joined via a forwarded link without logging in, he is in `ActualAttendees` as `{name: "Alex (Guest)", email: null}`. The system can assign action items to "Alex (Guest)" in the UI, but flags the item as `missingemail: true`.

4.3 The Email Dispatch Engine (Addressing the Sales Request)

To satisfy Sales without sending hallucinated assignments, we will implement a Two-Track Dispatch Engine:

• Track 1: High-Confidence Auto-Send (30-Minute Delay)
• Condition: All extracted action items have `owner != Unassigned`, `needsreview == false`, and `missingemail == false`.
• Behavior: The host gets an immediate Slack/Email ping: "Your meeting summary is ready. Action items will be emailed to owners in 30 minutes unless you edit them." If the host makes no changes within 30 minutes (or clicks "Send Now"), emails are dispatched to action item owners.
• Track 2: Low-Confidence Hold
• Condition: One or more action items are flagged `needsreview: true` or `missingemail: true`.
• Behavior: Auto-send is paused. The host is notified: "Your meeting summary has 2 action items that need your confirmation before we email the team." Emails only trigger once the host resolves the flags and clicks "Approve & Send".

---

5. User Experience & Design Requirements

5.1 Pre-Meeting Lobby (Small tweak for Guest ID)

• Unauthenticated Guests: Update the pre-join screen. Require both Full Name and Work Email (Optional) before joining. Explaining "Used to send you meeting notes" will convert a high percentage of the 15% uninvited guests into identifiable users.

5.2 Post-Meeting Summary View

The Meeting Host (and participants) will access the summary inside the Huddle web/desktop app under the "Past Meetings" tab.

* Layout: Split screen. Left side: Video player + searchable transcript. Right side: AI Summary widget. * Summary Widget Sections: 1. Status Banner: Shows dispatch state (e.g., "Auto-sending to 4 owners in 24 mins [Send Now] [Pause]" OR "Approval Required before emailing"). 2. Decisions Made: Bulleted list. Hovering over a decision highlights the corresponding timestamp in the transcript and lets the user click to play that 15-second clip. (Crucial for building user trust). 3. Action Items List: Each row contains: * Checkbox (for completion tracking). * Task description (inline editable). * Assignee Dropdown Pill. * Source timestamp link.

5.3 The Assignee Dropdown & "Needs Review" UI

• Restricted Roster: When a user clicks the Assignee Pill to change or add an owner, the dropdown menu only lists people from the `Actual_Attendees` array.
• Design detail: Below a divider line at the bottom of the dropdown, show calendar invitees who didn't show up in greyed-out, unclickable text with a tooltip: "Did not attend meeting." (This prevents users from thinking the dropdown is broken while enforcing our constraint—unless someone was hiding in a conference room, see below).
• Conference Room Override: If a meeting included a Room system, include an option in the dropdown: `+ Add person who was in [Conf Room Name]`. Clicking this allows the host to pick from the org directory, explicitly confirming that the person was physically present in the room.
• Low-Confidence Visual State: Action items flagged with `needs_review: true` (due to the 8% diarization issue) should have an amber highlight around the Assignee Pill reading: `Suggested: [Name] ?`. Clicking it lets the host confirm with one click.

5.4 The Action Item Email

• Subject: `Action Items from [Meeting Title] ([Date])`
• Body:
• Personalized top section: "Assigned to You (2):" followed by their specific tasks.
• Context section below: "All Decisions & Team Action Items" so they have full context.
• Footer CTA: `[View Full Recording & Transcript in Huddle]`.

---

6. Out of Scope for v1

• 3rd-Party Task Manager Integrations: Pushing tasks to Jira, Asana, Linear, or Salesforce (planned for v1.1 after we validate extraction accuracy).
• Cross-Meeting Action Item Tracking: A global "My Tasks" dashboard across all meetings. v1 is strictly scoped to the single-meeting view and email dispatch.
• Voiceprint Enrollment: Having users record their voice to fix the conference room diarization problem. We will rely on UI fallbacks for v1.

---

7. Open Questions for Kickoff

1. Engineering: What is the p95 latency for transcript generation + LLM summary extraction on a 60-minute call? Sales expects "as soon as the meeting ends"—if our pipeline takes 8 minutes, do we need to adjust the 30-minute auto-send timer?
2. Design: If a meeting has zero decisions and zero action items (e.g., a casual 1:1 catch-up), what should the empty state look like, and should we suppress the post-meeting notification entirely?
3. Engineering: Can our current diarization vendor expose word-level confidence scores via their webhook, or do we need to calculate crosstalk purely by checking overlapping speaker timestamps?