Meetings, TRI & Minutes of Meeting

The authoritative specification for all meetings attached to a ticket — TRI tripartite reviews, hearings, departmental and direct meetings, and site visits — and for the upload-first Minutes of Meeting (MoM) lifecycle, AI extraction, approval gating, publish & auto-share, and analytics on the Sindh IT Portal — Facilitation Desk (SITP).

1. Scope & Definitions

This document is the single source of truth for Module M. It defines every kind of meeting that can attach to a ticket, how meetings are scheduled, how their minutes are produced and shared, and how action items inside the minutes flow back into the ticket as sub-tasks. It is the canonical reference for the meetings, meeting_attendees, mom, mom_approvals, mom_distributions, mom_acknowledgments, and meeting_recordings tables defined in /specs/en/05-data-model/ §4.9.

The ticket lifecycle, SLA, escalation ladder, proof-of-resolution gate, reopen/appeal windows, and the TRI/MoM summary that appears in /specs/en/06-ticket-workflow/ §9–§10 are governed there; this document expands them into the full Module-M specification. Where the two documents appear to differ, this document is authoritative for Module-M behaviour and the ticket-workflow doc defers.

Glossary (short form; see _glossary.md):

All capabilities described here are individually toggleable via the Feature Flag module (Q) and individually configurable via the per-department / per-category configuration described in §15.

2. Meeting Types

A meeting is always attached to exactly one ticket (the meetings.ticket_id foreign key). One ticket may have several meetings over its lifetime. The system recognises five meeting types, classified by purpose and the parties that must attend. The data model's meetings.type enum (see /specs/en/05-data-model/ §4.9) currently carries tri, hearing, internal; this document specifies the authoritative taxonomy and requires the enum to be extended (see §12 data-model recap) to cover the full set, with a subtype discriminator for further classification.

Common rules across types:

• Every meeting produces exactly one MoM (1:1 in mom.meeting_id, unique). There are no "minutes-less" meetings in the system; even an internal coordination meeting produces a short MoM for the audit trail.
• Every meeting is permanently attached to its ticket (audit-logged, immutable history). Cancelling or rescheduling a meeting never deletes its record.
• The five types share the same scheduling, consent, recording, publish, and acknowledgment machinery described below; they differ in required parties, quorum rules, approval routing, and the audience to which the MoM is shared (e.g. an internal MoM is not auto-shared to the company).

3. Scheduling & Calendar

3.1 Calendar model

Every meetings row carries scheduled_at, started_at, ended_at (all DATETIME(6), Asia/Karachi timezone by default), a status enum (§11), the modality, and where applicable the video_provider, join_url, and location_address. The portal maintains a per-user calendar view that aggregates every meeting a user is invited to, plus the Sindh Government holiday calendar and each department's business hours (see /specs/en/06-ticket-workflow/ §5.4) so that scheduling honours both.

3.2 Availability and conflict checks

On scheduling, the portal runs a conflict check across all invitees' calendars and the meeting-room / virtual-provider resource:

• A hard conflict (an invitee already has a scheduled or in_progress meeting overlapping the proposed slot) blocks the slot for that invitee and surfaces alternate free slots within ±N business hours (default N = 2), respecting each invitee's department business hours.
• A soft conflict (an invitee is marked "tentative" on another meeting, or is outside business hours) warns but does not block.
• The holiday check rejects any slot that falls on a Sindh public holiday (see holiday_calendar); the scheduler offers the next business day instead. Hijri-date holidays (Eid, Ashura, etc.) are resolved to Gregorian each year per /specs/en/06-ticket-workflow/ §5.4.
• A weekend check respects per-department weekend configuration (default Sat + Sun).
• Quorum validation. For TRI and hearings the scheduler enforces that the required quorum (§7.4) is achievable: at least one accept from each mandatory party is required before the meeting can move from scheduled to a confirmed state.

3.3 Reschedule and cancel

Any organiser (the S&ITD facilitator for TRI; the convening authority for hearings; the officer for internal/direct) can reschedule or cancel a scheduled meeting.

