Document evidence and commitment model

2026-08-11 14:19:19 +02:00
parent fd7d5e1424
commit c2b7b6b4d2
3 changed files with 525 additions and 3 deletions
@@ -2,13 +2,63 @@

 ## Purpose

-The **Meeting Lab** is an experimental environment for developing and evaluating methods to extract structured knowledge from real meeting transcripts.
+The **Meeting Lab** is the experimental R&D environment for developing and
+evaluating methods to extract structured knowledge from real meeting
+transcripts. It is the research platform, architecture playground, regression
+framework, benchmark environment and prototype implementation for the future
+Meeting Assistant.

 Its purpose is not to build a complete meeting assistant, but to answer a single question:

 > **How can knowledge be extracted from real discussions as reliably as possible?**

-Successful approaches will later be integrated into the Meeting Assistant project.
+Its purpose is to validate ideas before they are promoted into the product.
+Only sufficiently mature and verified components should migrate into Meeting
+Assistant. Meeting Lab may intentionally contain experiments or development
+branches that are rejected, remain inconclusive or never reach the Assistant.
+
+## Meeting Lab and Meeting Assistant lifecycle
+
+Meeting Lab and Meeting Assistant have different long-term responsibilities:
+
+- **Meeting Lab** is the long-term innovation branch. It favors learning,
+  inspectable experiments, regression evidence, benchmarks and architectural
+  change.
+- **Meeting Assistant** is the stable product branch. It favors a polished user
+  experience, installation, configuration and a production pipeline.
+
+Architectural promotion follows an evidence-based lifecycle:
+
+```text
+Research idea
+    ->
+Meeting Lab experiment
+    ->
+Regression tests
+    ->
+Stable architecture
+    ->
+Meeting Assistant implementation
+```
+
+The expected release progression is:
+
+```text
+Meeting Lab Alpha
+    ->
+Meeting Lab Beta
+    ->
+Meeting Assistant Beta
+    ->
+Meeting Assistant Release
+```
+
+The first public Meeting Assistant beta should be based on a stable Meeting
+Lab MVP. It should provide a polished user experience, an installer,
+configuration and a production-quality pipeline. A GUI is optional.
+Experimental features should not be enabled by default. Meeting Lab continues
+to evolve independently after components have migrated; promotion does not
+turn the Lab itself into the product branch.

 ---

@@ -356,6 +406,127 @@ The architecture document only describes the overall system.

 ---

