meeting-assistant/docs/adr/0012-post-run-corrections.md

ADR 0012: Preserve Corrections as Post-Run Knowledge

Status

Accepted as a future product direction; not required for the current MVP.

Context

Real-meeting review exposes corrections that should not require repeating expensive processing. These include misspelled or recurring name variants, people mentioned but omitted from the initial Meeting Context, and confirmed SPEAKER_XX -> participant_id mappings. A destructive edit would lose useful provenance, while rerunning Whisper or diarization would add cost without improving a deterministic correction.

The product is also expected to provide both a detailed contextual protocol and a short participant/distribution protocol. Both should eventually use the same confirmed context and corrections.

Decision

Original machine-generated artifacts remain immutable. Corrected or reviewed artifacts are separate derivatives. Human corrections should evolve into structured, meeting-specific knowledge rather than opaque destructive edits; the correction schema is deliberately not defined by this ADR.

An early correction tool may be simple deterministic search and replace, for example Grossman to Herr Grossmann. Applying such a confirmed correction to a suitable editable artifact requires neither Whisper, diarization nor an LLM call.

A later review stage may run after diarization or the complete initial run. It may propose likely person/name matches, allow addition of previously omitted mentioned people, and present anonymous speaker mappings for review. Every suggestion is non-authoritative: anonymous labels remain anonymous until the user explicitly confirms or corrects them, and mentioned_only people cannot be mapped as speakers.

After confirmation, the product should offer two paths:

1. A fast path applies confirmed speaker, name or text corrections deterministically where that is semantically safe.
2. A quality path regenerates protocol output using the existing transcription, existing diarization, corrected Meeting Context and confirmed mappings or corrections. It reruns protocol generation only. Whisper and diarization run again only when separately requested or technically necessary.

The likely later workflow is therefore:

Audio -> transcription -> optional diarization -> initial protocol
      -> name/person/speaker review -> human confirmation
      -> deterministic correction or protocol-only regeneration
      -> final reviewed detailed and/or distribution protocol

The exact ordering may evolve, and this review stage is not mandatory for the current Streamlit MVP.

Consequences

• Human knowledge can improve outputs without unnecessary upstream work.
• Provenance is retained because originals and corrected derivatives coexist.
• Correction data can later be reused consistently across detailed and short protocol views.
• Search/replace, correction storage, review UI, identity suggestions and protocol-only rerun controls remain future implementation work.