123 lines
4.3 KiB
Markdown
123 lines
4.3 KiB
Markdown
# 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
|
|
- 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.
|
|
|
|
## Validated MVP Pipeline
|
|
|
|
```text
|
|
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](docs/adr/0012-post-run-corrections.md); 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
|