+# Version 2 Accepted Architectural Direction
+
+The following topics are accepted architectural goals for Version 2. They
+record direction reached through the BUG-011 through BUG-015 investigations;
+they are not descriptions of implemented behavior or authorization to change
+the current pipeline.
+
+## Speaker diarization before semantic analysis
+
+Version 2 should determine **who is speaking before semantic analysis**.
+Speaker identity contains evidence that cannot reliably be reconstructed from
+text alone. It helps distinguish, for example, who answers a question, accepts
+work, agrees with a proposal, or advances the discussion after another
+speaker. It also preserves conversational flow that anonymous transcript text
+can erase.
+
+Diarization is therefore a semantic prerequisite in the intended Version 2
+architecture, not merely a display enhancement. Its output should remain
+traceable to transcript segments so later stages can preserve speaker and
+source provenance.
+
+## Persistent speaker identification
+
+Version 2 should add a persistent speaker database and an interactive identity
+workflow during import:
+
+```text
+Unknown speaker detected
+    ->
+Representative audio sample (approximately 20 seconds)
+    ->
+User selects an existing identity or creates a new identity
+    ->
+Known speaker available for future recognition
+```
+
+Automatic recognition may suggest an identity, but user confirmation governs
+the persistent association. Over the long term, speaker embeddings rather
+than raw meeting recordings should be the persistent recognition
+representation. Representative raw audio is an import and confirmation aid,
+not the intended durable identity store. Privacy, deletion and false-match
+handling require separate design before implementation.
+
+## Meeting Context as a probabilistic prior
+
+Known meeting participants should influence semantic interpretation, but
+Meeting Context is a **probabilistic prior**, not a deterministic semantic
+rule. It can make one interpretation more plausible and help focus review; it
+must never manufacture a commitment, decision or responsibility assignment.
+
+For example, if Marleen is confirmed as present, “Marleen müsste sich mal
+äußern” is more likely to be conversation management directed at a current
+participant than future project work. Presence alone does not prove this
+interpretation, and it does not establish an Action Item or responsibility.
+Explicit meeting evidence remains authoritative. This extends, rather than
+weakens, the responsibility attribution invariant.
+
+The existing Meeting Context V2 entity direction is documented in
+[`adr-meeting-context-v2-entity-registry.md`](adr-meeting-context-v2-entity-registry.md).
+Speaker identities and meeting-specific participant confirmation should
+eventually feed that context without turning registry metadata into semantic
+facts.
+
+## Conversation Management versus Meeting Content
+
+BUG-015 reinforced that not every utterance is protocol-worthy content.
+Version 2 should conceptually distinguish:
+
+- **Conversation Management**: utterances that coordinate the meeting itself,
+  such as asking a present participant to speak, moderation, requesting a
+  slide, or asking someone to repeat something.
+- **Meeting Content**: propositions that may contribute to the meeting's
+  durable knowledge, including facts, technical findings, decisions, action
+  items and open questions.
+
+This is an architectural concept, not a currently implemented category or
+filter. The distinction should prevent conversational coordination from being
+promoted into project commitments while retaining sufficient provenance to
+understand dialogue. Context and diarization can inform the distinction, but
+neither should act as a deterministic keyword or participant rule.
+
+## Evidence and commitment before protocol eligibility
+
+The BUG-015 design study concludes that semantic state should be classified
+before policy determines whether an item is eligible for a protocol. A binary
+keep/reject verifier conflates evidence recognition with publication policy
+and loses valid intermediate states.
+
+The proposed decision progression is:
+
+```text
+idea -> option -> proposal -> preferred option -> tentative agreement -> decision
+```
+
+The proposed action progression is:
+
+```text
+possible next step -> recommendation -> requested action
+    -> established action -> ongoing work -> completed
+```
+
+Questions combine a communicative **kind** with an independent **resolution
+state**, rather than treating every uncertainty or interrogative as an Open
+Question. Responsibility remains an independent dimension and may be recorded
+only when explicitly assigned, accepted or confirmed. Evidence strength is
+also independent: it describes support for a semantic label, not semantic
+maturity or protocol eligibility.
+
+After semantic state classification, explicit policy should select Decisions,
+Action Items and Open Questions for a particular output view. Renderers should
+receive policy-selected semantic content and must not promote proposals or
+conversation management into commitments. The complete taxonomy, trade-offs,
+architecture interactions and migration questions are recorded in
+[`design/evidence_commitment_model.md`](design/evidence_commitment_model.md).
+
+Implementation is intentionally postponed until this architecture has been
+reviewed. No Version 2 goal in this section changes current extraction,
+canonicalization, consolidation or rendering behavior.
+
+---
+
 # Current State

 Implemented:
@@ -389,6 +560,22 @@ Action Item may have no known owner, while a named owner requires explicit
 assignment, volunteering or acceptance. These are semantic LLM classifications;
 deterministic validation must not guess intent from keywords.

+### Classification Verifier
+
+Before extraction output is normalized for Canonicalizer input, Decision,
+Action Item and Open Question candidates pass through a semantic precision
+gate. Facts and technical details pass through unchanged. Each candidate is
+reviewed independently with its evidence and bounded local chunk context; the
+verifier may only keep or reject the existing candidate. It cannot add or
+rewrite semantic items.
+
+Verifier output contains the stable candidate ID, category, `keep|reject`
+verdict, evidence-based reason and `responsibility_supported`. A kept Action
+Item with an unsupported named owner is retained with its responsibility
+cleared. Malformed output fails the extraction verification substage closed,
+after preserving candidate input and raw response. Per-candidate results and an
+aggregate audit remain traceable before Canonicalizer input is written.
+
 ## Semantic Consolidator failure handling

 Semantic Consolidator V0 preserves every raw model response before parsing.