Refine canonical meeting knowledge architecture

- establish Canonical Meeting Knowledge as the semantic source of truth
- introduce Output View Rendering architecture
- define Working Protocol, Distribution Protocol and Knowledge Objects as parallel renderers
- document renderer responsibilities and terminology
- clarify future Knowledge Object architecture
- document long-term reuse for enterprise knowledge systems

README.md

@@ -43,7 +43,9 @@ Extraktion
     ↓
 Konsolidierung
     ↓
-Protokoll
+Canonical Meeting Knowledge
+    ↓
+Arbeitsprotokoll / Verteilerprotokoll / Knowledge Objects
 ```
 
 Jeder Verarbeitungsschritt löst genau eine klar definierte Aufgabe.
@@ -89,21 +91,43 @@ chunk_transcript.py
     ↓
 Extraktoren
     ↓
-Protokoll
+Canonical Meeting Knowledge
+    ↓
+Output-Ansichten
 ```
 
 Die Themensegmentierung bildet den nächsten großen Entwicklungsschritt.
 
+Das Meeting Lab behandelt "das Protokoll" nicht mehr als ein einzelnes
+Endprodukt. Das konsolidierte Meeting-Wissen ist die **Canonical Meeting
+Knowledge**, also die kanonische semantische Repräsentation eines Meetings und
+die Single Source of Truth für alle nachgelagerten Ausgaben.
+
+Aus dieser Canonical Meeting Knowledge entstehen drei unabhängige
+Output-Ansichten:
+
+- Working Protocol (`working_protocol.md`, Arbeitsprotokoll): relativ vollständig, mit Kontext,
+  Begründungen, Entscheidungen, Aufgaben und offenen Fragen.
+- Distribution Protocol (`distribution_protocol.md`, Verteilerprotokoll): deutlich kürzer,
+  ergebnisorientiert und für Kolleginnen, Management oder Stakeholder geeignet.
+- Knowledge Objects, dargestellt zum Beispiel als Knowledge-base Entry
+  (`knowledge_entry.md`) oder später strukturiert gespeichert, zum Beispiel als
+  `knowledge_entry.json` (Wissensdatenbankeintrag).
+
+Diese Ausgaben sind parallele Renderings desselben semantischen Modells. Das
+Arbeitsprotokoll ist nicht die Quelle des Verteilerprotokolls, und das
+Verteilerprotokoll ist nicht die Quelle der Knowledge Objects.
+
 ---
 
 ## Projektstatus
 
 Aktuell liegt der Schwerpunkt auf der Entwicklung eines modularen Diskussionsanalyzers.
 
-Die eigentliche Protokollerstellung ist bewusst der letzte Verarbeitungsschritt.
+Die eigentliche Ausgabeerzeugung ist bewusst der letzte Verarbeitungsschritt.
 
 ---
 
 ## Lizenz
 
-Noch nicht festgelegt.
+Noch nicht festgelegt.

docs/architecture.md

@@ -100,9 +100,11 @@ Specialized Extraction
     ↓
 Consolidation
     ↓
-Structured Meeting Data
+Canonical Meeting Knowledge
     ↓
