AI Meeting Notes

Editing technical v0.1 — published

Tab to switch the tab. Save writes a vNEW-DRAFT.md alongside the published file.

Markdown source

# AI Meeting Notes – Technical Specification
- Task Manager – Technical Specification v2.2.docx
- Communication Hub – Technical Specification v2.1.docx
- Security & Privacy – Technical Specification v2.0.docx
- Primoro AI Meetings – Technical Specification v1.1.docx

## 0. Change Summary (v2.2)

This revision locks AI Meeting Notes to a recording‑first operating model and introduces a governed sign‑off + retention workflow while preserving Primoro's non‑negotiables: explicit capture (not passive), review‑first outputs, human confirmation for actions, RBAC everywhere, and full auditability.

Key changes in v2.2:

- All meetings recorded by default within this module; recordings are available for organiser playback and can be shared optionally.
- Live transcription + live note drafting during the meeting; final actions are produced at the end through a governed review and selection flow.
- Recording retention default = 30 days with an end‑of‑meeting sign‑off step to change expiry; the retention decision is auditable and can create a Task to revisit later.
- Speaker attribution strengthened via staff voice profile mapping (governed, assistive, confidence‑aware) and room capture hardware requirements (omnidirectional microphones for multi‑speaker rooms).

## 1. Purpose of This Specification

This document is the authoritative technical contract for the AI Meeting Notes module within Primoro.

No recording, transcription, summarisation, speaker attribution, sign‑off, retention, sharing, export, or action→task conversion behaviour may operate outside the rules defined here.

## 2. Module Purpose & Scope

AI Meeting Notes is Primoro's recording‑first internal meeting capture and actionisation module for staff‑to‑staff meetings.

Its purpose is to ensure that internal meetings reliably produce:

- an organiser‑controlled recording (playback available post‑meeting)
- a review‑first, editable meeting record (summary, topics, decisions)
- confirmed actions that become governed, calendar‑backed work in Task Manager

Explicit scope boundary: This module is for internal meetings only (management, HR, governance, ops, projects). Patient conversations are explicitly excluded.

## 3. Responsibilities & Non‑Responsibilities

### 3.1 AI Meeting Notes IS Responsible For

- Recording meetings created/managed under this module (recording‑first behaviour).
- Live transcription and live note drafting during meetings (assistive).
- Producing a structured Note Pack (summary/topics/decisions/actions) that is never auto‑finalised and remains review‑first.
- Post‑meeting action review: users check/select/tweak ActionCandidates before any task is created.
- Creating Tasks only from explicitly confirmed actions, and linking them back to the meeting record.
- Enforcing RBAC, privacy‑by‑design, retention/expiry, and immutable audit trails for all access and changes.

### 3.2 AI Meeting Notes IS NOT Responsible For

- Message delivery primitives, channels, or conversation storage (owned by Communication Hub).
- Task execution lifecycle, boards, SLA states, recurrence execution, or completion evidence (owned by Task Manager).
- Passive or hidden recording ("always‑on listening"); capture must remain explicit and transparent even though recording is default for this module.
- Autonomous AI actions (no auto‑task creation/assignment/completion without human confirmation).

## 4. Governance, Privacy & Use Boundaries (Non‑Negotiable)

AI Meeting Notes must follow platform‑wide security principles: minimum data exposure, least‑privilege access, secure defaults, defence in depth, and auditability as a first‑class requirement.

- Transparency: Participants must be informed that meeting assistance is active.
- Control: Organisers can start/stop capture; capture may also be auto‑enabled for configured meeting types (recording is default for this module, but must still be explicitly indicated in‑meeting).
- RBAC: Access to transcripts, summaries, and action items is role‑controlled.

## 5. Authoritative Objects (Build‑Contract Primitives)

### 5.1 MeetingNoteRecord (Canonical Container)

A MeetingNoteRecord is the canonical container for a meeting's recording, transcript, note pack, sign‑off state, retention, and audit events.

Minimum properties:

- MeetingNoteId (immutable)
- Title, StartDateTime, EndDateTime
- OrganiserUserId
- MeetingTypeTag (template key)
- Sensitivity (Standard | Restricted | Private)
- Status (Draft | In‑Review | Final | Archived)
- RecordingArtefactRef (nullable if capture failed)
- TranscriptArtefactRef (nullable)
- NotePackRef (nullable until generated)
- RetentionPolicy (defaulted) + RecordingExpiryAt
- SignOffState (NotStarted | InProgress | Completed)
- AuditLogRef (immutable)

### 5.2 RecordingArtefact (Supporting Artefact)

