# ADR: Meeting Context V2 and Entity Registry

Status: Accepted Architecture

Implementation: Deferred

Date: 2026-08-03

## Context

Meeting Context V1 proved that authoritative meeting context can significantly
improve extraction quality. It helps the extractor normalize known aliases,
identify participants and avoid treating context metadata as evidence for
responsibility or decisions.

End-to-end evaluation also showed that manually writing Meeting Context is not
the right long-term primary workflow. The pipeline needs an earlier,
interactive entity confirmation step after Whisper transcription. That step
should identify candidate entities, ask the user to confirm them and then build
the meeting-specific context from confirmed data.

## Decision

Meeting Context should evolve toward V2 as an authoritative,
meeting-specific Point of Truth generated or assisted from a persistent Entity
Registry, user confirmations and meeting metadata.

Preferred future pipeline:

```text
Whisper
    ↓
Entity Detection
    ↓
User Confirmation
    ↓
Entity Registry Update
    ↓
Meeting Context Builder
    ↓
meeting_context.yaml
    ↓
Extraction Pipeline
```

The Entity Registry is the persistent cross-meeting knowledge source for
confirmed entities, aliases and organizational metadata.

For each individual meeting, `meeting_context.yaml` remains the authoritative
meeting-specific Point of Truth and reproducible input artifact consumed by
the extraction pipeline. Meeting Context V2 changes how this YAML is prepared,
not its authority for a meeting run.

The generated `meeting_context.yaml` is a meeting-specific snapshot. The
Registry must not override explicit meeting-specific confirmations. Changes to
the Registry after a meeting run must not silently change the historical
Meeting Context used for that run.

## Entity Registry

The Entity Registry is the persistent cross-meeting knowledge source and is
independent from individual meetings. It stores confirmed entities such as:

- people
- organizations
- departments
- products
- projects
- locations
- abbreviations

Each entity receives a stable internal identifier. The displayed name may
change over time, but the identifier must remain stable.

## Learning Principle

The registry never learns automatically.

It may propose matches, but only confirmed user actions update the registry.
No autonomous learning is allowed.

## Alias Handling

Aliases are first-class data.

Examples:

```text
Jovana
Giovanna
Jovanna
Giovana
```

These variants may all refer to one confirmed entity. Future runs should
automatically suggest previously confirmed aliases, but those suggestions still
require explicit confirmation when they would update registry data.

## Unknown Entities

Previously unseen names are presented to the user for classification.

Possible classifications:

- meeting participant
- mentioned person
- external person
- transcription error
- ignore

Nothing is automatically accepted.

## Similarity Search

Similarity search is a future extension. It can propose likely matches for:

- spelling variants
- Whisper transcription variants
- umlaut handling
- OCR-like mistakes

Similarity suggestions require explicit confirmation.

## Rationale

Expected advantages:

- significantly less manual work
- earlier detection of transcription errors
- robust alias handling
- reusable organizational knowledge
- improved Meeting Context quality
- easier GUI workflow
- better scalability across many meetings

## Consequences

Meeting Context V1 remains the current implemented interface.

Meeting Context V2 should preserve the YAML interface for extraction.
`meeting_context.yaml` remains the authoritative meeting-specific Point of
Truth and reproducible input artifact for a meeting run. The Entity Registry is
the persistent cross-meeting knowledge source used to prepare that artifact.

The Registry must not override explicit meeting-specific confirmations. Changes
to the Registry after a meeting run must not silently change the historical
Meeting Context used for that run.

The registry must not infer responsibility, decisions, attendance or ownership.
Those still require meeting evidence and remain governed by the existing
responsibility attribution invariant.

No implementation is part of this ADR.