-Protocol Generation
+Output View Rendering
+    ↓
+Working Protocol / Distribution Protocol / Knowledge Objects
 ```
 
 Each stage solves one clearly defined problem.
@@ -185,11 +187,25 @@ Typical responsibilities:
 
 ## protocol/
 
-Generates human-readable output from structured meeting data.
+Generates output views from Canonical Meeting Knowledge.
 
-Protocol generation never invents information.
+Output generation never invents information.
 
-It only reformulates the analysis results.
+It only reformulates the analysis results for a specific audience and purpose.
+Depending on the output and maturity of the implementation, a renderer may be
+deterministic, template-based or LLM-assisted.
+
+The planned output products are:
+
+- Working Protocol (`working_protocol.md`, Arbeitsprotokoll)
+- Distribution Protocol (`distribution_protocol.md`,
+  Verteilerprotokoll)
+- Knowledge Objects, which may be rendered as a Knowledge-base Entry
+  (`knowledge_entry.md`) and later stored in a structured format such as
+  `knowledge_entry.json` (Wissensdatenbankeintrag)
+
+These are parallel renderings of the same canonical semantic model, not
+documents derived from one another.
 
 ---
 
@@ -214,6 +230,7 @@ Examples:
 - segmentation.md
 - prompts.md
 - experiments.md
+- output-views.md
 
 The architecture document only describes the overall system.
 
@@ -231,6 +248,11 @@ The current extraction step still performs multiple tasks simultaneously.
 
 This was sufficient as a proof of concept but does not reflect the intended long-term architecture.
 
+The current protocol builder is also an interim implementation. It concatenates
+extraction results into `meeting_protocol.md` for technical validation. The
+planned architecture separates Canonical Meeting Knowledge from the final Output
+Views documented in `output-views.md`.
+
 ---
 
 # Next Milestone
@@ -256,4 +278,4 @@ Only after reliable topic segmentation has been achieved will the specialized ex
 
 The Meeting Lab assumes that the greatest improvement in transcript quality will not come from increasingly powerful language models.
 
-Instead, quality is expected to emerge from a pipeline that decomposes a complex problem into many small, clearly defined and independently testable processing steps.
+Instead, quality is expected to emerge from a pipeline that decomposes a complex problem into many small, clearly defined and independently testable processing steps.

docs/data-models.md

@@ -238,23 +238,60 @@ After extraction, every topic contains the collected information.
 }
 ```
 
-This object represents the main output of the analysis pipeline.
+This object feeds the Canonical Meeting Knowledge representation.
 
 ---
 
-# Meeting Result
+# Canonical Meeting Knowledge
 
-The complete structured meeting.
+The canonical semantic representation of one meeting.
+
+This representation is the single source of truth for all downstream outputs.
 
 ```json
 {
     "meeting_id": "meeting_001",
 
-    "topics": []
+    "metadata": {},
+    "topics": [],
+    "facts": [],
+    "decisions": [],
+    "todos": [],
+    "questions": [],
+    "positions": [],
+    "technical_details": [],
+    "rationale": [],
+    "uncertainty": [],
+    "source_references": []
 }
 ```
 
-Protocol generation operates exclusively on this structure.
+This is the common intermediate representation for all final Output Views.
+The exact schema is not final and should be refined during future
+implementation work.
+
+---
+
+# Output Views
+
+The final outputs are independent renderings of the Canonical Meeting Knowledge.
+
+```text
+Canonical Meeting Knowledge
+    ├── Working Protocol
+    ├── Distribution Protocol
+    └── Knowledge Objects
+```
+
+The Working Protocol, Distribution Protocol and Knowledge Objects are not
+derived from one another. Each renderer reads the same canonical semantic
+model and selects the level of detail appropriate for its purpose.
+
+Knowledge Objects represent durable organizational knowledge such as processes,
+definitions, responsibilities, rules, accepted practices and long-term
+decisions. They are independent of the original meeting wording. Markdown is one
+possible presentation, but JSON or another structured format is expected to
+become the canonical storage format later.
 
 ---
 
@@ -272,4 +309,4 @@ Possible future additions include:
 
 These fields will only be introduced when they provide measurable benefits.
 
-The Meeting Lab intentionally avoids designing an overly complex schema in advance.
+The Meeting Lab intentionally avoids designing an overly complex schema in advance.

docs/output-views.md