• Reschedule writes a new scheduled_at, re-runs conflict/quorum checks, and notifies all invitees with the updated time and a refreshed join_url (presigned, time-limited). The previous slot is freed. Each reschedule is audited (audit_events.type = meeting_rescheduled).
• Cancel sets meetings.status = cancelled with a reason; the slot is freed; invitees are notified; the linked mom (if already drafted) is retained in draft status with the cancellation reason for audit continuity. A cancelled meeting is never physically deleted.
• Auto-cancel on ticket terminal. If the parent ticket reaches a terminal state (Closed or Cancelled/Withdrawn) before the meeting's scheduled_at, the portal auto-cancels the meeting and notifies invitees, unless the organiser has explicitly marked the meeting as "proceed regardless".

3.4 Reminders

Reminders are sent to all attendees and watchers through their preferred channels per the Notification module (G):

Reminder timing and channels are configurable globally and per department in meeting_reminder_config (keyed by dept_id, type).

4. Modality & Video Providers

4.1 Modality

Each meeting is one of three modalities (meetings.modality):

• Physical — held at a venue; location_address is mandatory; no join_url. Recording (if any) is via a dedicated device; consent captured per §10.
• Virtual — held entirely online via a video provider; video_provider and a join_url are mandatory; location_address is null.
• Hybrid — some attendees in a physical venue, others joining virtually; both location_address and video_provider + join_url are populated.

The modality is chosen per meeting by the organiser and is not constrained by meeting type, with two exceptions: site visits (T5) are always physical; hearings (T4) default to physical unless the convening authority explicitly permits virtual attendance.

4.2 Video providers (configurable per meeting)

The portal integrates three configurable video providers — Zoom, Google Meet, and Microsoft Teams — behind a stable interface. The provider is selected per meeting by the organiser; it is not a global setting, because different departments and officials have different standard platforms.

Symbols per _conventions.md §8. ✓ supported · ◐ conditional.

Interface contract. Every video-provider integration implements:

VideoProvider {
  createMeeting(meeting)        -> { providerMeetingId, joinUrl, hostUrl, dialIn? }
  updateMeeting(meeting)        -> void
  cancelMeeting(meeting)        -> void
  getJoinUrl(meeting, user)     -> presigned, time-limited URL
  fetchRecording(meeting)       -> { mediaId, durationSeconds, format }
  fetchTranscript(meeting)      -> { mediaId, segments: [{speaker, start, end, text}] }
}

Provider credentials are stored in the secret store (see /specs/en/11-security-compliance/) keyed per (department, provider) so each department can use its own tenant.

On meeting creation the portal calls createMeeting, stores the returned providerMeetingId and a time-limited join_url (presigned; default TTL = scheduled time + 2 hours), and includes the join link in the calendar invite and reminders. Each join_url is rotated on reschedule.

On meeting completion (or on organiser request mid-meeting), the portal can call fetchRecording to pull the cloud recording (subject to consent — §10) and fetchTranscript to pull the speaker-labelled transcript. Both are stored as meeting_recordings rows linked to media_library blobs (encrypted at rest). The transcript feeds the AI transcription MoM mode (§8.2).

Fallback. If the selected provider's API is unavailable at meeting-creation time, the portal falls back to the department's secondary provider; if none is available, it generates a placeholder and asks the organiser to attach a manual meeting link. A meeting is never blocked solely because the provider API is down.

5. AI-Drafted Agenda

For every meeting the AI (module E, capability summary) auto-drafts an agenda from the parent ticket's full context, stored as meetings.agenda_json. The agenda is a suggestion; the facilitator reviews and edits it before invitations are sent (human-in-the-loop, principle P2 of /specs/en/07-ai-ocr-spec/ §1.1).

Inputs to the agenda:

• The ticket title, description, category, and SLA events.
• The full message history (PII-redacted).
• Attachment OCR text (evidence documents, prior MoMs, related correspondence).
• The escalation history and any prior TRI outcomes on the ticket.
• Linked / merged / similar tickets (only their metadata, not their bodies).

