admin
63075eaca9
- document responsibility attribution as a project-wide invariant - prevent inferred ownership in protocol rendering - add negative gold regression for false responsibility assignment - document future responsibility evidence and attribution model - record the real-life benchmark finding
214 lines
6.3 KiB
Markdown
214 lines
6.3 KiB
Markdown
# 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
|
|
->
|
|
Deterministic Canonicalizer
|
|
->
|
|
Semantic Consolidator
|
|
->
|
|
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.
|
|
|
|
The next planned architecture stage before this representation is explicit:
|
|
|
|
- Canonicalizer V1 validates and normalizes extraction objects, assigns stable
|
|
source references and IDs, performs only safe deterministic cleanup and
|
|
preserves all source evidence. It uses no LLM and must not make uncertain
|
|
semantic merges.
|
|
- Semantic Consolidator V0 uses the local LLM only for facts-only semantic
|
|
duplicate detection. It preserves source evidence and does not directly write
|
|
a protocol or produce Canonical Meeting Knowledge.
|
|
- Future Semantic Consolidator versions should group content by topic, mark
|
|
contradictions and uncertainty, separate durable information from transient
|
|
discussion and prepare Canonical Meeting Knowledge.
|
|
|
|
## 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.
|
|
|
|
Rendered protocol language should normally match the dominant language of the
|
|
source transcript or consolidated meeting knowledge unless an explicit output
|
|
language is requested.
|
|
|
|
Responsibility attribution is a cross-cutting invariant for every Output View.
|
|
A renderer may name a person, team or department as responsible only when the
|
|
input explicitly contains that assignment or acceptance. Discussion,
|
|
expertise, objection, suggestion, speaker adjacency, organizational
|
|
assumptions and department mentions do not establish ownership. If
|
|
responsibility is unclear, render it as open rather than guessing.
|
|
|
|
## 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
|