@@ -0,0 +1,185 @@
+# Output Views
+
+The Meeting Lab does not treat "the protocol" as one single final output.
+
+Canonical Meeting Knowledge is the canonical semantic representation of one
+meeting. It is the single source of truth for all downstream outputs.
+
+The three output products are independent renderings of this shared semantic
+model:
+
+```text
+Meeting transcript
+    ->
+chunk extraction
+    ->
+Canonical Meeting Knowledge
+    ├── Working Protocol
+    ├── Distribution Protocol
+    └── Knowledge Objects
+```
+
+The Working Protocol is not the source of the Distribution Protocol. The
+Distribution Protocol is not the source of the Knowledge-base Entry or future
+Knowledge Objects.
+
+## Common Intermediate Representation
+
+The common intermediate representation is Canonical Meeting Knowledge.
+
+It should conceptually include:
+
+- meeting metadata
+- topics
+- facts
+- decisions
+- action items
+- open questions
+- positions
+- technical information
+- rationale and discussion context
+- contradictions or uncertainty
+- source references and evidence
+
+The detailed schema is future implementation work. The current implementation
+still uses simple extraction JSON files and a basic Markdown protocol builder for
+technical validation.
+
+## Renderers
+
+Each Output View is produced by a renderer.
+
+Depending on the implementation, rendering may be:
+
+- deterministic
+- template-based
+- LLM-assisted
+
+The architecture does not assume that every renderer must always use an LLM.
+
+## Working Protocol
+
+Suggested filename: `working_protocol.md`
+
+German working term: Arbeitsprotokoll
+
+Purpose:
+
+- recap the meeting later
+- preserve reasoning and context
+- support participants and follow-up work
+- remain understandable to a neutral reader with limited background
+
+Characteristics:
+
+- relatively complete
+- retains relevant background and rationale
+- shows how conclusions were reached
+- includes decisions, tasks, open questions and important discussion context
+- may include rejected alternatives when they help explain the result
+- removes obvious noise, duplicates and irrelevant technical interruptions
+- is not a verbatim transcript
+
+Completeness goal: optimize for recall and traceability.
+
+## Concise Distribution Protocol
+
+Suggested filename: `distribution_protocol.md`
+
+German working term: Verteilerprotokoll
+
+Terminology decision: use "distribution protocol" rather than "management
+protocol" as the default English term because the audience includes colleagues,
+management and stakeholders. The document should be suitable for circulation,
+not only for management.
+
+Purpose:
+
+- distribute meeting results to colleagues, management or stakeholders
+- enable rapid understanding
+- communicate only what matters operationally
+
+Characteristics:
+
+- significantly more condensed than the working protocol
+- organized around core topics and outcomes
+- focuses on purpose, key conclusions, decisions, agreed next steps and
+  responsibilities
+- omits most discussion history and exploratory reasoning
+- reads like a polished meeting summary or management memo
+
+Completeness goal: optimize for relevance and brevity.
+
+## Knowledge-Base Entry
+
+Suggested filename: `knowledge_entry.md`
+
+Alternative planned structured format: `knowledge_entry.json`
+
+German working term: Wissensdatenbankeintrag
+
+Purpose:
+
+- preserve durable organizational knowledge
+- provide reusable input for a future Knowledge Assistant or RAG system
+- detach stable knowledge from the meeting event itself
+
+Characteristics:
+
+- is not written as a meeting recap
+- removes conversational framing
+- removes temporary discussion details
+- focuses on accepted processes, definitions, responsibilities, rules,
+  decisions with continuing validity and unresolved knowledge gaps
+- distinguishes stable knowledge from temporary meeting-specific actions
+- may retain source meeting metadata for traceability, but not in the main prose
+
+Completeness goal: optimize for durability and reuse.
+
+Long-term target: Knowledge Objects.
+
+Knowledge Objects may represent durable organizational knowledge such as:
+
+- processes
+- definitions
+- responsibilities
+- rules
+- accepted practices
+- long-term decisions
+
+Knowledge Objects are independent of the original meeting wording. Markdown is
+only one possible presentation. JSON or another structured format is expected to
+become the canonical storage format later.
+
+## Future Reuse
+
+Canonical Meeting Knowledge and future Knowledge Objects are intended to become
+reusable building blocks for systems such as:
+
+- Meeting Assistant
+- Production Knowledge Assistant
+- future enterprise knowledge retrieval
+- RAG systems
+
+This section is conceptual. It does not define a storage engine, retrieval
+architecture or embedding strategy.
+
+## Comparison
+
+Working Protocol:
+
+- preserves context
+- useful for later recollection
+- relatively complete
+
+Distribution protocol:
+
+- concise
+- outcome-oriented
+- suitable for circulation
+
+Knowledge-base Entry / Knowledge Objects:
+
+- event-independent
+- durable
+- structured for future retrieval and reuse