Output structure (agenda_json):

The agenda is generated in the facilitator's preferred locale and machine-translated into EN/UR/SD for the multilingual invitations. The facilitator can override any field; the diff between AI draft and final is logged to ai_feedback for the improvement loop. For hearings (T4) the agenda additionally surfaces the legal/statutory basis and the list of evidence to be taken on record.

6. TRI Trigger & Flow

6.1 When TRI is requested

A TRI is requested when normal ticket progress stalls. Any of the following can trigger it:

• The company rep — via the "Request TRI meeting" action on the ticket (visible to Primary/Admin reps; Filer if permitted by the Primary).
• The assigned department officer or section head.
• The S&ITD facilitator.
• Automatic — the SLA engine fires when a ticket has been Escalated at tier ≥ 2 with no movement for a configurable interval (default 3 business days).

A TRI request moves the parent ticket to On Hold (SLA clock paused) with reason "TRI meeting requested", creates a meetings row with type = 'tri', and notifies all three required parties. The TRI request itself is an audited event.

6.2 Approvals to convene

For non-sensitive tickets the TRI convenes on request without further approval. For sensitive or VIP tickets the request routes to the department's Chair/DG (or S&ITD DG where S&ITD is the concerned department) for sign-off before invitations are sent, mirroring the proof-of-resolution approval logic in /specs/en/06-ticket-workflow/ §7.3.

6.3 Parties and quorum

1. Company — Primary Authorized Rep (or delegated Admin/Filer), optionally with counsel or technical staff.
2. S&ITD — the assigned facilitator, who chairs the meeting.
3. Concerned Department(s) — the assigned officer plus the section head; for multi-department tickets, all concerned departments must attend or send a delegate.

Quorum for a TRI = at least one representative of each of the three parties. If quorum is not met 30 minutes after scheduled_at, the facilitator may either (a) adjourn and reschedule, or (b) proceed as a partial meeting whose MoM is clearly marked "partial — without [party]" and cannot record binding decisions.

6.4 Outcome

At meeting end the facilitator records the outcome as one of:

• Resolved — agreement reached. The ticket returns to In Progress only long enough to attach the agreed evidence (typically the signed MoM and any settlement/agreement), then moves to Resolved through the proof-of-resolution gate (/specs/en/06-ticket-workflow/ §7).
• Further action items — specific owners and due dates are recorded; these become ticket sub-tasks (§9.6) and the ticket returns to In Progress.
• Escalate — the meeting could not resolve the issue. The ticket moves to Escalated at the next oversight tier with the meeting record as supporting context.
• Adjourn — quorum not met, or more information/time is required. The ticket remains On Hold; a follow-up TRI is scheduled.

In every case a MoM is produced and permanently attached per §9.

6.5 TRI flow diagram

Written description. A TRI starts when a ticket stalls or sits at escalation tier 2 or higher without movement. Any of the company, the officer, the facilitator, or the SLA-engine auto-trigger can request it; the request creates a meetings row of type tri and parks the ticket in On Hold with reason "TRI meeting requested", pausing the SLA clock. For sensitive or VIP tickets the request first goes to the Chair/DG for sign-off; a decline keeps the ticket On Hold with the reason recorded. The AI auto-drafts an agenda from the ticket history and uploads, which the facilitator reviews and edits. Modality is selected per meeting — physical (venue booked), virtual (Zoom/Meet/Teams meeting created and join_url generated), or hybrid (both). Multilingual invitations go out and recording consent is captured before any recording starts. At the scheduled time, quorum is checked; if not met, the facilitator adjourns and reschedules. With quorum met, the meeting proceeds and the facilitator records one of four outcomes: resolved (ticket returns briefly to In Progress to attach the MoM and signed agreement as proof, then moves to Resolved); further action items (action items confirmed as sub-tasks, ticket returns to In Progress); escalate (ticket moves to the next escalation tier with the meeting record as context); or adjourn (follow-up TRI scheduled, ticket stays On Hold). In every case a MoM is produced and permanently attached per §9.

