admin
950284e236
This commit significantly improves the robustness and determinism of the Meeting Lab processing pipeline and establishes the first Release Candidate baseline for end-to-end evaluation. Highlights - BUG-009 - Implement deterministic responsible-party validation - Normalize participant aliases using Meeting Context - Reject invalid responsible values (dates, locations, technical terms, projects, products, unknown entities) - Record structured responsibility validation metadata - Add focused regression tests - BUG-010 - Implement adaptive num_predict estimation for Semantic Consolidator - Eliminate JSON truncation caused by fixed output limits - Add deterministic source coverage repair - Preserve strict post-repair validation - Add regression tests - BUG-011 - Implement Working Protocol V2 renderer contract enforcement - Preserve raw renderer responses - Reject invalid protocol output instead of accepting malformed documents - Add deterministic cleanup for harmless formatting deviations - Add focused renderer regression tests - Meeting Context - Validate Meeting Context V1 - Integrate authoritative participant alias normalization - Documentation - Update architecture documentation - Update output documentation - Update regression bug tracker The pipeline now fails safely instead of silently accepting invalid intermediate or final artifacts. Remaining work focuses primarily on extraction quality and semantic classification (decisions, action items, protocol faithfulness), rather than pipeline robustness.
229 lines
7.0 KiB
Markdown
229 lines
7.0 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.
|
|
|
|
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
|