docs/pipeline.md

@@ -36,10 +36,14 @@ Specialized Extraction
 Consolidation
         │
         ▼
-Structured Meeting
+Canonical Meeting Knowledge
         │
         ▼
-Protocol Generation
+Output View Rendering
+        │
+        ├── Working Protocol
+        ├── Distribution Protocol
+        └── Knowledge Objects
 ```
 
 Each stage receives a well-defined input and produces a well-defined output.
@@ -299,13 +303,13 @@ Planned
 
 ---
 
-# Stage 7 – Structured Meeting
+# Stage 7 – Canonical Meeting Knowledge
 
 ## Purpose
 
-Produce a complete machine-readable representation of the meeting.
+Produce the canonical semantic representation of one meeting.
 
-This is the primary output of the analysis pipeline.
+This representation is the single source of truth for all downstream outputs.
 
 Example:
 
@@ -326,29 +330,58 @@ Example:
 
 The exact schema will evolve during development.
 
+Conceptually, the Canonical Meeting Knowledge should include:
+
+- meeting metadata
+- topics
+- facts
+- decisions
+- action items
+- open questions
+- positions
+- technical information
+- rationale and discussion context
+- contradictions or uncertainty
+- source references and evidence
+
+The detailed schema remains future implementation work.
+
 ## Current Status
 
 Planned
 
 ---
 
-# Stage 8 – Protocol Generation
+# Stage 8 – Output View Rendering
 
 ## Purpose
 
-Generate human-readable documents from structured meeting data.
+Render purpose-specific outputs from Canonical Meeting Knowledge.
 
-Possible outputs include:
+The planned output products are:
 
-- Full protocol
+- Working Protocol (`working_protocol.md`, Arbeitsprotokoll)
-- Executive summary
+- Distribution Protocol (`distribution_protocol.md`, Verteilerprotokoll)
-- Action list
+- Knowledge Objects, rendered as a Knowledge-base Entry (`knowledge_entry.md`)
-- Decision log
+  and later stored in a structured format such as `knowledge_entry.json`
-- Technical report
+  (Wissensdatenbankeintrag)
 
-Protocol generation never performs additional analysis.
+Output rendering never performs additional analysis.
 
-It only transforms existing structured information into readable text.
+It only transforms existing structured information into the required view.
+
+The outputs are rendered in parallel from the canonical representation. The
+Distribution Protocol is not derived from the Working Protocol, and Knowledge
+Objects are not derived from either protocol.
+
+Rendering may be deterministic, template-based or LLM-assisted depending on the
+output and implementation maturity.
+
+Completeness differs by output:
+
+- The Working Protocol optimizes for recall and traceability.
+- The Distribution Protocol optimizes for relevance and brevity.
+- Knowledge Objects optimize for durability and reuse.
 
 ## Processing Type
 
@@ -420,9 +453,9 @@ A processing stage may be replaced by another implementation as long as it prese
 
 ⬜ Consolidation
 
-⬜ Structured Meeting
+⬜ Canonical Meeting Knowledge
 
-⬜ Protocol Generation
+⬜ Output View Rendering
 ```
 
-The immediate development focus is **Topic Segmentation**, as it provides the semantic structure on which all subsequent processing stages depend.
+The immediate development focus is **Topic Segmentation**, as it provides the semantic structure on which all subsequent processing stages depend.