7. Attendees & Roles

7.1 Attendee record

Every person present at (or invited to) a meeting is recorded in meeting_attendees, tagged with a party (company, sitd, department, external) and a free-text role. Internal attendees are linked to users.id; external attendees (counsel, consultants, members of the public in a hearing) are recorded by name only.

7.2 Roles

7.3 Attendance status lifecycle

Each meeting_attendees row moves through invited → accepted | declined → attended | absent. The accepted count drives quorum validation in scheduling (§3.2).

7.4 Quorum rules by type

Quorum rules are configurable per (department, type) in meeting_quorum_config.

8. MoM Lifecycle (Upload-First)

The MoM flow applies to any meeting attached to a ticket — TRI, hearing, internal, direct, or site visit. The department preparing the MoM uploads it in its own format (PDF, Word, or images of a signed paper MoM); upload-first is the default and primary path per _context.md §5. Two alternative modes — manual template entry and AI transcription from recording — are available as feature-flagged toggles (§8.2, §15).

8.1 Upload-first lifecycle

1. Prepare & upload. After the meeting, the designated note-taker (usually the department's officer, sometimes the facilitator) prepares the MoM in the department's own template and uploads it (PDF/DOCX/PNG/JPEG; multiple files allowed). The upload is linked to the meeting and the parent ticket.
2. AV scan. ClamAV scans every upload (module D). Infected files are quarantined and the upload is rejected with a reason logged in audit_events.
3. Store. Clean files are encrypted and stored in MinIO under the moms bucket; a mom.source_media_id reference is set and a mom row is created (or its source_media_id updated if a prior draft exists).
4. OCR (if scanned). Image-only or scanned PDFs route through the pluggable OCR engine (Tesseract on-prem / Google Document AI / Azure Document Intelligence / AWS Textract) per /specs/en/07-ai-ocr-spec/ §3.2 and §4.1. OCR is multilingual (EN + UR + Sindhi, including Nastaliq and Naskh scripts) and produces a searchable text layer with confidence scores; low-confidence spans are flagged for review.
5. AI extraction. The AI service (module E, capability mom_extract, /specs/en/07-ai-ocr-spec/ §4.11) reads the OCR text (or native text for born-digital files) and extracts:
   • A structured summary of the meeting.
   • Action items — each with owner, ownerType (company/sitd/dept/external), due date (ISO-8601; Hijri preserved), description, priority, and linked ticket.
   • Decisions recorded, with the deciding party.
   • Attendees cross-referenced against the invitee list.
   • A machine translation to EN/UR/SD so participants can read the MoM in their preferred language (mom.body_en, mom.body_ur, mom.body_sd). Extraction results are written to extracted_action_items and a summary to mom.summary_ai.
6. Officer review & confirm. The uploading officer reviews the extracted action items in a side-by-side view (original document ↔ extracted table), corrects any mis-extraction (wrong owner, wrong date, false positive), and confirms. This is a mandatory human-in-the-loop checkpoint (principle P2). Confirmed action items become sub-tasks on the parent ticket (ticket_subtasks), each with its own owner, due date, and SLA slice (§9.6); the extracted_action_items.status flips to converted and the row is back-linked to the sub-task.

8.2 Alternative modes (feature-flagged)

These modes are off by default and enabled per department via feature flags (see §15):

In all three modes the human-in-the-loop confirm step is mandatory; no action item becomes a sub-task without officer sign-off, and no MoM is published without the approval gate (§9.3) clearing.

8.3 MoM lifecycle diagram (upload-first)

Written description. After any meeting, the MoM is produced through one of three modes. In the default upload-first mode, the responsible officer uploads the MoM in the department's own format (PDF, Word, or images of a signed paper document). In the manual template entry mode (feature-flagged), the officer fills a structured portal-side template. In the AI transcription mode (feature-flagged), the meeting recording is transcribed by the configured transcription engine and the LLM drafts a MoM from the transcript. For uploads, ClamAV scans every file; infected files are quarantined and rejected with an audit event, while clean files are encrypted and stored in MinIO. Scanned documents run through the pluggable multilingual OCR engine (English, Urdu including Nastaliq, and Sindhi including Naskh) to produce a text layer with confidence scores; born-digital files skip OCR. The AI service (capability mom_extract) then extracts a summary, structured action items with owners and due dates, recorded decisions, and the attendee list, and produces machine translations in all three languages, writing structured rows to extracted_action_items. The uploading officer reviews the extraction side-by-side with the original and confirms — a mandatory checkpoint; confirmed action items become sub-tasks on the parent ticket and the extracted_action_items.status flips to converted. For normal tickets the officer publishes directly; for sensitive or VIP tickets the MoM must first pass Chair/DG approval, and a rejection or "changes requested" returns it to the review step. On publish the MoM is versioned and permanently attached (immutable, prior versions retained), auto-shared to all participants across email, in-app, and SMS/WhatsApp per their preferences with acknowledgments tracked and reminders sent after a grace period. If the department has e-Office integration enabled, the MoM is cross-posted to NITB e-Office as an official file movement.

9. MoM States, Approval, Publish & Share

9.1 MoM states

The mom.status enum carries the canonical persisted state of every MoM. The lifecycle around it (upload → scan → store → OCR → extract → review → confirm → approve → publish → distribute → acknowledge) is a sequence of lifecycle phases that the status field summarises.

Lifecycle phases (not persisted as separate enum values, but tracked in audit_events and mom_history):

uploaded → av_scanned → stored → ocr_pending → ocr_done → extract_pending → extracted → review_pending → confirmed → approval_pending (sensitive) → approved → published → distributed → acknowledged (per recipient).

9.2 MoM state machine

Written description. An MoM is born in draft — created when a file is uploaded, a manual template is started, or a transcript arrives. It stays in draft through the AV scan, storage, OCR, AI extraction, and officer-review phases; any number of revisions during this window leave it in draft. When the officer has confirmed the extracted action items (and, for sensitive/VIP tickets, the Chair/DG has approved) the MoM moves to approved. The publish action then moves it to published, which is terminal and immutable: the MoM is permanently attached to the ticket, versioned, auto-shared, and its acknowledgment window opens. A published MoM can never return to draft; the only exit is the revised path, taken when a new version is published over it — the new version goes through the same draft → approved → published flow on its own row, and the prior version is flagged as superseded but otherwise retained verbatim.

9.3 Approval gate

Whether a MoM requires approval before publication depends on the ticket's sensitivity classification. The rule is the same one that governs the proof-of-resolution gate for sensitive/VIP tickets (/specs/en/06-ticket-workflow/ §7.3).

Each approval decision (approve / reject / changes-requested) writes a mom_approvals row with approver_user_id, decision, note, and decided_at, and an audit_events row. Approval routing is configurable per (department, ticket_classification) in mom_approval_config.

9.4 Publish & auto-share

On publish the system:

1. Persists the MoM as a versioned, immutable attachment. Every revision creates a new mom_documents version row; prior versions are retained and audit-logged, never overwritten. The MoM is permanently attached to the parent ticket and is visible in the ticket timeline.
2. Auto-shares to all participants — company reps, S&ITD facilitator, department attendees, and oversight watchers (for the audience appropriate to the meeting type; an internal MoM is not shared with the company). Each share writes a mom_distributions row. Channels:
   • Email with the MoM attached (or a secure, time-limited download link if the file is large).
   • In-app notification with a deep-link to the ticket and the MoM.
   • SMS short summary + link.
   • WhatsApp short summary + link.
   • Each channel's content is in the recipient's preferred locale (EN/UR/SD).
3. Cross-posts to NITB e-Office (module H) if the department has e-Office integration enabled, creating the corresponding official file movement.
4. Updates ticket-linked artefacts — confirmed action items created as sub-tasks are now visible on the ticket; the ticket status reflects the meeting outcome (§6.4).

9.5 Acknowledgment tracking

Each participant's acknowledgment is tracked against the published MoM in mom_acknowledgments:

Non-acknowledgment past a configurable grace (default 3 calendar days) triggers a reminder through the recipient's preferred channels; a second reminder fires at 7 days; non-acknowledgment beyond a configurable final window (default 14 days) is flagged in analytics (§14) and surfaced to the S&ITD facilitator.

9.6 Action items → sub-tasks

When the officer confirms an extracted action item, the system creates a ticket_subtasks row on the parent ticket:

• Each sub-task inherits a slice of the parent ticket's SLA (configurable; default = the action item's due date or the parent resolution SLA, whichever is sooner).
• Each sub-task has its own owner (resolved from the action item's owner/ownerType against the org chart where possible), due date, priority, and description.
• Each sub-task is individually resolvable; the parent ticket cannot reach Resolved until all sub-tasks are resolved or explicitly waived (proof-gate precondition in /specs/en/06-ticket-workflow/ §7.1).
• The extracted_action_items.subtask_id is set and extracted_action_items.status flips to converted, giving an end-to-end audit chain ticket → meeting → mom → ai_run → extracted_action_item → subtask.

10. Recording Consent

Before any audio or video recording of a meeting starts — physical (dedicated device) or virtual (provider-side) — the portal captures explicit consent from every attendee. Consent is stored in meeting_consent (per attendee: scope, timestamp, IP/device, withdrawal) and surfaced again at the start of the recording.

Consent capture is mandatory and enforced server-side: the recording-creation endpoint refuses to start without a complete consent set for all in-progress attendees.

11. Meeting States

The meetings.status enum carries four canonical states. Transitions are validated server-side and every transition emits an audit_events row.

11.1 Meeting state machine

Written description. A meeting is born scheduled when the organiser creates it and invitations go out; it may be rescheduled any number of times while scheduled. When the organiser starts the meeting (and quorum is met for TRI/hearings), it moves to in_progress. On end it moves to completed, at which point the MoM lifecycle (§8) takes over. From scheduled or in_progress the meeting can be moved to cancelled — by the organiser, by an oversight tier, or automatically when the parent ticket reaches a terminal state. Both completed and cancelled are terminal for the meeting record (the record is retained for audit); only the MoM lifecycle continues from completed.

12. Hearing Outcomes

For hearings (T4) the outcome recorded by the adjudicator at meeting end has a richer vocabulary than the general TRI outcome, because a hearing can produce binding decisions:

For non-hearing meeting types the outcome vocabulary is the general TRI set (resolved / further action items / escalate / adjourn — §6.4).

13. Notifications & Reminders

The Notification module (G) is the delivery substrate for all meeting- and MoM-related notifications. The event keys, channels, and templates are configurable in notification_templates per locale.

All notifications are templated, multilingual (EN/UR/SD), and respect each recipient's preference center (digest mode, quiet hours) per module G.

14. Multilingual OCR & Translation

MoMs in Sindh government use are often in Urdu (the official working language), frequently in Sindhi (the provincial language), and sometimes in English. The MoM pipeline is multilingual end-to-end:

• OCR supports all three languages, including Urdu Nastaliq and Sindhi Naskh scripts, through the pluggable OCR engine (/specs/en/07-ai-ocr-spec/ §3.2). Low-confidence spans are routed to the OCR review queue for human correction before AI extraction.
• AI extraction accepts any source locale and produces structured output (summary, action items, decisions) tagged with source_locale.
• Translation produces parallel text in all three locales (mom.body_en, mom.body_ur, mom.body_sd) using the LLM-based translator with glossary injection (/specs/en/07-ai-ocr-spec/ §3.4, §4.6). Official-legal MoM text (hearing orders, binding decisions) requires human review of the translation before publication.
• RTL rendering for Urdu and Sindhi is handled by the renderer (Docusaurus locale for docs; Next.js locale for the portal UI); no inline direction hacks in stored content.
• Dates are preserved in both Gregorian and Hijri (where present); the LLM is instructed never to silently convert Hijri dates (/specs/en/07-ai-ocr-spec/ §4.11).
• Glossary adherence is 100% enforced: government-terms mappings from _glossary.md are injected into every translation prompt and the output is validated against them.

15. Data Model Recap

The Module-M tables are defined canonically in /specs/en/05-data-model/ §4.9. This section recaps the entity set, relationships, and the two schema deltas this document requires of the data model.

15.1 Entity set

15.2 Schema deltas (this document requires)

1. meetings.type enum extension. The current enum ('tri','hearing','internal') must be extended to cover all five types in §2. Proposed: ('tri','hearing','internal','company_direct','site_visit'). Add a subtype VARCHAR(48) NULL discriminator for further classification (e.g. "adjudication" under hearing, "internal_briefing" under internal). See doc 05 §4.9.
2. meeting_consent new table. Columns: id PK, meeting_id FK, user_id FK, scope ENUM('audio','audio_video','transcript'), granted TINYINT(1), captured_at DATETIME(6), withdrawn_at DATETIME(6) NULL, device_fingerprint VARCHAR(255). Unique on (meeting_id, user_id, scope). Required by §10.

These deltas are noted here as the authoritative Module-M requirement; the canonical DDL lives in /specs/en/05-data-model/ and should be updated to match.

15.3 Entity relationships

Written description. A tickets row triggers zero or more meetings. Each meeting has many attendees (internal users linked via users, external recorded by name), produces exactly one mom (1:1), may have several meeting_recordings (one per recording scope), and captures per-attendee meeting_consent for any recording. The mom is gated by zero or more mom_approvals (present only when the ticket is sensitive/VIP), shared via many mom_distributions (one per channel per recipient), and acknowledged via mom_acknowledgments. AI extraction of the MoM's source yields many extracted_action_items, each of which converts to at most one ticket_subtask on officer confirmation. All binary content (MoM source file, recording blob, recording transcript) is stored as media_library rows in MinIO with encryption at rest, referenced by foreign key from the content tables.

16. Analytics

Module-M analytics feed the Analytics module (I) and the dashboards defined in /specs/en/17-analytics-kpis/. The metric families specific to meetings and MoM:

All metrics are sliced by department, category, locale, and time window, and are exported via the Analytics module's standard export channels (PDF/Excel/CSV) and surfaced in scheduled digests.

17. Functional Requirements

18. Non-Functional Requirements

19. User Stories

US-MTG-001 — Request a TRI meeting from a stalled ticket [Must]

As a Company Representative (Primary/Admin) I want to click "Request TRI meeting" on my stalled ticket and have S&ITD convene Company + S&ITD + Department in one meeting So that my issue is unblocked without me having to chase each party separately.

Acceptance Criteria (Gherkin)

Scenario: Company requests TRI on an escalated ticket
  Given a ticket owned by me is in status Escalated at tier 2
  And I am the Primary Authorized Rep for the filing company
  When I click "Request TRI meeting" and confirm
  Then a meetings row of type "tri" is created and linked to the ticket
  And the ticket status moves to On Hold with reason "TRI meeting requested"
  And the S&ITD facilitator is notified to convene
  And an audit event "meeting.requested" is recorded

Scenario: Sensitive ticket requires convening approval
  Given the ticket is flagged sensitive = true
  When I request a TRI meeting
  Then the request routes to the Chair/DG approval queue
  And no invitations are sent until approval is granted

US-MTG-002 — Upload the MoM in my department's own format [Must]

As a Department Officer (note-taker) I want to upload the MoM as a PDF/Word/scan in my department's own template So that I do not have to re-format our official minutes into a portal template.

Acceptance Criteria (Gherkin)

Scenario: Successful upload of a scanned MoM
  Given a meeting of any type has status completed and no MoM yet
  When I upload a scanned PDF of the department's MoM
  Then ClamAV scans the file and, on clean, encrypts and stores it
  And a mom row is created with status draft and source_media_id set
  And OCR runs in EN/UR/Sindhi producing a text layer
  And the AI extracts summary, action items, decisions, and attendees
  And extracted_action_items rows are created for officer review

US-MTG-003 — Confirm extracted action items into sub-tasks [Must]

As a Department Officer I want to review the AI-extracted action items side-by-side with the original MoM and confirm the correct ones So that only accurate commitments become ticket sub-tasks.

Acceptance Criteria (Gherkin)

Scenario: Confirm a correctly extracted action item
  Given an extracted_action_item exists with owner "Company Primary Rep" and due date "2026-08-15"
  When I review it side-by-side, correct a typo, and click Confirm
  Then a ticket_subtask is created on the parent ticket with the corrected owner, due date, priority
  And the extracted_action_item.status flips to "converted" and subtask_id is set
  And an audit event records the confirmation

Scenario: Reject a false-positive extraction
  Given an extracted_action_item is in fact a general statement, not a commitment
  When I delete it from the review list
  Then no sub-task is created
  And the item is marked rejected with the officer as actor

US-MTG-004 — Publish a sensitive MoM with Chair/DG approval [Must]

As a S&ITD Facilitator I want the MoM of a sensitive ticket to require Chair/DG approval before it is shared So that sensitive content is reviewed by an accountable authority before it reaches the company.

Acceptance Criteria (Gherkin)

Scenario: Sensitive MoM routed to approval queue
  Given the parent ticket is sensitive = true
  And the officer has confirmed all extracted action items
  When the MoM is submitted for publish
  Then its status stays draft and a mom_approvals row is created pending
  And the Chair/DG approval queue is notified
  And no auto-share occurs

Scenario: Approval granted then published
  Given a sensitive MoM is pending approval
  When the Chair approves it
  Then the mom.status moves to approved then published
  And auto-share fans out to all participants per §9.4
  And mom_distributions rows are written for each channel/recipient

US-MTG-005 — Receive and acknowledge the MoM in my language [Must]

As a Company Representative I want to receive the published MoM in my preferred language and acknowledge it So that I have an authoritative record of what was agreed and the system tracks that I received it.

Acceptance Criteria (Gherkin)

Scenario: Acknowledge a published MoM
  Given a MoM for a meeting I attended has been published
  When I receive the in-app notification and click through to the MoM
  Then the MoM is rendered in my preferred locale (EN/UR/SD)
  And my open is recorded as an acknowledgment of type "opened"
  And when I click "I acknowledge" an "explicit_ack" row is written
  And no further reminders are sent to me

20. Test Cases (reference)

21. Feature Flags

Flags are stored in feature_flags (see /specs/en/05-data-model/ §4) and administered by Super Admin per (department, environment) per module Q.

22. Configuration Matrix

23. Cross-References

• _context.md §5 — locked decisions on MoM upload-first, TRI tripartite, approval only for sensitive/VIP, auto-share.
• /specs/en/05-data-model/ §4.9 — canonical schema for meetings, meeting_attendees, mom, mom_approvals, mom_distributions, mom_acknowledgments, meeting_recordings, extracted_action_items.
• /specs/en/06-ticket-workflow/ §9–§10 — TRI and MoM summary in the ticket lifecycle; §7 proof-of-resolution gate; §7.3 sensitive/VIP closure approval.
• /specs/en/07-ai-ocr-spec/ §3.2 — OCR engines; §4.1 OCR capability; §4.6 translation; §4.11 mom_extract capability with the canonical prompt template and success metrics.
• /specs/en/04-roles-permissions/ — RBAC for who may request, convene, attend, upload, approve, publish, and acknowledge.
• /specs/en/11-security-compliance/ — encryption at rest, retention, consent handling, audit logging.
• /specs/en/15-tech-architecture/ §9 — ClamAV scan pipeline; MinIO object storage.
• /specs/en/17-analytics-kpis/ — analytics dashboards consuming Module-M metrics.
• _glossary.md — trilingual term dictionary for MoM, TRI, hearing, facilitator, etc.

24. Open Questions