Project Knowledge

Vision

Meeting Assistant turns recorded meetings into reviewed, user-facing protocols and, over time, searchable organizational knowledge. It is the application layer over the reusable Meeting Lab processing backend.

The source audio and canonical transcript are preserved. Generated protocols are derived, reproducible artifacts and require human review.

System Boundary

Meeting Lab

Meeting Lab owns reusable and experimental processing:

FFmpeg audio preparation, with optional normalization enabled by default
whisper.cpp transcription
optional pyannote.audio diarization
protocol generation
pipeline orchestration and progress events

Its reusable integration surface is the Python API:

MvpMeetingConfig
MvpRunResult
run_mvp_meeting(...)

The CLI is a thin adapter, not the Meeting Assistant integration boundary.

Meeting Assistant

Meeting Assistant owns user interaction and product workflow:

audio-file selection
structured Meeting Context editing
participant management
versioned YAML import/export for reusable People lists, using replace semantics
optional explicit speaker mapping
pipeline launch and progress display
protocol review and editing
export and presentation of protocol versions

Processing logic must not be duplicated in the application.

Diarization runtime, container image and ordered container arguments are machine configuration. MKA_DIARIZATION_CONTAINER_ARGS is a JSON array of strings forwarded unchanged to Meeting Lab; these details are not normal UI controls.

People-list YAML is a Meeting Assistant application concern and contains only stable IDs, display names, roles, organizations and attendance states. It does not contain meeting metadata or processing settings. Named team or meeting templates may build on this later, but are not part of the current mechanism.

Validated MVP Pipeline

Imported audio
    -> always prepare as mono, 16 kHz PCM WAV with FFmpeg
       (optionally normalize loudness; default on)
    -> transcribe with whisper.cpp and large-v3-turbo
    -> optionally diarize with pyannote.audio Community-1
    -> generate a protocol directly from the full transcript
    -> review and edit by a human

Mandatory fixed five-minute chunking is not part of the productive MVP path. Chunking or segmentation used internally by an engine does not shape the Meeting Assistant storage or domain model.

On the North reference machine, whisper.cpp with Vulkan on an AMD RX 9070 transcribed approximately 93.5 minutes in about 100 seconds. Pyannote through PyTorch/ROCm processed the same duration in approximately 98.6 seconds. These are validation observations, not performance guarantees or hardware requirements. CPU execution remains supported and may be substantially slower.

Meeting Context and Speakers

MeetingContext is a structured domain object containing meeting metadata, present participants, and people who were mentioned without attending. The GUI records exactly present or mentioned_only; missing legacy participant status defaults to present in Meeting Lab. It can also contain optional explicit mappings from SPEAKER_XX labels to participant_id values.

A speaker mapping is authoritative only when a user explicitly confirms it and may reference only a present participant. Speakers otherwise remain anonymous. Automatic speaker-name inference is not allowed. The GUI must create and edit Meeting Context; hand-written YAML is not a product requirement.

Progress Contract

Meeting Lab emits stage-based progress events for:

preparing
transcription
diarization
protocol_generation
completed
failed

The GUI consumes this event interface. Percentages are shown only when real measurable progress is available.

Protocol Policy

Direct full-transcript protocol generation is the practical MVP direction. qwen3.8:27B has shown strong readability and contextual synthesis; qwen3.6:35B-A3B has shown somewhat more conservative behavior in some areas. Experimental dual-model and diarization-assisted hard-fact extraction has not demonstrated reliably better strict attribution accuracy and is not mandatory.

The product should ultimately offer both a detailed contextual protocol and a shorter participant/distribution version. The short version remains follow-up work if it is not available for the first GUI milestone.

Confirmed meeting-specific corrections should ultimately be reusable by both protocol views. The detailed correction and selective-regeneration decision is recorded in ADR 0012; it is later product work, not a current MVP requirement.

Design Principles

offline-first where practical
explicit application/backend boundaries
replaceable AI components
CPU-compatible operation with optional acceleration
immutable source artifacts and traceable derived artifacts
no automatic identity claims
human review of generated protocols
small modules and simple interfaces

5.0 KiB Raw Blame History