A RecordingArtefact is a time‑bounded audio/video artefact associated with a MeetingNoteRecord and governed by retention rules.

### 5.3 TranscriptArtefact (Derived Artefact)

A TranscriptArtefact is the time‑stamped transcript derived from the recording (live and/or post‑meeting).

### 5.4 NotePack (System of Record for Outcomes)

The NotePack is the authoritative record for outcomes and MUST include:

- Purpose / Summary
- Topics (segmented)
- Decisions (explicit list)
- ActionCandidates (unconfirmed)

### 5.5 ActionCandidate (Pre‑Task Object)

ActionCandidates are proposed actions extracted from meeting content.

Rule: ActionCandidates MUST NOT become Tasks until an authorised user confirms them.

## 6. Recording Model (Authoritative)

### 6.1 Default Recording Behaviour

All meetings managed under AI Meeting Notes are recorded by default.

### 6.2 Participant Awareness & Visible Recording Indicator

Recording MUST be visibly indicated during capture, and participants must be informed that meeting assistance is active.

### 6.3 Organiser Playback & Optional Sharing

- The organiser can replay the recording after the meeting.
- The organiser may optionally share recording access and/or derived artefacts to permitted users based on RBAC and sensitivity rules.

### 6.4 Capture Modes (Supported Inputs)

Meetings can be captured via approved room microphones/devices and supported platforms.

## 7. Live Transcription & Live Note Drafting (During Meeting)

### 7.1 Live Transcription

The system MUST support live transcription during the meeting and store a time‑stamped transcript with confidence scoring.

### 7.2 Live Note Drafting (Assistive)

During the meeting, the system MAY draft:

- evolving summary blocks
- topic segment candidates
- decision candidates
- action candidates

These remain non‑authoritative until post‑meeting review.

## 8. Post‑Meeting Processing (Review‑First Outputs)

### 8.1 Output Generation

After the meeting ends, the system MUST generate a NotePack draft containing summary/topics/decisions/actions.

### 8.2 Review‑First (Never Auto‑Finalised)

Notes are never auto‑approved. Authorised users can review, edit, and redact; a full audit trail is retained.

## 9. Action Confirmation → Task Creation (Hard Boundary)

### 9.1 Action Review Flow (End‑of‑Meeting)

Actions are finalised at the end via a governed workflow where the organiser (or authorised roles) checks, selects, and tweaks ActionCandidates.

### 9.2 Task Manager Integration (Authoritative Boundary)

Confirmed actions MUST create Tasks in Task Manager – Technical Specification v2.2.docx and link back to the MeetingNoteRecord.

Task Manager canonically owns all task creation; AI Meeting Notes MUST NOT generate tasks through any internal or autonomous path. When an ActionCandidate is confirmed, AI Meeting Notes MUST invoke Task Manager's canonical task-creation surface (API or integration contract) to create the task. AI Meeting Notes MUST NOT maintain its own parallel task record for confirmed items — the ConvertedTaskId stored on the ActionCandidate is a reference to the Task Manager record, not a duplicate. The authoritative audit trail for the created task (assignment, state transitions, completion evidence) is owned by Task Manager; AI Meeting Notes retains only the meeting-scoped audit events (see §14) covering the confirmation decision and the linkage to the resulting TaskId.

### 9.3 No Autonomous Task Actions

AI may suggest actions, owners, and due dates, but task creation/assignment requires human confirmation. The AI Meeting Notes module MUST NOT call Task Manager's creation surface prior to an explicit human confirmation event; doing so would constitute an autonomous task action and is prohibited under §3.2.

## 10. Speaker Attribution & Staff Voice Profiles (Governed)

### 10.1 Speaker Diarisation & Speaker Naming

AI Meeting Notes supports speaker diarisation where identity is available via meeting context and supports voice profile mapping to label staff speakers.

### 10.2 Voice Profile Mapping (Enrolment & Matching)

Voice profile mapping is assistive and requires human confirmation for mapping unknown speakers to staff profiles.

### 10.3 Confidence States & Safe Fallback

Speaker label states are confidence‑aware; where confidence is insufficient, the system MUST fall back to "Speaker 1/2/3" until confirmed.

### 10.4 Governance

Voice profile create/edit is RBAC‑restricted; staff may request removal/reset; encrypted voiceprints only (no raw audio for voiceprints), tenant‑scoped.

## 11. Microphone Hardware Standard (Room Capture Quality)

### 11.1 Multi‑Speaker Room Requirement

Meetings requiring multi‑speaker capture MUST use suggested microphone hardware with omnidirectional microphones.

### 11.2 Best‑Practice Reinforcement

