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
This commit is contained in:
@@ -43,7 +43,9 @@ Extraktion
|
||||
↓
|
||||
Konsolidierung
|
||||
↓
|
||||
Protokoll
|
||||
Canonical Meeting Knowledge
|
||||
↓
|
||||
Arbeitsprotokoll / Verteilerprotokoll / Knowledge Objects
|
||||
```
|
||||
|
||||
Jeder Verarbeitungsschritt löst genau eine klar definierte Aufgabe.
|
||||
@@ -89,18 +91,40 @@ 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.
|
||||
|
||||
---
|
||||
|
||||
|
||||
+27
-5
@@ -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
|
||||
|
||||
+42
-5
@@ -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.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -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
|
||||
+50
-17
@@ -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
|
||||
- Executive summary
|
||||
- Action list
|
||||
- Decision log
|
||||
- Technical report
|
||||
- Working Protocol (`working_protocol.md`, Arbeitsprotokoll)
|
||||
- Distribution Protocol (`distribution_protocol.md`, Verteilerprotokoll)
|
||||
- Knowledge Objects, rendered as a Knowledge-base Entry (`knowledge_entry.md`)
|
||||
and later stored in a structured format such as `knowledge_entry.json`
|
||||
(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.
|
||||
Reference in New Issue
Block a user