meeting-assistant/openspec/changes/unify-pyannote-validation-toggle/specs/meeting-transcription/spec.md

MODIFIED Requirements

Requirement: Speaker identity matching can use pyannote secondary validation

Meeting Assistant SHALL support an optional configurable pyannote secondary validation layer for speaker identity matching.

SpeakerIdentification:PyannoteValidation:Enabled SHALL be the only enable setting for speaker identity pyannote validation. The nested pyannote runtime settings SHALL NOT expose or honor a second enable setting.

Speaker identity pyannote validation SHALL use the application-level setting consistently for matching and startup warm-up. Launch profiles SHALL NOT override this validation setting or its runtime configuration.

When pyannote secondary validation is enabled, Meeting Assistant SHALL verify candidate speaker samples before retaining them for identity matching. Samples that pyannote reports as containing multiple speakers SHALL be rejected.

When pyannote secondary validation is enabled, Meeting Assistant SHALL verify speaker-override samples before retaining them on speaker identities. Speaker overrides whose source samples are rejected SHALL NOT create a new speaker identity from that rejected sample.

When pyannote secondary validation is enabled and the primary identity matcher confirms a speaker, Meeting Assistant SHALL run a second validation pass through pyannote before accepting the match.

If pyannote secondary validation cannot confirm that the unknown live sample and matched identity samples belong to one speaker, Meeting Assistant SHALL reject the match.

When pyannote secondary validation is disabled, Meeting Assistant SHALL preserve the primary identity matching behavior.

When pyannote secondary validation is enabled, Meeting Assistant SHALL start a non-blocking startup warm-up that builds or verifies the configured pyannote runtime image and downloads the configured model into the persistent model cache before the first validation request when possible.

Scenario: Multi-speaker sample is rejected

• GIVEN pyannote secondary validation is enabled
• WHEN pyannote reports multiple speakers in a candidate sample
• THEN Meeting Assistant does not retain that sample for identity matching

Scenario: Multi-speaker speaker-override sample is rejected

• GIVEN pyannote secondary validation is enabled
• WHEN a summary speaker override resolves a source sample that pyannote reports as containing multiple speakers
• THEN Meeting Assistant does not retain that sample on a speaker identity
• AND does not create a new speaker identity from that rejected sample

Scenario: Pyannote rejects primary match

• GIVEN pyannote secondary validation is enabled
• AND the primary identity matcher confirms Guest03 as Chris
• WHEN pyannote reports that the unknown Guest03 sample and known Chris samples contain different speakers
• THEN Meeting Assistant rejects the match

Scenario: Enabled pyannote validation invokes its runtime

• GIVEN speaker identity pyannote validation is enabled
• WHEN Meeting Assistant validates a readable speaker sample
• THEN it invokes the configured pyannote runtime without requiring another enable setting

Scenario: Launch profile cannot override speaker validation

• GIVEN application-level speaker identity pyannote validation is disabled
• AND a named launch profile contains different speaker-validation settings
• WHEN Meeting Assistant starts or matches a speaker for that profile
• THEN it keeps application-level validation disabled
• AND does not warm or invoke the named profile's speaker-validation runtime

Scenario: Disabled pyannote validation preserves primary match

• GIVEN pyannote secondary validation is disabled
• WHEN the primary identity matcher confirms Guest03 as Chris
• THEN Meeting Assistant accepts the match without running pyannote secondary validation

Scenario: Pyannote validation warms up on startup

• GIVEN pyannote secondary validation is enabled
• WHEN Meeting Assistant starts
• THEN it begins preparing the configured pyannote runtime image and model cache without waiting for the first validation request
• AND application startup is not blocked by the warm-up task