Needs more than a quick edit7 of 11 checks passed
The PRD assumes a participant session log that is not confirmed by context; a PM would need to verify this assumption and adjust the roster design before building.
Output
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
| Limit | Impact | Design response |
|---|---|---|
| Speaker labels wrong ~8% of the time, mostly during overlapping speech | Owner may be misattributed | Attach an attribution confidence score to each action item. Low-confidence items are held for review (FR-6). |
| ~15% of meetings include uninvited joiners | Roster from calendar is incomplete | Build the roster from the participant session log, not the invite (FR-1). |
| Multiple people share one room device | Speaker labels can't separate them | Flag room-device speech as "multi-person source." Items attributed to a shared source require owner confirmation (FR-7). |
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
- Should the review queue notify the organizer by email, Slack, or in-app only?
- When an owner is an external email address, what is the policy under the admin domain setting?
- How will we handle meetings where the transcript contains no clear owner for a decision or action?
- Do we need a per-workspace setting to require organizer approval for all items?
- 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.
Claims the judge couldn’t find in the brief
- The platform has a participant session log (the platform's record of who joined).
Grades and run details
Decision model 77 · LLM judge 58
Decision model checks
- failUses the supplied evidence correctly11%
- passAddresses the actual decision86%
- passRespects explicit constraints51%
- passIdentifies material uncertainty82%
- partialAvoids unsupported claims38%
- passProduces the required deliverable79%
- passSpecifies AI failure behaviour100%
- passSuccess settles trade-offs76%
- partialProposes tests that could fail74%
- passSays who it's for, and who it isn't37%
- partialPlans how people will find it98%
Run
- Run
- #1
- API response time
- 20 s
- Submitted
- 8 Oct 2026