meeting-lab/docs/output-views.md

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:

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.

Current Working Protocol V2 renderer contract:

• output must begin exactly with # Working Protocol
• no explanatory preamble may appear before that heading
• content is organized by topic with ## topic headings
• each topic may use only the supported ### sections: Background, Decisions, Action Items, Open Questions
• category-level report framing such as a global ## Decisions / ## Action Items summary is not a valid topic-oriented Working Protocol
• raw model responses are preserved separately
• deterministic cleanup may remove leading prose before an already valid # Working Protocol heading and normalize harmless heading whitespace
• working_protocol.md is written only after the cleaned candidate passes the renderer contract validator

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