Using an omnidirectional microphone improves capture in multi‑speaker rooms and supports better speaker identification outcomes.

### 11.3 Safe Degradation

If capture quality is insufficient, meeting notes must still be produced, but speaker attribution must degrade safely (unnamed speakers) rather than mis‑attribute.

## 12. Retention, Expiry & Sign‑Off (Build‑Contract)

### 12.1 Default Recording Expiry

Recordings auto‑expire by default after 30 days unless changed during sign‑off.

### 12.2 Sign‑Off Step (End‑of‑Meeting Governance)

At the end of the recording, the organiser MUST complete a sign‑off step that:

- finalises the NotePack status (Draft → In‑Review/Final as permitted)
- confirms which actions become Tasks
- sets recording retention (keep default expiry or change it)
- optionally creates a retention review Task (see 12.3)

### 12.3 Retention Review as a Task (Optional, Governed)

If the organiser extends retention (or chooses a non‑default retention outcome), the system MAY create a Task in Task Manager:

- Title: "Review retention for meeting: {MeetingTitle}"
- Owner: organiser (or configured governance role)
- Due date/time window: aligned to the chosen expiry/review date
- LinkedEntities: MeetingNoteRecord reference

This leverages Task Manager's calendar‑backed, auditable model for governance follow‑up.

### 12.4 Audit Requirements for Retention

All retention decisions and deletion/expiry events must be logged as attributable audit events.

## 13. Communication Hub Delivery (Optional Surface)

AI Meeting Notes MAY post a meeting summary/actions into Communication Hub as a delivery surface, but Communication Hub retains ownership of threads and primitives.

Any "message → work" conversion remains governed by Task Manager rules.

## 14. Audit & Compliance (Mandatory)

Auditability is first‑class: if data is accessed, viewed, changed, shared, or deleted, it is logged, attributable, and reviewable.

Audit log MUST capture:

- recording start/stop events
- who viewed playback (organiser and any shared users)
- transcript generation events
- note edits and redactions
- sign‑off completion
- action confirmations and Task creation linkages
- retention changes and expiry/deletion events
- voice profile mapping events and access to voice profile settings

## 15. Non‑Functional Requirements

- Performance: live transcription must not block meeting UX; security controls must not introduce noticeable UI latency.
- Reliability: recording artefact creation and task conversion must be idempotent and must not silently duplicate or lose outcomes.
- Security & Governance: least‑privilege everywhere; retention and deletion policies enforced; inspection‑ready by default.

## 16. Build Contract (Engineering & QA)

### 16.1 Canonical Data Model (Minimum Required)

MeetingNoteRecord

- MeetingNoteId (immutable)
- OrganiserUserId
- Sensitivity, Status
- RecordingArtefactRef, TranscriptArtefactRef, NotePackRef
- RecordingExpiryAt, RetentionPolicy
- SignOffState
- AuditLogRef

NotePack

- Summary
- Topics[]
- Decisions[]
- ActionCandidates[]

ActionCandidate

- CandidateId (immutable)
- Text
- SuggestedOwner (nullable)
- SuggestedDueDate (nullable)
- ConfirmationState (Proposed | Confirmed | Rejected | Converted)
- ConvertedTaskId (nullable) — reference to the Task Manager record created via Task Manager's canonical task-creation surface; not a locally owned task record

VoiceProfile (where enabled)

- StaffId linkage
- Enrolment state
- Encrypted voiceprint reference
- Audit coverage for create/edit/delete

### 16.2 Acceptance Criteria (QA Contract)

✅ Meetings created/managed in AI Meeting Notes are recorded by default, with visible recording indication and participant awareness.

✅ Organiser can replay the recording; optional sharing is permission‑controlled and auditable.

✅ Live transcription runs during the meeting and produces a time‑stamped transcript.

✅ NotePack is generated and remains review‑first (never auto‑finalised).

✅ Actions are confirmed via an end‑of‑meeting selection/tweaking flow; only confirmed actions create Tasks in Task Manager with back‑links, and task creation is invoked exclusively through Task Manager's canonical task-creation surface with no autonomous or parallel AI Meeting Notes–owned path.

✅ Default recording expiry is 30 days; retention can be changed during sign‑off; expiry/deletion is enforced and audit‑logged.

✅ Optional retention review Task can be created and revisited later (calendar‑backed governance).

✅ Speaker attribution supports voice profile mapping with confidence‑aware fallback; voice profile operations are RBAC‑restricted and auditable.

✅ Multi‑speaker rooms require omnidirectional microphone hardware; if capture quality is insufficient, system degrades safely to unnamed speakers without breaking meeting notes.

Live preview