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

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