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:

```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:

- The Deterministic Canonicalizer 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.
- The Semantic Consolidator uses the local LLM to merge semantically equivalent
  statements, group content by topic, preserve evidence from all contributing
  chunks, mark contradictions and uncertainty, separate durable information from
  transient discussion and produce Canonical Meeting Knowledge. It does not
  directly write a protocol.

## 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.

## 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