Preserve North protocol regression evidence

Record the V1-V3 experiments and accept the minimal semantic-preservation first stage.

.gitattributes

@@ -0,0 +1 @@
+samples/real_live/**/*.wav filter=lfs diff=lfs merge=lfs -text

.gitignore

@@ -21,6 +21,9 @@ dist/
 
 # Test
 .pytest_cache/
+.test-tmp/
+.test-tmp-root/
+tmp_run_meeting_tests/
 .coverage
 htmlcov/
 
@@ -31,6 +34,16 @@ htmlcov/
 # Experiment Outputs
 experiments/**/output/
 experiments/**/results/
+artifacts/experiments/**/
+
+# Pipeline runtime artifacts
+samples/raw/
+samples/whisper/
+**/chunk_*_extraction.json
+**/meeting_protocol.md
+**/*.raw.txt
+tests/gold/**/actual.json
+samples/benchmarks/semantic_consolidator_v0/raw_model_response.txt
 
 # Lokale Meetings (niemals versionieren)
 meeting_data/

AGENTS.md

@@ -0,0 +1,163 @@
+# AGENTS.md
+
+Practical instructions for coding agents working in Meeting Lab.
+
+## Project Purpose
+
+Meeting Lab extracts and structures organizational knowledge from meeting
+recordings. It is an experimental local discussion analyzer, not merely a
+one-step meeting-protocol generator.
+
+Successful approaches may later move into the Meeting Assistant project.
+
+## Current Pipeline
+
+Current and intended flow:
+
+```text
+Audio
+-> Whisper
+-> cleanup
+-> normalization
+-> chunking
+-> local chunk extraction
+-> deterministic canonicalization
+-> semantic consolidation
+-> Canonical Meeting Knowledge
+-> Output Views
+```
+
+Status:
+
+- Implemented: Whisper JSON cleanup script, normalization, technical chunking,
+  local chunk extraction, Canonicalizer V1, Semantic Consolidator V0
+  facts-only duplicate detection, interim Markdown protocol builder.
+- Experimental/prototype: topic segmentation and review tooling.
+- Planned: broader semantic consolidation, Canonical Meeting Knowledge
+  implementation, final Output Views.
+
+## Architectural Principles
+
+- Canonical Meeting Knowledge is the intended semantic source of truth.
+- Working Protocol / Arbeitsprotokoll, Distribution Protocol /
+  Verteilerprotokoll and Knowledge Objects / Wissensdatenbankeintrag are
+  parallel output views.
+- Output views must not silently change meaning. They may select, condense or
+  render information for an audience, but not invent new semantics.
+- Extraction, consolidation, synthesis and rendering are separate concerns.
+- Deterministic canonicalization and semantic consolidation are separate
+  concerns.
+- Canonicalizer V1 is implemented Python code. It validates and normalizes
+  extraction objects, assigns stable source references and IDs, normalizes
+  category names and basic field structure, performs only safe deterministic
+  cleanup, may group exact duplicates, and must preserve all source evidence.
+  It must not perform uncertain semantic merging.
+- Semantic Consolidator V0 is implemented as local-LLM facts-only duplicate
+  detection. It merges semantically equivalent fact items conservatively,
+  preserves source references and evidence, and validates complete source fact
+  coverage. It is not a summarizer, topic grouper, protocol renderer or
+  complete Canonical Meeting Knowledge stage.
+- Broader semantic consolidation remains planned. It should group content by
+  topic, mark contradictions and uncertainty, separate durable information from
+  transient discussion, and prepare Canonical Meeting Knowledge. It does not
+  directly write a protocol.
+- Prefer small, testable processing stages over one monolithic LLM prompt.
+- Current extraction strategy is one normalized chunk per LLM call.
+- Do not expand context windows or redesign the extraction strategy without an
+  explicit experiment.
+- Deterministic stages should remain deterministic where possible.
+- Rendered protocol output language should normally match the dominant language
+  of the source transcript or consolidated meeting knowledge unless an explicit
+  output language is requested.
+
+## Responsibility Attribution Invariant
+
+A person, team or department may be recorded as responsible only when the
+meeting evidence explicitly assigns, accepts or confirms that responsibility.
+
+Discussion, expertise, objection, suggestion, thematic proximity, speaker
+adjacency, organizational assumptions, likely job roles or mere mention do not
+establish ownership.
+
+When support is incomplete or ambiguous, leave the responsible person unset,
+mark the item as unclear where the current schema supports it, and preserve the
+supporting evidence. Never guess.
+
+This invariant applies to extraction, canonicalization, semantic consolidation,
+Canonical Meeting Knowledge, Working Protocol / Arbeitsprotokoll, Distribution
+Protocol / Verteilerprotokoll and Knowledge Objects /
+Wissensdatenbankeintrag.
+
+## Prompt Engineering Rules
+
+The Gold Standard corpus is the reference specification. Follow Rules 1-11 from
+`tests/gold/PROMPT_ENGINEERING_METHODOLOGY.md`:
+
+1. Make only one prompt change per iteration.
+2. Optimize only one target gold test case at a time.
+3. Validate every prompt modification immediately.
+4. Accept a prompt change only if it improves the target and causes no
+   regressions in previously passing gold tests.
+5. Never modify `expected.json` merely to make a prompt pass.
+6. Prompt engineering edits prompt files only; Python code changes require a
+   separate explicit task.
+7. Maintain a prompt evolution log for every iteration.
+8. Stop arbitrary iterations if small changes do not improve the test; analyze
+   the root cause.
+9. Avoid gold-test overfitting. Prompt changes must generalize and must not
+   special-case one transcript.
+10. Stop after two consecutive non-improving prompt iterations and classify the
+    root cause.
+11. Verify whether the target gold test has objectively unique ground truth
+    before changing a prompt for unexpected behavior.
+
+Current documented Prompt Version 2 decision baseline:
+
+- `decision_simple`: passing
+- `decision_deferred`: passing
+- `decision_none`: passing
+
+## LLM Execution Safety
+
+- Never start a full multi-chunk LLM run unless explicitly requested.
+- Before any LLM run, state the model, inputs, expected LLM-call count and
+  output location.
+- Do not retry LLM calls automatically unless explicitly allowed.
+- Do not download models automatically.
+- Prefer small-scope validation runs.
+- Never use generated output as committed source data.
+- Preserve raw model responses when diagnosing parser or truncation failures.
+- Do not run Ollama from unit tests.
+
+## Development Rules
+
+- Make small, focused changes.
+- Preserve the existing architecture unless a redesign is explicitly requested.
+- Add regression tests for bugs.
+- Run non-LLM tests before committing when code changes are made.
+- Do not commit generated transcripts, audio, extraction JSON, protocol output
+  or temporary files.
+- Report files changed, tests run and assumptions.
+- Do not commit or push unless explicitly requested.
+
+## Repository Conventions
+
+- `README.md`: project overview and current high-level status.
+- `docs/`: architecture, pipeline, data model and output-view documentation.
+- `prompts/`: extraction and segmentation prompts. Treat prompt edits as
+  controlled experiments.
+- `tests/gold/`: Gold Standard corpus and semantic specification for extraction
+  behavior.
+- `scripts/`: command-line support scripts such as Whisper cleanup and gold
+  test execution.
+- `src/meeting_lab/normalization/`: deterministic transcript cleanup.
+- `src/meeting_lab/chunking/`: technical chunk creation; chunks are not topics.
+- `src/meeting_lab/segmentation/`: experimental topic segmentation tooling.
+- `src/meeting_lab/extraction/`: local LLM extraction flow and category
+  extractor modules.
+- `src/meeting_lab/consolidation/`: Canonicalizer V1 and Semantic
+  Consolidator V0.
+- `src/meeting_lab/protocol/`: interim protocol rendering.
+- `src/meeting_lab/models/`: current lightweight data models.
+- `samples/`: sample inputs and generated/experimental artifacts; do not treat
+  sample output as canonical source data.

CHANGELOG.md

@@ -0,0 +1,81 @@
+# Changelog
+
+## Unreleased
+
+### Added
+
+- Initial Meeting Lab project structure with source, docs, prompts, samples and
+  tests directories.
+- Deterministic transcript normalization module.
+- Technical transcript chunking with block-aligned chunk generation.
+- Whisper JSON cleanup support.
+- Local Ollama-based chunk extraction flow.
+- Interim Markdown meeting protocol builder for technical validation.
+- Initial and windowed topic segmentation prototypes plus review tooling.
+- Gold Standard extraction corpus and gold-test runner.
+- Prompt loading support and common/decision prompt baseline.
+- Output-view architecture documentation for Canonical Meeting Knowledge,
+  Working Protocol / Arbeitsprotokoll, Distribution Protocol /
+  Verteilerprotokoll and Knowledge Objects / Wissensdatenbankeintrag.
+- Working Protocol Synthesizer V0 benchmark artifact for future
+  canonicalizer/consolidator comparisons.
+- Canonicalizer V1 deterministic CLI for canonicalizing chunk extraction JSON.
+- Non-LLM Canonicalizer V1 tests covering ordering, validation, IDs, parsing,
+  source references, exact duplicates, invalid JSON and empty categories.
+- Semantic Consolidator V0 CLI for conservative facts-only semantic duplicate
+  detection using local Ollama.
+- Consolidation prompt and non-LLM tests for payload construction, grouping
+  validation and source fact coverage.
+- Semantic Consolidator V0 benchmark report and consolidated extraction JSON.
+- Gold regression scenario for responsibility attribution integrity.
+- Meeting Context V1 YAML scaffold, generic template and documentation for
+  manually maintained meeting metadata.
+- Meeting Context V1 loader, validator, deterministic prompt representation,
+  optional `--meeting-context` extraction CLI integration and extraction
+  context provenance.
+- PyYAML project dependency for Meeting Context YAML loading.
+- Focused Gold scenarios for responsibility attribution and explicit position
+  extraction.
+
+### Changed
+
+- Refined the architecture from a single meeting protocol toward Canonical
+  Meeting Knowledge as the planned semantic source of truth.
+- Clarified that Working Protocol, Distribution Protocol and Knowledge Objects
+  are parallel renderings, not derived from one another.
+- Documented the planned Deterministic Canonicalizer and Semantic Consolidator
+  stages before Canonical Meeting Knowledge.
+- Clarified that Semantic Consolidator V0 is implemented only for fact
+  duplicate detection; broader semantic synthesis and Canonical Meeting
+  Knowledge remain planned.
+- Documented that rendered protocol language should normally match the source
+  transcript or consolidated meeting knowledge unless explicitly requested
+  otherwise.
+- Added the Responsibility Attribution Invariant across extraction,
+  canonicalization, consolidation, Canonical Meeting Knowledge and output
+  views.
+- Updated decision extraction semantics to include explicit process decisions
+  and deferrals.
+- Shared extraction prompt assembly now loads `common.md`, `decisions.md` and
+  `todos.md`.
+- Added explicit action-item responsibility attribution rules and clarified
+  the decision/todo boundary, including duplicate-classification handling.
+- Marked Meeting Context integration with later pipeline stages as planned
+  while extraction-stage integration is implemented.
+
+### Fixed
+
+- Fixed Whisper JSON chunk extraction to prefer `segments[*].text` over the
+  aggregate top-level `text` field.
+- Added chunking tests to ensure chunks do not duplicate later blocks when no
+  overlap is requested.
+- Added parser handling for model responses that contain thinking text before
+  the final JSON object.
+
+### Documentation
+
+- Added architecture, pipeline and data-model documentation.
+- Added output-view documentation.
+- Added Gold Standard prompt-engineering methodology.
+- Added formal decision-definition documentation.
+- Added scenario README files for the Gold Standard corpus.

PROJECT_KNOWLEDGE.md

@@ -0,0 +1,317 @@
+# Project Knowledge
+
+## Meeting language in direct protocols
+
+Direct protocol prompts derive their explicit output language from persisted
+Meeting Context `meeting.language`, including regeneration and diarized fallback.
+Missing context/language explicitly defaults to `de`; omitted language is accepted
+without modifying context data. Protocol runtime `output_language` is derived
+provenance, not a separate setting. No transcript/context translation is performed.
+
+Prompt evolution (2026-09-11): replaced unconditional German output with the
+meeting-language instruction in the shared prompt builder. Names remain verbatim.
+Validation uses mocked generation for German/English, plain/diarized inputs,
+regeneration and legacy contexts; no live model or extraction gold run is involved.
+
+This is a compact operational summary of the current Meeting Lab state.
+
+## Objective
+
+Meeting Lab develops and evaluates local methods for extracting structured
+organizational knowledge from real meeting recordings and transcripts. The
+project is a research and validation environment for a future Meeting
+Assistant, not a finished product.
+
+## Implemented Pipeline Stages
+
+Implemented:
+
+- Whisper JSON cleanup via `scripts/clean_whisper_json.py`.
+- Transcript normalization in `src/meeting_lab/normalization/`.
+- Technical chunking in `src/meeting_lab/chunking/`.
+- Local per-chunk extraction in `src/meeting_lab/extraction/extract_chunks.py`.
+- Deterministic Canonicalizer V1 in
+  `src/meeting_lab/consolidation/canonicalize.py`.
+- Semantic Consolidator V0 in
+  `src/meeting_lab/consolidation/consolidate_facts.py` for facts-only
+  semantic duplicate detection.
+- Prompt loading from `src/meeting_lab/llm/prompts.py`.
+- Meeting Context V1 loading, validation and optional extraction prompt
+  injection with minimal extraction JSON provenance.
+- FFmpeg-backed WAV, FLAC and M4A preparation into a per-run canonical mono
+  16 kHz signed PCM16 WAV artifact before transcription or diarization. Audio
+  preparation always runs. Optional loudness normalization defaults to on and
+  currently uses the isolated FFmpeg filter
+  `loudnorm=I=-16:LRA=11:TP=-1.5`. This is a conservative speech-recording
+  default and may be revisited after empirical comparison without changing the
+  orchestration API.
+- Interim Markdown protocol generation in `src/meeting_lab/protocol/`.
+- Direct protocol prompt input protection: diarized transcripts are rendered as
+  compact adjacent-speaker blocks without per-segment timestamps. Every source
+  segment remains represented in order. A deterministic heuristic enforces a
+  configurable safe input budget, falls back to complete plain transcript text
+  when necessary, and fails before any Ollama request if even that input is too
+  large. Silent head/tail truncation is prohibited.
+- The `qwen3.8:27b` direct-protocol stage explicitly requests `num_ctx=32768`
+  and `think=false`; the practical prompt target is approximately 29,000 tokens.
+  A 31,038-token synthetic prompt passed, but larger prompts are not assumed safe
+  from the model's advertised 262,144-token native context alone.
+- `regenerate_mvp_protocol` updates the run's validated Meeting Context and
+  regenerates protocol artifacts from the existing diarized transcript when
+  available. It never reruns audio preparation, Whisper or Pyannote, and it
+  preserves anonymous speaker labels in the source transcript.
+- Non-LLM unit tests for chunking, extraction helpers, protocol rendering and
+  gold-test runner validation.
+- Meeting Context V1 scaffold and documentation for manually maintained
+  meeting metadata.
+
+Experimental/prototype:
+
+- Topic segmentation in `src/meeting_lab/segmentation/`.
+- Windowed segmentation and review output in `samples/chunks/`.
+- Gold Standard extraction corpus under `tests/gold/`.
+
+Planned:
+
+- Broader semantic consolidation for topic grouping, contradiction handling,
+  uncertainty marking and durable/transient separation.
+- Canonical Meeting Knowledge implementation as the semantic source of truth.
+- Meeting Context integration with Canonicalizer, Semantic Consolidator,
+  Canonical Meeting Knowledge and output renderers.
+- Final Working Protocol / Arbeitsprotokoll, Distribution Protocol /
+  Verteilerprotokoll and Knowledge Objects / Wissensdatenbankeintrag renderers.
+
+## Source Tree
+
+```text
+src/meeting_lab/
+  chunking/        technical transcript chunking
+  consolidation/   planned canonicalization/consolidation area
+  extraction/      current local LLM extraction flow
+  io/              lightweight file and JSON helpers
+  llm/             Ollama and prompt support
+  models/          current lightweight model definitions
+  normalization/   deterministic transcript cleanup
+  protocol/        interim Markdown protocol builder
+  segmentation/    experimental topic segmentation tooling
+```
+
+Supporting areas:
+
+- `docs/`: architecture, pipeline, data models and output-view concepts.
+- `docs/meeting-context.md`: Meeting Context V1 scaffold, fields and future
+  integration rules.
+- `prompts/`: active extraction prompt files. The shared extraction prompt is
+  assembled from `common.md`, `decisions.md` and `todos.md`.
+- `tests/gold/`: semantic gold tests and prompt-engineering methodology.
+- `samples/`: sample inputs and generated or experimental artifacts.
+- `scripts/`: operational scripts for cleanup and gold-test execution.
+
+## Current Model Strategy
+
+The current extraction strategy is one normalized chunk per LLM call. This is
+preferred over expanding context windows or asking one model call to analyze a
+full meeting.
+
+Known working models from current project notes and experiment practice:
+
+- `qwen3:1.7b`: useful for smoke tests.
+- `qwen3.5:9b`: useful for meaningful extraction and segmentation work.
+
+LLM calls use Ollama locally. The current extractor defaults to `qwen3:8b`, but
+validated work may specify another model explicitly.
+
+## Important Findings
+
+- Whisper JSON chunking must use `segments[*].text`, not only the top-level
+  `text` field.
+- Independent chunk extraction is currently preferred.
+- Larger context windows can change classification behavior and increase
+  instability.
+- Extraction and consolidation are separate problems.
+- Generation limits can truncate JSON.
+- Qwen thinking may be returned separately by the Ollama API.
+- Gold Standard tests are also a formal specification of meeting semantics.
+- Raw model responses should be preserved when diagnosing parser or truncation
+  failures.
+- Responsibility attribution is a critical correctness invariant: people,
+  teams and departments must not be assigned ownership from discussion,
+  expertise, objection, thematic proximity, speaker adjacency, role guesses or
+  world knowledge. Assignment requires explicit evidence.
+
+## Decision Taxonomy
+
+Accepted decision semantics:
+
+- A decision is an explicit agreement that creates a binding change in action,
+  process, responsibility, approval status, timing or next step.
+- Included: substantive decisions, organizational decisions, process decisions,
+  approvals, rejections, deferrals, explicit agreement not to decide yet, and
+  explicit agreement to gather more information before deciding.
+- Excluded: opinions, preferences, proposals without agreement, open questions,
+  current-state descriptions and explanations without commitment.
+- A process decision to defer a substantive decision is still a decision.
+- "No decision was reached" is different from "the group decided to defer the
+  decision."
+- A personal commitment to perform concrete future work is normally a todo,
+  not a decision, unless the group also establishes a separate binding outcome,
+  rule, approval, rejection, deferral, selection, process state or
+  responsibility policy.
+- The same proposition should not be duplicated under decisions and todos.
+  Extract both only when the transcript contains a group-level decision and a
+  semantically separate resulting action item.
+
+## Responsibility Attribution
+
+Meeting Lab distinguishes mentioned people, speakers, participants,
+responsible people, departments, owners and assignees. These concepts must not
+be collapsed into one field.
+
+Meeting Context V1 reinforces this distinction by separating actual
+participants from mentioned non-participants and by storing aliases, roles and
+departments only when they are explicitly supplied as metadata. It must not be
+used to infer responsibilities. In the current implementation this context can
+be injected into chunk extraction prompts as authoritative metadata, and only
+minimal provenance is written to extraction JSON.
+The implemented MVP statuses are exactly `present` and `mentioned_only`.
+Legacy entries without a status receive collection-appropriate defaults. Only
+present participants may be targets of explicit `SPEAKER_XX` mappings.
+
+A `responsible` or future `owner` / `assignee` value may be recorded only when
+source evidence explicitly assigns, accepts or confirms responsibility. If the
+evidence is incomplete or ambiguous, the responsible person remains `null` or
+unset and the evidence is preserved. Future schema work may add
+`responsibility_status` values such as `explicit`, `accepted`, `proposed` and
+`unclear`, plus `attribution_evidence`.
+
+Meeting Context may validate identity, role, department and attendance, but it
+never establishes responsibility.
+
+Focused Gold coverage now separates these concerns:
+
+- `responsibility_attribution_negative`: tests that discussion, objection and
+  department proximity do not create an owner.
+- `position_explicit_objection`: tests explicit position extraction separately
+  from responsibility attribution.
+
+Current Prompt Version 2 decision baseline:
+
+- `decision_simple`: passing.
+- `decision_deferred`: passing.
+- `decision_none`: passing.
+- Prompt Version 2 explicitly supports process decisions where the group agrees
+  to defer a substantive decision until more information is available.
+
+## Canonical Knowledge Architecture
+
+The next documented pipeline milestone is:
+
+```text
+Chunk Extractions
+  -> Deterministic Canonicalizer
+  -> Semantic Consolidator
+  -> Canonical Meeting Knowledge
+  -> Output View Renderers
+```
+
+Canonicalizer V1 is implemented Python code with no LLM. It validates and
+normalizes extraction objects, assigns stable source references and IDs,
+normalizes category names and basic field structure, performs only safe
+deterministic cleanup, optionally groups exact duplicates, and preserves all
+source evidence. It must not perform uncertain semantic merging.
+
+CLI:
+
+```text
+PYTHONPATH=src .venv/bin/python -m meeting_lab.consolidation.canonicalize \
+  samples/whisper/meeting_speech_cleaned_chunks \
+  -o /tmp/canonicalized_extractions.json
+```
+
+Semantic Consolidator V0 is implemented as narrow local-LLM work for fact
+items only. It merges semantically equivalent fact statements, preserves source
+references and evidence, and prefers false negatives over false-positive
+merges. It is not a summarizer, topic grouper, protocol renderer or complete
+Canonical Meeting Knowledge stage.
+
+The first accepted V0 benchmark used `qwen3.5:9B` in one Ollama call over 33
+fact items. Runtime on the current machine was 390.119 seconds. One correct
+merge was accepted, involving `fact_0025` and `fact_0031`; 31 facts remained
+singletons, validation passed, no source fact was lost or duplicated, and
+non-fact categories remained unchanged. This is a local benchmark, not a
+general hardware claim.
+
+Broader semantic consolidation remains planned. It should group content by
+topic, mark contradictions and uncertainty, separate durable information from
+transient discussion, and produce Canonical Meeting Knowledge. It does not
+directly write a protocol.
+
+Canonical Meeting Knowledge is the planned semantic intermediate model and
+future single source of truth. It should be structured, preferably JSON, and
+preserve topics, facts, decisions, action items, open questions, positions,
+technical details, rationale, uncertainty, contradictions and source evidence.
+It is not itself a prose protocol.
+
+Output views are planned as independent renderings from that canonical model:
+
+- Working Protocol / Arbeitsprotokoll: relatively complete, optimized for
+  recall and traceability.
+- Distribution Protocol / Verteilerprotokoll: concise and outcome-oriented,
+  optimized for circulation.
+- Knowledge Objects / Wissensdatenbankeintrag: durable organizational knowledge
+  optimized for reuse.
+
+The current `meeting_protocol.md` builder is an interim technical validation
+tool, not the final output-view architecture.
+
+Rendered protocol output should normally use the dominant language of the
+source transcript or consolidated meeting knowledge unless an explicit output
+language is requested.
+
+## Current Limitations
+
+- Discussion Blocks are documented as a stable semantic unit but are not yet a
+  separate implemented pipeline artifact.
+- Topic segmentation exists as prototype tooling, not a stable pipeline stage.
+- Extraction is still a combined current flow, even though separate extractors
+  are the intended architecture.
+- Semantic Consolidator V0 is implemented only for facts-only duplicate
+  detection.
+- Meeting Context V1 is implemented only through chunk extraction; later-stage
+  integration remains planned.
+- Canonical Meeting Knowledge is documented but not implemented.
+- Final output views are documented but not implemented.
+- Some prompt files remain placeholders; `common.md`, `decisions.md` and
+  `todos.md` are active in the shared extraction prompt.
+- Gold tests currently emphasize extraction semantics, especially decisions,
+  todos, responsibility attribution and focused position extraction.
+
+## Next Recommended Engineering Step
+
+Stabilize repeatable local extraction evaluation before broadening the pipeline:
+expand Gold Standard coverage by category, keep one-chunk extraction as the
+baseline, and use small prompt experiments with immediate non-regression checks.
+The next recommended evaluation step is to use the consolidated V0 result as
+input for the unchanged Working Protocol renderer and compare that output
+against the Working Protocol Synthesizer V0 baseline and the human reference
+protocol.
+
+Protocol calls accept an optional positive `protocol_num_thread` setting through
+both initial processing and regeneration. With `None`, Ollama receives no
+`num_thread` override and selects its own thread configuration.
+
+Configured glossary aliases are diagnostic metadata only. Meeting Context supplies
+terminology guidance; direct-protocol transcript text is never alias-substituted.
+See `docs/protocol-generation-regression.md` for the frozen-input regression.
+
+Successful protocols are retained in `protocol/generations/NNN/` with their exact
+prompt, transcript input, response, model/runtime metadata and Meeting Context.
+Relative compatibility symlinks resolve through `protocol/current`, which is
+replaced atomically only after a complete record is written. Failed regeneration
+keeps the previous protocol, diagnostics and context. Legacy regular files are
+snapshotted before conversion. Publication is serialized with a local file lock.
+Read `current` once when inspecting a consistent multi-file snapshot. Copy whole
+run directories preserving relative symlinks. Process interruption may leave an
+unreferenced record or temporary directory, never a partial current generation.
+This local POSIX-filesystem contract does not promise power-loss durability or
+network-filesystem transaction semantics.

README.md

@@ -0,0 +1,292 @@
+# Meeting Lab
+
+The direct protocol uses saved Meeting Context `meeting.language`: `de` requests
+German output and `en` requests English output, for plain and diarized transcripts
+and protocol-only regeneration. Meeting Assistant supplies the same selection to
+Whisper. Missing context/language retains German output for older runs. Effective
+output language is recorded as `output_language` in protocol runtime metadata.
+Transcript text, authored context, names and speaker mappings are not translated.
+
+Experimentierumgebung zur Entwicklung eines lokalen Diskussionsanalyzers für Meetingtranskripte.
+
+## Ziel
+
+Das Meeting Lab dient dazu, Verfahren zur Analyse realer Meetingtranskripte zu entwickeln und zu evaluieren.
+
+Im Mittelpunkt steht nicht die Softwarearchitektur, sondern die Frage:
+
+> **Wie lässt sich aus einem realen Meeting möglichst zuverlässig strukturiertes Wissen extrahieren?**
+
+Meeting Lab ist die experimentelle R&D-Umgebung fuer den zukuenftigen
+*Meeting Assistant*. Es dient gleichzeitig als Forschungsplattform,
+Architektur-Spielwiese, Regressionsframework, Benchmark-Umgebung und
+Prototypimplementierung. Neue Ideen werden hier untersucht und gegen reale
+Meeting-Beispiele validiert, bevor sie fuer das Produkt in Betracht kommen.
+
+Der beabsichtigte Reifeprozess ist:
+
+```text
+Research idea
+    ->
+Meeting Lab experiment
+    ->
+Regression tests
+    ->
+Stable architecture
+    ->
+Meeting Assistant implementation
+```
+
+Nur ausreichend ausgereifte und verifizierte Komponenten sollen in den
+Meeting Assistant uebernommen werden. Meeting Lab darf bewusst experimentelle
+Ansaetze und Entwicklungszweige enthalten, die verworfen werden oder nie den
+Assistant erreichen.
+
+## Meeting Assistant und langfristige Produktentwicklung
+
+Der Meeting Assistant ist als Produktionsanwendung vorgesehen. Seine erste
+oeffentliche Beta soll auf einem stabilen Meeting-Lab-MVP basieren und eine
+polierte User Experience, Installer, Konfiguration und eine produktionsreife
+Pipeline bieten. Eine GUI ist optional; experimentelle Funktionen sollen
+standardmaessig nicht aktiviert sein.
+
+Meeting Lab entwickelt sich unabhaengig weiter und bleibt der langfristige
+Innovationszweig. Der erwartete Transferpfad lautet:
+
+```text
+Meeting Lab Alpha
+    ->
+Meeting Lab Beta
+    ->
+Meeting Assistant Beta
+    ->
+Meeting Assistant Release
+```
+
+Meeting-Assistant-Releases uebernehmen damit gezielt bewaehrte Meeting-Lab-
+Komponenten, waehrend der Assistant den stabilen Produktzweig bildet.
+
+---
+
+## Grundidee
+
+Klassische Meeting-Zusammenfassungen versuchen, das gesamte Transkript in einem einzigen Schritt zu verstehen und zusammenzufassen.
+
+Das funktioniert bei realen Diskussionen nur eingeschränkt, da Themen häufig
+
+- begonnen,
+- unterbrochen,
+- später wieder aufgenommen,
+- ergänzt oder
+- relativiert
+
+werden.
+
+Deshalb verfolgt das Meeting Lab einen mehrstufigen Analyseansatz.
+
+```text
+Meeting
+    ↓
+Normalisierung
+    ↓
+Diskussionsblöcke
+    ↓
+Themensegmentierung
+    ↓
+Extraktion
+    ↓
+Deterministic Canonicalizer
+    ↓
+Semantic Consolidator
+    ↓
+Canonical Meeting Knowledge
+    ↓
+Arbeitsprotokoll / Verteilerprotokoll / Knowledge Objects
+```
+
+Jeder Verarbeitungsschritt löst genau eine klar definierte Aufgabe.
+
+---
+
+## Entwicklungsprinzipien
+
+- Kleine, klar abgegrenzte Verarbeitungsschritte
+- Ein Modul = eine Aufgabe
+- Deterministische Vorverarbeitung
+- Nachvollziehbare Ergebnisse
+- Reproduzierbare Experimente
+- Lokale Ausführung ohne Cloud-Abhängigkeit
+
+---
+
+## Repository-Struktur
+
+```text
+meeting-lab/
+├── src/            # Quellcode
+├── prompts/        # LLM-Prompts
+├── experiments/    # Reproduzierbare Experimente
+├── samples/        # Beispieltranskripte
+├── tests/          # Tests
+├── docs/           # Dokumentation
+└── pyproject.toml
+```
+
+---
+
+## Aktuelle Pipeline
+
+```text
+Whisper
+    ↓
+normalize_transcript.py
+    ↓
+chunk_transcript.py
+    ↓
+(segment_topics.py)
+    ↓
+Extraktoren
+    ↓
+Deterministic Canonicalizer
+    ↓
+Semantic Consolidator
+    ↓
+Canonical Meeting Knowledge
+    ↓
+Output-Ansichten
+```
+
+Der aktuelle Architekturmeilenstein trennt deterministische Kanonisierung der
+Chunk-Extraktionen von semantischer Konsolidierung. Die Kanonisierung validiert
+und normalisiert Extraktionsobjekte ohne LLM. Semantic Consolidator V0 nutzt
+das lokale LLM nur fuer konservative facts-only Duplikaterkennung, erhaelt
+Evidenz und erzeugt noch keine Canonical Meeting Knowledge.
+
+Meeting Context V1 ist als manuell gepflegtes YAML-Geruest dokumentiert und
+fuer die Chunk-Extraktion implementiert. Die Extraktion kann den Kontext
+optional validieren, als autoritative Metadaten in den Prompt aufnehmen und
+minimale Kontext-Provenienz im Extraction JSON speichern. Konsolidierung,
+Canonical Meeting Knowledge und Rendering sind noch nicht daran angeschlossen.
+
+Als akzeptierte, aber noch nicht implementierte Architektur soll Meeting
+Context V2 kuenftig nicht mehr primaer manuell geschrieben werden. Nach Whisper
+soll ein Entity-Detection- und User-Confirmation-Schritt unbekannte Namen und
+Begriffe sichtbar machen. Bestaetigte Entitaeten werden in einer persistenten
+Entity Registry als cross-meeting Wissensquelle mit stabilen internen IDs,
+Anzeigenamen und Aliasen gepflegt. Aus Registry, Nutzerbestaetigungen und
+Meeting-Metadaten erzeugt ein Meeting Context Builder dann das
+meeting-spezifische `meeting_context.yaml`. Diese YAML-Datei bleibt der
+authoritative meeting-spezifische Point of Truth und ein reproduzierbares
+Input-Artefakt fuer den jeweiligen Pipeline-Lauf.
+
+Der gemeinsame Extraktionsprompt besteht aktuell aus `common.md`,
+`decisions.md` und `todos.md`. Die Todo-Regeln verlangen explizite Zuweisung,
+Freiwilligenmeldung oder Annahme, bevor eine verantwortliche Person gesetzt
+wird. Meeting Context kann Identitaet, Rolle, Abteilung und Anwesenheit
+validieren, begruendet aber niemals Verantwortung. Entscheidungen und Todos
+werden nicht aus derselben Proposition doppelt extrahiert; beides wird nur
+ausgegeben, wenn eine gruppenweite Entscheidung und eine davon getrennte
+Folgeaufgabe vorliegen.
+
+Das Meeting Lab behandelt "das Protokoll" nicht mehr als ein einzelnes
+Endprodukt. Das konsolidierte Meeting-Wissen ist die **Canonical Meeting
+Knowledge**, also die kanonische semantische Repräsentation eines Meetings und
+die Single Source of Truth für alle nachgelagerten Ausgaben.
+
+Aus dieser Canonical Meeting Knowledge entstehen drei unabhängige
+Output-Ansichten:
+
+- Working Protocol (`working_protocol.md`, Arbeitsprotokoll): relativ vollständig, mit Kontext,
+  Begründungen, Entscheidungen, Aufgaben und offenen Fragen.
+- Distribution Protocol (`distribution_protocol.md`, Verteilerprotokoll): deutlich kürzer,
+  ergebnisorientiert und für Kolleginnen, Management oder Stakeholder geeignet.
+- Knowledge Objects, dargestellt zum Beispiel als Knowledge-base Entry
+  (`knowledge_entry.md`) oder später strukturiert gespeichert, zum Beispiel als
+  `knowledge_entry.json` (Wissensdatenbankeintrag).
+
+Diese Ausgaben sind parallele Renderings desselben semantischen Modells. Das
+Arbeitsprotokoll ist nicht die Quelle des Verteilerprotokolls, und das
+Verteilerprotokoll ist nicht die Quelle der Knowledge Objects.
+
+Gerenderte Protokolle sollen normalerweise in der dominanten Sprache des
+Quelltranskripts beziehungsweise der konsolidierten Meeting Knowledge erstellt
+werden, sofern keine explizite Ausgabesprache angefordert wurde.
+
+---
+
+## Projektstatus
+
+Aktuell liegt der Schwerpunkt auf der Entwicklung eines modularen
+Diskussionsanalyzers. Implementiert sind Vorverarbeitung, technisches Chunking,
+lokale Chunk-Extraktion, Meeting Context V1 fuer die Extraktionsstufe,
+Canonicalizer V1 als deterministische Vorbereitung der Extraktionsergebnisse
+und Semantic Consolidator V0 fuer facts-only Duplikaterkennung. Canonical
+Meeting Knowledge, breitere semantische Synthese, Meeting-Context-Integration
+in spaetere Stufen und finale Output-View-Renderer sind geplante naechste
+Schritte.
+
+Canonicalizer V1 kann aus dem Repository heraus so ausgeführt werden:
+
+```text
+PYTHONPATH=src .venv/bin/python -m meeting_lab.consolidation.canonicalize \
+  samples/whisper/meeting_speech_cleaned_chunks \
+  -o /tmp/canonicalized_extractions.json
+```
+
+Semantic Consolidator V0 kann auf dem Canonicalizer-Output ausgefuehrt werden:
+
+```text
+PYTHONPATH=src .venv/bin/python -m meeting_lab.consolidation.consolidate_facts \
+  samples/benchmarks/canonicalizer_v1/canonicalized_extractions.json \
+  -o samples/benchmarks/semantic_consolidator_v0 \
+  --model qwen3.5:9B \
+  --endpoint http://127.0.0.1:11434/api/generate \
+  --no-think
+```
+
+Die eigentliche Ausgabeerzeugung ist bewusst der letzte Verarbeitungsschritt.
+
+Ein kompletter repository-nativer Referenzlauf fuer das Progeo-Benchmark kann
+auf dem Linux AI-PC ohne Codex mit einem Befehl gestartet werden:
+
+```text
+python scripts/run_meeting.py \
+  --input samples/real_live/progeo_meeting/progeo_whispercpp_vulkan_turbo_trimmed_converted.json \
+  --context samples/real_live/progeo_meeting/meeting_context.yaml \
+  --model qwen3.5:9b \
+  --benchmark-label progeo_ai_pc
+```
+
+Die Linux-Einrichtung ist:
+
+```text
+python3 -m venv .venv
+source .venv/bin/activate
+python -m pip install --upgrade pip
+python -m pip install -e .
+ollama pull qwen3.5:9b
+ollama list
+ollama ps
+```
+
+`ollama ps` muss fuer den Referenzlauf leer sein. Details zu Voraussetzungen,
+Artefakten, Windows-Beispiel und Vergleich mit dem AI-PC stehen in
+`docs/run-meeting.md`.
+
+---
+
+## Lizenz
+
+Noch nicht festgelegt.
+
+Successful protocols are retained in `protocol/generations/NNN/` with their exact
+prompt, transcript input, response, model/runtime metadata and Meeting Context.
+Relative compatibility symlinks resolve through `protocol/current`, which is
+replaced atomically only after a complete record is written. Failed regeneration
+keeps the previous protocol, diagnostics and context. Legacy regular files are
+snapshotted before conversion. Publication is serialized with a local file lock.
+Read `current` once when inspecting a consistent multi-file snapshot. Copy whole
+run directories preserving relative symlinks. Process interruption may leave an
+unreferenced record or temporary directory, never a partial current generation.
+This local POSIX-filesystem contract does not promise power-loss durability or
+network-filesystem transaction semantics.

ROADMAP.md

@@ -0,0 +1,299 @@
+# Roadmap
+
+No dates are assigned. Phases describe dependency order, not release promises.
+
+## Phase 1 - Stable Local Extraction
+
+Goal:
+
+- Establish reliable per-chunk extraction behavior for core meeting semantics.
+
+Deliverables:
+
+- Stronger Gold Standard coverage across facts, positions, decisions, todos,
+  questions and technical details.
+- Gold coverage for responsibility attribution: discussion, objection, role
+  proximity and department mention must not become ownership.
+- Improved category prompts.
+- Repeatable evaluation workflow.
+- Documented prompt experiment log.
+
+Prerequisites:
+
+- Existing chunk extraction flow.
+- Existing Gold Standard runner and methodology.
+
+Out of scope:
+
+- Full-transcript LLM extraction.
+- Larger context-window strategy changes without an explicit experiment.
+- Canonicalization, semantic consolidation or final protocol rendering.
+
+## Phase 2 - Deterministic Canonicalization
+
+Goal:
+
+- Convert independent chunk extraction JSON into a validated, normalized,
+  evidence-bearing intermediate representation without semantic guessing.
+
+Deliverables:
+
+- Canonicalizer V1 implemented in Python.
+- Stable source references and IDs.
+- Normalized category names and basic field structure.
+- Safe deterministic cleanup.
+- Exact duplicate grouping where unambiguous.
+- Preservation of all source evidence.
+
+Prerequisites:
+
+- Stable local extraction baseline.
+- Agreement on the extraction object shape that should be canonicalized.
+
+Current status:
+
+- Implemented as `meeting_lab.consolidation.canonicalize`.
+
+Out of scope:
+
+- Uncertain semantic merging.
+- Topic synthesis.
+- Protocol writing.
+- LLM calls.
+
+## Phase 3 - Semantic Consolidation
+
+Goal:
+
+- Merge canonicalized extraction objects into a coherent semantic meeting
+  representation while preserving evidence and uncertainty.
+
+Deliverables:
+
+- Semantic Consolidator V0 using the local LLM for facts-only duplicate
+  detection.
+- Semantically equivalent fact statement merging.
+- Evidence preserved from all contributing chunks.
+- Complete source fact coverage validation.
+- Later broader semantic consolidation with topic grouping, contradiction and
+  uncertainty markers, durable/transient separation and Canonical Meeting
+  Knowledge preparation.
+
+Prerequisites:
+
+- Canonicalizer V1 output with stable IDs and source references.
+- Gold or benchmark cases that expose duplication and category shifts.
+
+Current status:
+
+- Semantic Consolidator V0 is implemented and experimentally validated for
+  facts-only conservative merging.
+- The first accepted benchmark merged one correct pair among 33 facts and left
+  31 singleton groups.
+
+Out of scope:
+
+- Direct protocol writing.
+- Topic synthesis in V0.
+- Processing decisions, action items, questions, positions or technical details
+  in V0.
+- Canonical Meeting Knowledge generation in V0.
+- Deriving output views from one another.
+- Retrieval or RAG integration.
+
+## Phase 4 - Canonical Meeting Knowledge
+
+Goal:
+
+- Define and implement the semantic intermediate model that becomes the source
+  of truth for downstream outputs.
+
+Deliverables:
+
+- Canonical Meeting Knowledge schema.
+- Source evidence and traceability fields.
+- Clear distinction between durable knowledge and meeting-specific actions.
+- Migration path from consolidated extraction JSON into the canonical model.
+
+Prerequisites:
+
+- Semantic consolidation behavior that preserves evidence and uncertainty.
+- Agreement on required semantic categories.
+
+Out of scope:
+
+- GUI.
+- Export formats beyond those needed to validate the model.
+- Knowledge-system storage design.
+
+## Phase 4A - Meeting Context V2 and Entity Registry
+
+Goal:
+
+- Replace primarily manual Meeting Context authoring with an interactive
+  entity confirmation workflow backed by a persistent Entity Registry.
+
+Accepted architecture:
+
+```text
+Whisper
+    ↓
+Entity Detection
+    ↓
+User Confirmation
+    ↓
+Entity Registry Update
+    ↓
+Meeting Context Builder
+    ↓
+meeting_context.yaml
+    ↓
+Extraction Pipeline
+```
+
+Deliverables:
+
+- Persistent Entity Registry independent from individual meetings as the
+  cross-meeting knowledge source for confirmed entities, aliases and
+  organizational metadata.
+- Stable internal entity IDs for people, organizations, departments, products,
+  projects, locations and abbreviations.
+- First-class aliases, including spelling and transcription variants.
+- User confirmation UI/workflow for unknown names.
+- Meeting Context Builder that produces meeting-specific `meeting_context.yaml`
+  from registry entries, user confirmations and meeting metadata.
+- Generated `meeting_context.yaml` as the authoritative meeting-specific Point
+  of Truth and reproducible input artifact for each meeting run.
+- Similarity suggestions for spelling variants, Whisper variants, umlaut
+  handling and OCR-like mistakes.
+
+Prerequisites:
+
+- Agreement on the Entity Registry data model.
+- Review workflow for confirming unknown entities after Whisper transcription.
+- Meeting Context V1 remains the extraction interface until V2 is implemented.
+
+Current status:
+
+- Accepted Architecture.
+- Implementation deferred.
+
+Out of scope:
+
+- Autonomous learning.
+- Silent registry updates.
+- Registry overrides of explicit meeting-specific confirmations.
+- Silent changes to historical Meeting Context after Registry updates.
+- Inferring responsibility, decisions, ownership or attendance from registry
+  metadata.
+
+## Phase 5 - Output Views
+
+Goal:
+
+- Render purpose-specific outputs from Canonical Meeting Knowledge without
+  changing meaning.
+
+Deliverables:
+
+- Working Protocol / Arbeitsprotokoll renderer.
+- Distribution Protocol / Verteilerprotokoll renderer.
+- Knowledge Objects / Wissensdatenbankeintrag renderer or structured export.
+- Later additional views such as action lists.
+- Tests or checks showing that output views are parallel renderings of the same
+  canonical model.
+- Default output-language policy: rendered protocols normally match the
+  dominant source language unless explicitly requested otherwise.
+
+Prerequisites:
+
+- Implemented Canonical Meeting Knowledge.
+- Clear audience and completeness rules for each output view.
+
+Out of scope:
+
+- Additional analysis during rendering.
+- Deriving one output view from another.
+- Retrieval integration.
+
+## Phase 6 - Review and Quality Control
+
+Goal:
+
+- Add optional review stages that improve omission detection, consistency and
+  model selection.
+
+Deliverables:
+
+- Optional whole-transcript review.
+- Omission detection.
+- Consistency checks.
+- Model comparison workflow.
+- Hardware and runtime benchmarks.
+
+Prerequisites:
+
+- Stable extraction, semantic consolidation and canonical model.
+- Representative test meetings.
+
+Out of scope:
+
+- Automatic acceptance of review suggestions without evidence.
+- Product UI work.
+- Cloud deployment.
+
+## Phase 7 - Productization
+
+Goal:
+
+- Turn the validated pipeline into a usable local workflow.
+
+Deliverables:
+
+- Recording/transcription workflow.
+- FFmpeg integration.
+- Meeting metadata capture.
+- Participant entry.
+- Meeting Context V1 exists as a manually maintained YAML structure with
+  validation, optional extraction prompt integration and extraction provenance;
+  future work should add GUI entry and conservative integration with later
+  pipeline stages.
+- GUI.
+- Stable deployment process.
+- Export workflows.
+
+Prerequisites:
+
+- Stable pipeline stages and output views.
+- Clear operational requirements for local use.
+
+Out of scope:
+
+- Enterprise knowledge retrieval.
+- Future Meeting Assistant integration beyond export contracts.
+- Cloud-first architecture.
+
+## Phase 8 - Knowledge-System Integration
+
+Goal:
+
+- Reuse durable meeting knowledge in broader knowledge systems.
+
+Deliverables:
+
+- Structured Knowledge Objects.
+- Retrieval-ready storage format.
+- Future RAG integration path.
+- Reuse contracts for Meeting Assistant and other knowledge systems.
+
+Prerequisites:
+
+- Canonical Meeting Knowledge and Knowledge Objects are implemented and stable.
+- Durable knowledge is separated from meeting-specific actions and discussion
+  history.
+
+Out of scope:
+
+- Building a full enterprise search product inside Meeting Lab.
+- Treating raw transcripts or generated protocols as the knowledge source of
+  truth.

docs/adr-meeting-context-v2-entity-registry.md

@@ -0,0 +1,153 @@
+# ADR: Meeting Context V2 and Entity Registry
+
+Status: Accepted Architecture
+
+Implementation: Deferred
+
+Date: 2026-08-03
+
+## Context
+
+Meeting Context V1 proved that authoritative meeting context can significantly
+improve extraction quality. It helps the extractor normalize known aliases,
+identify participants and avoid treating context metadata as evidence for
+responsibility or decisions.
+
+End-to-end evaluation also showed that manually writing Meeting Context is not
+the right long-term primary workflow. The pipeline needs an earlier,
+interactive entity confirmation step after Whisper transcription. That step
+should identify candidate entities, ask the user to confirm them and then build
+the meeting-specific context from confirmed data.
+
+## Decision
+
+Meeting Context should evolve toward V2 as an authoritative,
+meeting-specific Point of Truth generated or assisted from a persistent Entity
+Registry, user confirmations and meeting metadata.
+
+Preferred future pipeline:
+
+```text
+Whisper
+    ↓
+Entity Detection
+    ↓
+User Confirmation
+    ↓
+Entity Registry Update
+    ↓
+Meeting Context Builder
+    ↓
+meeting_context.yaml
+    ↓
+Extraction Pipeline
+```
+
+The Entity Registry is the persistent cross-meeting knowledge source for
+confirmed entities, aliases and organizational metadata.
+
+For each individual meeting, `meeting_context.yaml` remains the authoritative
+meeting-specific Point of Truth and reproducible input artifact consumed by
+the extraction pipeline. Meeting Context V2 changes how this YAML is prepared,
+not its authority for a meeting run.
+
+The generated `meeting_context.yaml` is a meeting-specific snapshot. The
+Registry must not override explicit meeting-specific confirmations. Changes to
+the Registry after a meeting run must not silently change the historical
+Meeting Context used for that run.
+
+## Entity Registry
+
+The Entity Registry is the persistent cross-meeting knowledge source and is
+independent from individual meetings. It stores confirmed entities such as:
+
+- people
+- organizations
+- departments
+- products
+- projects
+- locations
+- abbreviations
+
+Each entity receives a stable internal identifier. The displayed name may
+change over time, but the identifier must remain stable.
+
+## Learning Principle
+
+The registry never learns automatically.
+
+It may propose matches, but only confirmed user actions update the registry.
+No autonomous learning is allowed.
+
+## Alias Handling
+
+Aliases are first-class data.
+
+Examples:
+
+```text
+Jovana
+Giovanna
+Jovanna
+Giovana
+```
+
+These variants may all refer to one confirmed entity. Future runs should
+automatically suggest previously confirmed aliases, but those suggestions still
+require explicit confirmation when they would update registry data.
+
+## Unknown Entities
+
+Previously unseen names are presented to the user for classification.
+
+Possible classifications:
+
+- meeting participant
+- mentioned person
+- external person
+- transcription error
+- ignore
+
+Nothing is automatically accepted.
+
+## Similarity Search
+
+Similarity search is a future extension. It can propose likely matches for:
+
+- spelling variants
+- Whisper transcription variants
+- umlaut handling
+- OCR-like mistakes
+
+Similarity suggestions require explicit confirmation.
+
+## Rationale
+
+Expected advantages:
+
+- significantly less manual work
+- earlier detection of transcription errors
+- robust alias handling
+- reusable organizational knowledge
+- improved Meeting Context quality
+- easier GUI workflow
+- better scalability across many meetings
+
+## Consequences
+
+Meeting Context V1 remains the current implemented interface.
+
+Meeting Context V2 should preserve the YAML interface for extraction.
+`meeting_context.yaml` remains the authoritative meeting-specific Point of
+Truth and reproducible input artifact for a meeting run. The Entity Registry is
+the persistent cross-meeting knowledge source used to prepare that artifact.
+
+The Registry must not override explicit meeting-specific confirmations. Changes
+to the Registry after a meeting run must not silently change the historical
+Meeting Context used for that run.
+
+The registry must not infer responsibility, decisions, attendance or ownership.
+Those still require meeting evidence and remain governed by the existing
+responsibility attribution invariant.
+
+No implementation is part of this ADR.

docs/architecture.md

@@ -2,13 +2,63 @@
 
 ## Purpose
 
-The **Meeting Lab** is an experimental environment for developing and evaluating methods to extract structured knowledge from real meeting transcripts.
+The **Meeting Lab** is the experimental R&D environment for developing and
+evaluating methods to extract structured knowledge from real meeting
+transcripts. It is the research platform, architecture playground, regression
+framework, benchmark environment and prototype implementation for the future
+Meeting Assistant.
 
 Its purpose is not to build a complete meeting assistant, but to answer a single question:
 
 > **How can knowledge be extracted from real discussions as reliably as possible?**
 
-Successful approaches will later be integrated into the Meeting Assistant project.
+Its purpose is to validate ideas before they are promoted into the product.
+Only sufficiently mature and verified components should migrate into Meeting
+Assistant. Meeting Lab may intentionally contain experiments or development
+branches that are rejected, remain inconclusive or never reach the Assistant.
+
+## Meeting Lab and Meeting Assistant lifecycle
+
+Meeting Lab and Meeting Assistant have different long-term responsibilities:
+
+- **Meeting Lab** is the long-term innovation branch. It favors learning,
+  inspectable experiments, regression evidence, benchmarks and architectural
+  change.
+- **Meeting Assistant** is the stable product branch. It favors a polished user
+  experience, installation, configuration and a production pipeline.
+
+Architectural promotion follows an evidence-based lifecycle:
+
+```text
+Research idea
+    ->
+Meeting Lab experiment
+    ->
+Regression tests
+    ->
+Stable architecture
+    ->
+Meeting Assistant implementation
+```
+
+The expected release progression is:
+
+```text
+Meeting Lab Alpha
+    ->
+Meeting Lab Beta
+    ->
+Meeting Assistant Beta
+    ->
+Meeting Assistant Release
+```
+
+The first public Meeting Assistant beta should be based on a stable Meeting
+Lab MVP. It should provide a polished user experience, an installer,
+configuration and a production-quality pipeline. A GUI is optional.
+Experimental features should not be enabled by default. Meeting Lab continues
+to evolve independently after components have migrated; promotion does not
+turn the Lab itself into the product branch.
 
 ---
 
@@ -47,6 +97,20 @@ Every processing step should be understandable.
 
 Intermediate results should remain inspectable throughout the pipeline.
 
+## Responsibility Attribution Integrity
+
+Responsibility, ownership, organizational roles and action-item assignments may
+be recorded only when meeting evidence explicitly assigns, accepts or confirms
+them.
+
+The system must not infer responsibility from thematic proximity,
+participation in a discussion, mentioning a task, commenting on another
+department, organizational assumptions, likely job roles, speaker adjacency or
+model world knowledge.
+
+When evidence is incomplete or ambiguous, the responsible person remains unset
+or unclear and the supporting evidence is preserved.
+
 ## Reproducible Experiments
 
 Experiments must be repeatable.
@@ -85,6 +149,8 @@ The analyzer gradually transforms an unstructured discussion into structured kno
 
 # High-Level Pipeline
 
+Current implemented and intended analysis flow:
+
 ```text
 Transcript
     ↓
@@ -98,11 +164,33 @@ Topic Segmentation
     ↓
 Specialized Extraction
     ↓
-Consolidation
+Deterministic Canonicalization
     ↓
-Structured Meeting Data
+Semantic Consolidation
     ↓
-Protocol Generation
+Canonical Meeting Knowledge
+    ↓
+Output View Rendering
+    ↓
+Working Protocol / Distribution Protocol / Knowledge Objects
+```
+
+Accepted future Meeting Context V2 preparation flow:
+
+```text
+Whisper
+    ↓
+Entity Detection
+    ↓
+User Confirmation
+    ↓
+Entity Registry Update
+    ↓
+Meeting Context Builder
+    ↓
+meeting_context.yaml
+    ↓
+Extraction Pipeline
 ```
 
 Each stage solves one clearly defined problem.
@@ -170,26 +258,124 @@ Each extractor has exactly one task and one prompt.
 
 ---
 
+## Meeting Context
+
+Meeting Context V1 is a manually maintained YAML scaffold for reliable meeting
+metadata such as title, language, participants, aliases, departments,
+abbreviations and known entities.
+
+It is documented in `docs/meeting-context.md` and templated at
+`samples/templates/meeting_context.template.yaml`. It is implemented for
+loading, validation and optional injection into chunk extraction prompts.
+Extraction results record only minimal context provenance. It is not yet
+connected to consolidation, Canonical Meeting Knowledge or output rendering.
+
+The context can help prevent non-participants from being interpreted as
+attendees and can normalize known aliases for extraction. It must not infer
+roles, departments, responsibilities or decisions.
+
+Accepted future direction:
+
+Meeting Context V2 should be generated or assisted from an interactive entity
+confirmation workflow and a persistent Entity Registry. The Entity Registry is
+the persistent cross-meeting knowledge source for confirmed people,
+organizations, departments, products, projects, locations, aliases and
+organizational metadata under stable internal IDs. Display names may change,
+but internal IDs remain stable. Aliases are first-class data.
+
+The registry never learns automatically. It may propose matches and aliases,
+including spelling variants, Whisper transcription variants, umlaut variants
+and OCR-like mistakes, but only explicit user confirmation updates registry
+state. Unknown names should be presented to the user as meeting participant,
+mentioned person, external person, transcription error or ignore.
+
+In this architecture, `meeting_context.yaml` remains the authoritative
+meeting-specific Point of Truth and reproducible input artifact consumed by the
+extraction pipeline. It is a meeting-specific snapshot built from the Entity
+Registry, user confirmations and meeting metadata. The Registry must not
+override explicit meeting-specific confirmations, and Registry changes after a
+meeting run must not silently change the historical Meeting Context used for
+that run.
+
+Status: Accepted Architecture; implementation deferred. See
+`docs/adr-meeting-context-v2-entity-registry.md`.
+
+---
+
 ## consolidation/
 
-Merges information extracted from multiple discussion segments.
+Planned area for canonicalization and consolidation.
 
-Typical responsibilities:
+The next milestone splits this into two stages.
 
-- merge duplicates
-- combine partial information
-- distinguish positions from decisions
-- detect contradictions
+Deterministic Canonicalizer:
+
+- implemented in Python
+- uses no LLM
+- validates and normalizes extraction objects
+- assigns stable source references and IDs
+- normalizes category names and basic field structure
+- validates and normalizes action-item responsible fields against Meeting
+  Context when available: known participant and mentioned-person aliases are
+  normalized to canonical display names, while dates, locations, projects,
+  products, technical terms, generic process words and unknown free text are
+  cleared with a structured validation record
+- performs only safe deterministic cleanup
+- may group exact duplicates
+- preserves all source evidence
+- must not perform uncertain semantic merging
+
+Semantic Consolidator:
+
+- uses the local LLM
+- V0 is implemented for facts-only semantic duplicate detection
+- V0 merges semantically equivalent fact items conservatively
+- V0 preserves source references and evidence
+- V0 validates that every source fact appears exactly once
+- V0 sizes its Ollama output budget from the actual fact payload instead of
+  using a fixed response cap for every meeting
+- V0 may apply deterministic source-coverage repair after valid model JSON is
+  parsed: duplicate source IDs are removed after their first occurrence, empty
+  groups are removed and missing source facts are restored as singleton groups
+  from canonicalized input before strict validation runs
+- V0 does not process non-fact categories semantically
+- later versions should group content by topic, mark contradictions and
+  uncertainty, separate durable information from transient discussion and
+  prepare Canonical Meeting Knowledge
+- does not directly write a protocol
 
 ---
 
 ## protocol/
 
-Generates human-readable output from structured meeting data.
+Generates output views from Canonical Meeting Knowledge.
 
-Protocol generation never invents information.
+Output generation never invents information.
 
-It only reformulates the analysis results.
+It only reformulates the analysis results for a specific audience and purpose.
+Depending on the output and maturity of the implementation, a renderer may be
+deterministic, template-based or LLM-assisted.
+
+LLM-assisted renderers preserve raw model output separately and write the final
+output artifact only after deterministic contract validation succeeds. Renderer
+post-processing may remove non-semantic wrapper text, but must not fabricate
+missing semantic sections or relabel an invalid summary as a valid output view.
+
+The planned output products are:
+
+- Working Protocol (`working_protocol.md`, Arbeitsprotokoll)
+- Distribution Protocol (`distribution_protocol.md`,
+  Verteilerprotokoll)
+- Knowledge Objects, which may be rendered as a Knowledge-base Entry
+  (`knowledge_entry.md`) and later stored in a structured format such as
+  `knowledge_entry.json` (Wissensdatenbankeintrag)
+
+These are parallel renderings of the same canonical semantic model, not
+documents derived from one another.
+
+Rendered protocol language should normally match the dominant language of the
+source transcript or consolidated meeting knowledge unless an explicit output
+language is requested.
 
 ---
 
@@ -214,11 +400,150 @@ Examples:
 - segmentation.md
 - prompts.md
 - experiments.md
+- output-views.md
 
 The architecture document only describes the overall system.
 
 ---
 
+# Version 2 Accepted Architectural Direction
+
+The following topics are accepted architectural goals for Version 2. They
+record direction reached through the BUG-011 through BUG-015 investigations;
+they are not descriptions of implemented behavior or authorization to change
+the current pipeline.
+
+## Speaker diarization before semantic analysis
+
+Version 2 should determine **who is speaking before semantic analysis**.
+Speaker identity contains evidence that cannot reliably be reconstructed from
+text alone. It helps distinguish, for example, who answers a question, accepts
+work, agrees with a proposal, or advances the discussion after another
+speaker. It also preserves conversational flow that anonymous transcript text
+can erase.
+
+Diarization is therefore a semantic prerequisite in the intended Version 2
+architecture, not merely a display enhancement. Its output should remain
+traceable to transcript segments so later stages can preserve speaker and
+source provenance.
+
+## Persistent speaker identification
+
+Version 2 should add a persistent speaker database and an interactive identity
+workflow during import:
+
+```text
+Unknown speaker detected
+    ->
+Representative audio sample (approximately 20 seconds)
+    ->
+User selects an existing identity or creates a new identity
+    ->
+Known speaker available for future recognition
+```
+
+Automatic recognition may suggest an identity, but user confirmation governs
+the persistent association. Over the long term, speaker embeddings rather
+than raw meeting recordings should be the persistent recognition
+representation. Representative raw audio is an import and confirmation aid,
+not the intended durable identity store. Privacy, deletion and false-match
+handling require separate design before implementation.
+
+## Meeting Context as a probabilistic prior
+
+Known meeting participants should influence semantic interpretation, but
+Meeting Context is a **probabilistic prior**, not a deterministic semantic
+rule. It can make one interpretation more plausible and help focus review; it
+must never manufacture a commitment, decision or responsibility assignment.
+
+For example, if Marleen is confirmed as present, “Marleen müsste sich mal
+äußern” is more likely to be conversation management directed at a current
+participant than future project work. Presence alone does not prove this
+interpretation, and it does not establish an Action Item or responsibility.
+Explicit meeting evidence remains authoritative. This extends, rather than
+weakens, the responsibility attribution invariant.
+
+The existing Meeting Context V2 entity direction is documented in
+[`adr-meeting-context-v2-entity-registry.md`](adr-meeting-context-v2-entity-registry.md).
+Speaker identities and meeting-specific participant confirmation should
+eventually feed that context without turning registry metadata into semantic
+facts.
+
+## Conversation Management versus Meeting Content
+
+BUG-015 reinforced that not every utterance is protocol-worthy content.
+Version 2 should conceptually distinguish:
+
+- **Conversation Management**: utterances that coordinate the meeting itself,
+  such as asking a present participant to speak, moderation, requesting a
+  slide, or asking someone to repeat something.
+- **Meeting Content**: propositions that may contribute to the meeting's
+  durable knowledge, including facts, technical findings, decisions, action
+  items and open questions.
+
+This is an architectural concept, not a currently implemented category or
+filter. The distinction should prevent conversational coordination from being
+promoted into project commitments while retaining sufficient provenance to
+understand dialogue. Context and diarization can inform the distinction, but
+neither should act as a deterministic keyword or participant rule.
+
+## Evidence and commitment before protocol eligibility
+
+The BUG-015 design study concludes that semantic state should be classified
+before policy determines whether an item is eligible for a protocol. A binary
+keep/reject verifier conflates evidence recognition with publication policy
+and loses valid intermediate states.
+
+The proposed decision progression is:
+
+```text
+idea -> option -> proposal -> preferred option -> tentative agreement -> decision
+```
+
+The proposed action progression is:
+
+```text
+possible next step -> recommendation -> requested action
+    -> established action -> ongoing work -> completed
+```
+
+Questions combine a communicative **kind** with an independent **resolution
+state**, rather than treating every uncertainty or interrogative as an Open
+Question. Responsibility remains an independent dimension and may be recorded
+only when explicitly assigned, accepted or confirmed. Evidence strength is
+also independent: it describes support for a semantic label, not semantic
+maturity or protocol eligibility.
+
+After semantic state classification, explicit policy should select Decisions,
+Action Items and Open Questions for a particular output view. Renderers should
+receive policy-selected semantic content and must not promote proposals or
+conversation management into commitments. The complete taxonomy, trade-offs,
+architecture interactions and migration questions are recorded in
+[`design/evidence_commitment_model.md`](design/evidence_commitment_model.md).
+
+## Topic-oriented primary protocol
+
+One of the highest-level Version 2 requirements is:
+
+> **The protocol is primarily a topic-oriented reconstruction of the meeting, not a category-oriented listing of extracted information.**
+
+Semantic categories remain metadata and supporting structure within topics;
+they must not dictate the main document structure. The conceptual target flow
+is `Transcript -> Evidence Extraction -> Topic Reconstruction -> Semantic
+Synthesis -> Protocol Rendering`. The primary renderer should eventually
+receive topic-oriented semantic knowledge. Category-oriented Action Item,
+Decision, Open Question and management views remain useful derived outputs.
+
+The detailed rationale, example, architectural implications and explicit
+deferral of a final Topic Reconstruction schema are documented in
+[`design/evidence_commitment_model.md`](design/evidence_commitment_model.md#thematic-protocol-as-the-primary-structure).
+
+Implementation is intentionally postponed until this architecture has been
+reviewed. No Version 2 goal in this section changes current extraction,
+canonicalization, consolidation or rendering behavior.
+
+---
+
 # Current State
 
 Implemented:
@@ -226,29 +551,99 @@ Implemented:
 - Transcript normalization
 - Technical chunk generation
 - Experimental LLM-based information extraction
+- Meeting Context V1 loading, validation and extraction prompt integration
+- Canonicalizer V1 deterministic extraction canonicalization
 
 The current extraction step still performs multiple tasks simultaneously.
 
 This was sufficient as a proof of concept but does not reflect the intended long-term architecture.
 
+The current protocol builder is also an interim implementation. It concatenates
+extraction results into `meeting_protocol.md` for technical validation. The
+planned architecture separates Canonical Meeting Knowledge from the final Output
+Views documented in `output-views.md`.
+
+## Extraction classification contract
+
+Decision, Action Item and Open Question extraction shares one evidence-oriented
+classification contract. It is placed after the transcript so it remains the
+final classification instruction in the single multi-category extraction call.
+Decisions require a settled outcome; Action Items require established work;
+Open Questions require a concrete unresolved need. Unsupported candidates must
+not be moved into another category.
+
+Action existence and responsibility attribution are separate checks. A valid
+Action Item may have no known owner, while a named owner requires explicit
+assignment, volunteering or acceptance. These are semantic LLM classifications;
+deterministic validation must not guess intent from keywords.
+
+### Classification Verifier
+
+Before extraction output is normalized for Canonicalizer input, Decision,
+Action Item and Open Question candidates pass through a semantic precision
+gate. Facts and technical details pass through unchanged. Each candidate is
+reviewed independently with its evidence and bounded local chunk context; the
+verifier may only keep or reject the existing candidate. It cannot add or
+rewrite semantic items.
+
+Verifier output contains the stable candidate ID, category, `keep|reject`
+verdict, evidence-based reason and `responsibility_supported`. A kept Action
+Item with an unsupported named owner is retained with its responsibility
+cleared. Malformed output fails the extraction verification substage closed,
+after preserving candidate input and raw response. Per-candidate results and an
+aggregate audit remain traceable before Canonicalizer input is written.
+
+## Semantic Consolidator failure handling
+
+Semantic Consolidator V0 preserves every raw model response before parsing.
+Its normal path accepts parseable grouping JSON and leaves duplicate source-ID
+unknown-source-ID and missing-source-ID correction to the deterministic
+coverage repair. Unknown source IDs are removed without attempting numeric or
+semantic remapping. A group retains its valid IDs and remains present when at
+least one valid ID survives. A group containing only unknown IDs is removed
+after it becomes empty. Existing coverage repair then restores every genuinely
+missing canonical fact as a singleton. Strict validation runs against the
+repaired result and still rejects any unknown ID that survives this process.
+
+An invalid or truncated response is not retried by default. One controlled
+retry is allowed only when deterministic inspection finds at least three
+consecutive complete groups with an identical structural signature:
+`canonical_text`, ordered `source_item_ids` and `merge_reason`. The retry keeps
+the same model, temperature, context window and generation limit and adds only
+an instruction not to emit an identical group more than once. Both attempts
+and the detected repetition metadata are preserved. If the retry also fails,
+the stage fails normally; it does not make another LLM call.
+
+## Working Protocol V2 renderer contract
+
+The renderer deterministically projects consolidated items to the semantic
+fields required for presentation and omits bulky provenance fields from the
+LLM request. Every renderable item remains represented; structurally empty
+items are recorded separately rather than turned into invented prose. The
+compact renderer input is preserved as an artifact.
+
+The exact Markdown structure is generated from the same heading constants used
+by the validator and appended after the renderer input so it remains visible
+within the evaluated context. Decisions, action items and open questions carry
+input-derived hidden coverage markers. Strict validation requires every such
+renderable priority item exactly once in its matching section and rejects
+missing, duplicate, wrong-section or invented markers. Facts and technical
+details remain condensable as background.
+
+Renderer output budgeting is adaptive to required priority content and prompt
+size, while an explicit `num_predict` override remains authoritative. Raw model
+output is always preserved, and `working_protocol.md` is written only after
+strict structure and coverage validation passes. The renderer does not retry
+automatically.
+
 ---
 
 # Next Milestone
 
-The next development step is the implementation of **topic segmentation**.
-
-Its only responsibility is to identify the thematic structure of a discussion.
-
-It should answer questions such as:
-
-- Where does a topic begin?
-- Where does it end?
-- When does another topic start?
-- When is an earlier topic resumed?
-
-No facts, decisions or todos should be extracted at this stage.
-
-Only after reliable topic segmentation has been achieved will the specialized extraction modules be implemented.
+The next architecture milestone is the implementation of a deterministic
+canonicalization stage followed by a semantic consolidation stage. These stages
+convert raw chunk extraction JSON into evidence-preserving Canonical Meeting
+Knowledge before any Output View renderer writes a protocol.
 
 ---
 
@@ -256,4 +651,4 @@ Only after reliable topic segmentation has been achieved will the specialized ex
 
 The Meeting Lab assumes that the greatest improvement in transcript quality will not come from increasingly powerful language models.
 
-Instead, quality is expected to emerge from a pipeline that decomposes a complex problem into many small, clearly defined and independently testable processing steps.
+Instead, quality is expected to emerge from a pipeline that decomposes a complex problem into many small, clearly defined and independently testable processing steps.

docs/bug-003-root-cause.md

@@ -0,0 +1,265 @@
+# BUG-003 Root Cause Analysis
+
+## Observed Behaviour
+
+The final working protocol contains two names that were flagged as not
+belonging to the real meeting:
+
+- `Guido`
+- `Noah`
+
+Observed output:
+
+- `samples/benchmarks/meeting_context_v1/final_protocol_with_context/working_protocol.md:36`
+  contains `Einbinden der Fachbereiche (stellvertretend durch Guido) zur
+  Definition von Prüfsteinen.`
+- `samples/benchmarks/meeting_context_v1/final_protocol_with_context/working_protocol.md:44`
+  contains `Sollte ein eigener Prozess für Noah (Business Development)
+  benötigt werden oder reicht der bestehende?`
+
+## Evidence
+
+The names are present in the final renderer raw response as well as
+`working_protocol.md`:
+
+- `samples/benchmarks/meeting_context_v1/final_protocol_with_context/raw_model_response.txt:36`
+  contains `Guido`
+- `samples/benchmarks/meeting_context_v1/final_protocol_with_context/raw_model_response.txt:44`
+  contains `Noah`
+
+They are also present before rendering in the repaired consolidated input:
+
+- `samples/benchmarks/meeting_context_v1/semantic_consolidator_repair_v1/consolidated_extractions.json:1047`
+  contains the open question text with `Noah`
+- `samples/benchmarks/meeting_context_v1/semantic_consolidator_repair_v1/consolidated_extractions.json:1048`
+  contains evidence `Oder brauchen wir einen eigenen Prozess bei Noah?`
+- `samples/benchmarks/meeting_context_v1/semantic_consolidator_repair_v1/consolidated_extractions.json:1537`
+  contains the action item text with `Guido`
+
+They are present before semantic consolidation in the canonicalized output:
+
+- `samples/benchmarks/meeting_context_v1/canonicalizer/canonicalized_extractions.json:411`
+  contains the open question text with `Noah`
+- `samples/benchmarks/meeting_context_v1/canonicalizer/canonicalized_extractions.json:412`
+  contains evidence `Oder brauchen wir einen eigenen Prozess bei Noah?`
+- `samples/benchmarks/meeting_context_v1/canonicalizer/canonicalized_extractions.json:1401`
+  contains the action item text with `Guido`
+
+They are present before canonicalization in extraction output and raw model
+responses:
+
+- `samples/benchmarks/meeting_context_v1/full_context_run/chunk_02_extraction.json:18`
+  contains the extracted open question with `Noah`
+- `samples/benchmarks/meeting_context_v1/full_context_run/chunk_02_extraction.raw.txt:76`
+  contains the same raw model output question with `Noah`
+- `samples/benchmarks/meeting_context_v1/full_context_run/chunk_07_extraction.json:11`
+  contains the extracted todo with `Guido`
+- `samples/benchmarks/meeting_context_v1/full_context_run/chunk_07_extraction.raw.txt:53`
+  contains the same raw model output todo with `Guido`
+
+They are present before extraction in the reconstructed normalized chunks:
+
+- `samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_02_normalized.txt:79`
+  contains `Oder brauchen wir einen eigenen Prozess bei Noah?`
+- `samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_07_normalized.txt:213`
+  contains `Guido`
+
+They are present before normalization in reconstructed raw chunks:
+
+- `samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_02.txt:79`
+  contains `Oder brauchen wir einen eigenen Prozess bei Noah?`
+- `samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_07.txt:213`
+  contains `Guido`
+
+They are present in the source cleaned Whisper transcript used to reconstruct
+the chunks:
+
+- `samples/real_live/project_process_meeting/transcript/meeting_speech_cleaned.json:5783`
+  has segment text `Oder brauchen wir einen eigenen Prozess bei Noah?`
+- `samples/real_live/project_process_meeting/transcript/meeting_speech_cleaned.json:26315`
+  has segment text `Guido`
+
+Segment-level verification:
+
+- `Noah`: segment `id=182`, `start=899.6400000000001`, `end=901.94`,
+  text `Oder brauchen wir einen eigenen Prozess bei Noah?`
+- `Guido`: segment `id=776`, `start=4157.86`, `end=4160.14`, text `Guido`
+
+The original Whisper transcript also contains both names:
+
+- `samples/real_live/project_process_meeting/transcript/meeting_speech.json:1`
+  contains both `Noah` and `Guido` in the top-level transcript text and segment
+  data.
+
+Meeting Context does not contain either name:
+
+- `rg -n "Guido|Noah" samples/real_live/project_process_meeting/meeting_context.yaml`
+  returned no matches.
+
+Prompt files do not contain either name:
+
+- `rg -n "Guido|Noah" prompts`
+  returned no matches.
+
+## Earliest Pipeline Stage Containing the Names
+
+The earliest verified pipeline artifact containing the names is the Whisper
+transcript stage:
+
+- `samples/real_live/project_process_meeting/transcript/meeting_speech.json`
+- `samples/real_live/project_process_meeting/transcript/meeting_speech_cleaned.json`
+
+For the reconstructed benchmark specifically, the earliest input used by the
+TODO 4 pipeline is:
+
+- `samples/real_live/project_process_meeting/transcript/meeting_speech_cleaned.json`
+
+The reconstructed chunks preserve the names from that cleaned Whisper JSON.
+Extraction, canonicalization, consolidation and rendering propagate them.
+
+## Repository Search Results
+
+Repository search for `Guido|Noah` found these occurrence groups:
+
+- `docs/regression-bugs.md`: tracker entry for BUG-003 mentions both names.
+- `tests/gold/responsibility_attribution_negative/transcript.txt`: contains
+  `Noah` in a synthetic gold scenario.
+- `tests/gold/responsibility_attribution_negative/expected.json`: contains
+  expected `Noah` entries for that synthetic gold scenario.
+- `samples/real_live/project_process_meeting/transcript/meeting_speech.json`:
+  contains `Noah` and `Guido`.
+- `samples/real_live/project_process_meeting/transcript/meeting_speech_cleaned.json`:
+  contains `Noah` and `Guido`.
+- `samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_02.txt`
+  and `chunk_02_normalized.txt`: contain `Noah`.
+- `samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_07.txt`
+  and `chunk_07_normalized.txt`: contain `Guido`.
+- `samples/benchmarks/meeting_context_v1/full_context_run/chunk_02_extraction.json`
+  and `chunk_02_extraction.raw.txt`: contain `Noah`.
+- `samples/benchmarks/meeting_context_v1/full_context_run/chunk_07_extraction.json`
+  and `chunk_07_extraction.raw.txt`: contain `Guido`.
+- `samples/benchmarks/meeting_context_v1/canonicalizer/canonicalized_extractions.json`:
+  contains both names.
+- `samples/benchmarks/meeting_context_v1/semantic_consolidator_repair_v1/consolidated_extractions.json`:
+  contains both names.
+- `samples/benchmarks/meeting_context_v1/final_protocol_with_context/raw_model_response.txt`
+  and `working_protocol.md`: contain both names.
+- `samples/benchmarks/meeting_context_v1/final_protocol_with_context/comparison.md`:
+  mentions `Noah` in the evaluation notes.
+
+Search results did not find `Guido` or `Noah` in:
+
+- `prompts/`
+- `samples/real_live/project_process_meeting/meeting_context.yaml`
+- `src/`
+
+## Prompt Inspection
+
+Renderer prompt:
+
+- `samples/benchmarks/meeting_context_v1/final_protocol_with_context/metadata.json`
+  records `prompt_file: "prompts/working_protocol.md"` and
+  `input_source:
+  "samples/benchmarks/meeting_context_v1/semantic_consolidator_repair_v1/consolidated_extractions.json"`.
+- `prompts/working_protocol.md` contains no few-shot examples and no `Guido` or
+  `Noah` occurrences.
+
+Extraction prompt assembly:
+
+- `src/meeting_lab/llm/prompts.py` builds extraction prompts from
+  `prompts/common.md`, optional Meeting Context, explicitly requested task
+  prompts and the provided transcript.
+- `src/meeting_lab/extraction/extract_chunks.py` calls that shared builder with
+  `decisions.md` and `todos.md` as task prompts.
+
+Semantic Consolidator prompt assembly:
+
+- `src/meeting_lab/consolidation/consolidate_facts.py` builds its prompt from
+  `prompts/consolidate_facts.md` plus the canonicalized fact payload.
+
+Gold/test prompt inspection:
+
+- `tests/gold/responsibility_attribution_negative/` contains synthetic `Noah`
+  examples.
+- `scripts/run_gold_test.py` is a gold-test runner and reads
+  `scenario_dir / "transcript.txt"` when explicitly invoked.
+- The inspected production metadata for the TODO 4 extraction run records
+  `input_path` values under
+  `samples/benchmarks/meeting_context_v1/source_reconstruction/`, not
+  `tests/gold/`.
+- The inspected renderer metadata records only the repaired consolidated JSON
+  and `prompts/working_protocol.md`.
+
+No evidence was found that few-shot examples, embedded examples, test
+transcripts or gold scenarios became part of the production prompt for this
+benchmark run.
+
+## Pipeline Verification
+
+The persisted metadata verifies the production execution path:
+
+- `chunk_02_extraction.metadata.json` input:
+  `samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_02_normalized.txt`
+- `chunk_07_extraction.metadata.json` input:
+  `samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_07_normalized.txt`
+- both extraction metadata files record Meeting Context source:
+  `samples/real_live/project_process_meeting/meeting_context.yaml`
+- `canonicalizer/metadata.json` records input directory:
+  `samples/benchmarks/meeting_context_v1/full_context_run`
+- `semantic_consolidator_repair_v1/report.md` records output:
+  `samples/benchmarks/meeting_context_v1/semantic_consolidator_repair_v1/consolidated_extractions.json`
+- `final_protocol_with_context/metadata.json` records renderer input:
+  `samples/benchmarks/meeting_context_v1/semantic_consolidator_repair_v1/consolidated_extractions.json`
+  and prompt file `prompts/working_protocol.md`
+
+No execution metadata points to unrelated examples, templates, tests or gold
+scenarios.
+
+## Verified Root Cause
+
+The verified root cause for BUG-003 in this pipeline run is upstream transcript
+contamination: `Guido` and `Noah` already exist in the Whisper transcript and
+the cleaned Whisper transcript used as the benchmark source.
+
+The later stages did not introduce these names from prompts, Meeting Context,
+gold tests or renderer examples. They propagated names already present in the
+pipeline input:
+
+`meeting_speech.json`
+-> `meeting_speech_cleaned.json`
+-> reconstructed chunks
+-> extraction JSON
+-> canonicalized JSON
+-> repaired consolidated JSON
+-> final working protocol
+
+What cannot be established from repository artifacts alone:
+
+- whether Whisper hallucinated these names from audio
+- whether the source audio actually contains words that sound like these names
+- what the correct intended tokens should be
+
+Those questions require audio-level or human-transcript verification and are
+outside the evidence available in this repository trace.
+
+## Confidence
+
+High
+
+The conclusion that the final protocol names originated before extraction is
+directly supported by persisted source transcript, chunk, extraction,
+canonicalization, consolidation and renderer artifacts.
+
+The confidence does not extend to identifying the correct replacement words.
+That remains unverified.
+
+## Recommended Fix
+
+Conceptually, add a transcript/source-quality validation step before extraction
+that flags person or organization names not present in Meeting Context or an
+approved alias list. The step should preserve the original transcript text, but
+mark suspicious entity mentions for review before they become structured
+knowledge and final protocol content.
+
+Do not treat gold scenarios or prompt examples as the root cause for this bug;
+the evidence does not support that.

docs/bug-005-root-cause.md

@@ -0,0 +1,198 @@
+# BUG-005 Root Cause Analysis
+
+## Observed Behaviour
+
+The final working protocol treats Björn as one of the "fehlende Teilnehmer":
+
+- `samples/benchmarks/meeting_context_v1/final_protocol_with_context/working_protocol.md:53`
+
+This contradicts Meeting Context, which lists Björn as an actual participant
+with `attendance_status: "present"`:
+
+- `samples/real_live/project_process_meeting/meeting_context.yaml:45`
+- `samples/real_live/project_process_meeting/meeting_context.yaml:52`
+
+## Evidence
+
+Meeting Context marks Björn present:
+
+```text
+participant_id: "bjoern"
+display_name: "Björn"
+role: "Leiter Marketing"
+attendance_status: "present"
+```
+
+The extraction prompt path does include Meeting Context:
+
+- `src/meeting_lab/extraction/extract_chunks.py:161` renders Meeting Context
+  for the prompt when it is supplied.
+- `src/meeting_lab/models/meeting_context.py:108` renders the heading
+  `MEETING CONTEXT V1 (AUTHORITATIVE METADATA)`.
+- `src/meeting_lab/models/meeting_context.py:112` renders the rule
+  `The participant list is authoritative.`
+- `src/meeting_lab/models/meeting_context.py:128` to
+  `src/meeting_lab/models/meeting_context.py:132` renders actual
+  participants.
+
+Execution metadata confirms chunk 08 used the Meeting Context file:
+
+- `samples/benchmarks/meeting_context_v1/full_context_run/chunk_08_extraction.metadata.json:29`
+  to `:32`
+- `samples/benchmarks/meeting_context_v1/full_context_run/chunk_08_extraction.metadata.json:34`
+  to `:38`
+
+The source chunk does not say Björn was absent from the meeting. It says
+Giovanna and Björn had not yet understood or reviewed the discussed mail or
+process state:
+
+- `samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_08_normalized.txt:211`
+  to `:215`
+- `samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_08_normalized.txt:229`
+  to `:245`
+- `samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_08_normalized.txt:257`
+  to `:267`
+
+The earliest generated artifact that treats Björn as absent is the raw chunk
+08 extraction response:
+
+- `samples/benchmarks/meeting_context_v1/full_context_run/chunk_08_extraction.raw.txt:4`
+  summarizes "Einbeziehung fehlender Teilnehmer wie Jovana und Björn".
+- `samples/benchmarks/meeting_context_v1/full_context_run/chunk_08_extraction.raw.txt:6`
+  to `:10` lists participants as only Martin, Lars and Malte.
+- `samples/benchmarks/meeting_context_v1/full_context_run/chunk_08_extraction.raw.txt:64`
+  to `:68` emits the open question
+  `Wie sollen fehlende Teilnehmer (Jovana, Björn) in den Prozess einbezogen werden?`
+
+The persisted extraction JSON keeps that open question:
+
+- `samples/benchmarks/meeting_context_v1/full_context_run/chunk_08_extraction.json:14`
+  to `:16`
+
+The persisted extraction JSON records only Meeting Context provenance, not the
+participant list or attendance status:
+
+- `samples/benchmarks/meeting_context_v1/full_context_run/chunk_08_extraction.json:23`
+  to `:27`
+
+The normalizer drops raw response fields such as `participants` and `topics`:
+
+- `src/meeting_lab/extraction/extract_chunks.py:318` to `:365` returns only
+  normalized `facts`, `decisions`, `todos`, `questions`, `positions` and
+  `technical`.
+- `src/meeting_lab/extraction/extract_chunks.py:432` to `:434` adds only
+  provenance from Meeting Context after normalization.
+
+Canonicalizer preserves the bad open question:
+
+- `samples/benchmarks/meeting_context_v1/canonicalizer/canonicalized_extractions.json:1633`
+  to `:1645`
+
+Semantic Consolidator output also preserves the bad open question:
+
+- `samples/benchmarks/meeting_context_v1/semantic_consolidator_repair_v1/consolidated_extractions.json:1669`
+  to `:1681`
+
+The renderer receives the repaired consolidated JSON as its only recorded
+input:
+
+- `samples/benchmarks/meeting_context_v1/final_protocol_with_context/metadata.json:2`
+  to `:4`
+
+The renderer prompt requires using only the provided input:
+
+- `prompts/working_protocol.md:7` to `:12`
+
+Therefore the renderer did not receive Meeting Context attendance metadata
+that would let it distinguish a present participant from a mentioned-only or
+absent person.
+
+## Stage-by-Stage Verification
+
+1. Does extraction receive Björn as a present participant?
+
+Yes. The extraction code renders Meeting Context into the prompt when supplied,
+and the chunk 08 metadata records
+`samples/real_live/project_process_meeting/meeting_context.yaml` as the Meeting
+Context source.
+
+2. Does extraction output preserve that information?
+
+No. The raw chunk 08 response lists participants as Martin, Lars and Malte
+only, despite Björn being present in Meeting Context. The official persisted
+extraction JSON contains only a minimal `context` provenance object and does
+not preserve the authoritative participant list or attendance status.
+
+3. Does Canonicalizer preserve it?
+
+No. Canonicalizer input lacks the participant list and attendance status. The
+Canonicalizer preserves the already bad open question from chunk 08.
+
+4. Does Semantic Consolidator preserve it?
+
+No. The repaired consolidated JSON lacks Meeting Context participant metadata
+and preserves the bad open question.
+
+5. Does the Renderer receive enough information to distinguish present from
+mentioned-only participants?
+
+No. Renderer metadata records only
+`semantic_consolidator_repair_v1/consolidated_extractions.json` as input, and
+that file contains no Meeting Context participant list or attendance status.
+
+## Earliest Failing Pipeline Stage
+
+The earliest failing stage is chunk extraction for
+`chunk_08_normalized.txt`.
+
+More precisely, the raw model response for chunk 08 is the first artifact that
+both omits Björn from the participant list and groups Björn with absent or
+"fehlende" participants.
+
+## Verified Root Cause
+
+The immediate root cause is ignored Meeting Context metadata during extraction
+for chunk 08. The extraction model received authoritative Meeting Context, but
+interpreted transcript evidence about not having reviewed or understood an
+email/process state as meeting absence.
+
+The downstream cause is missing propagation of participant attendance metadata.
+After extraction, only Meeting Context provenance is persisted. Canonicalizer,
+Semantic Consolidator and Renderer do not receive the authoritative participant
+list or attendance status, so they cannot detect or repair the contradiction.
+
+This is not primarily a renderer inference bug. The renderer preserved an open
+question already present in its input, and its prompt explicitly restricts it
+to the supplied consolidated input.
+
+## Cause Classification
+
+- Missing propagation: verified.
+- Ignored metadata: verified at extraction.
+- Prompt wording: not verified as the direct cause.
+- Renderer inference: disproved as the earliest cause.
+- Lost provenance: partially verified; provenance remains, but the substantive
+  participant metadata is not propagated.
+- Another cause: not identified.
+
+## Confidence
+
+High.
+
+The conclusion is supported by Meeting Context, extraction metadata, raw chunk
+08 model output, persisted extraction JSON, Canonicalizer output, Semantic
+Consolidator output and renderer metadata.
+
+## Recommended Fix
+
+Concept only:
+
+Propagate authoritative Meeting Context participant metadata, including
+attendance status, beyond extraction as structured data. Add validation that
+flags contradictions where generated items classify an actual participant as
+absent or mentioned-only. The validation should run before rendering, and
+ideally immediately after extraction so the contradiction is caught at the
+earliest stage.
+
+Do not rely on the Working Protocol Renderer to correct attendance semantics
+from prose-only consolidated items.

docs/bug-006-root-cause.md

@@ -0,0 +1,426 @@
+# BUG-006 Root Cause Analysis
+
+## Observed Behaviour
+
+In benchmark `meeting_context_v1/e2e_current_20260803_151000`, the Working
+Protocol Renderer output is not a faithful view of the matching consolidated
+representation.
+
+Compared files:
+
+- Consolidated input:
+  `samples/benchmarks/meeting_context_v1/e2e_current_20260803_151000/semantic_consolidator/consolidated_extractions.json`
+- Rendered output:
+  `samples/benchmarks/meeting_context_v1/e2e_current_20260803_151000/working_protocol/working_protocol.md`
+- Raw renderer response:
+  `samples/benchmarks/meeting_context_v1/e2e_current_20260803_151000/working_protocol/raw_model_response.txt`
+
+Observed problems:
+
+- consolidated decisions are omitted from the rendered `Decisions` sections
+- consolidated open questions are omitted from rendered `Open Questions`
+  sections
+- consolidated facts are rendered as decisions
+- some consolidated action items are omitted
+- some action-item and decision meanings are merged into other rendered
+  sections
+
+The raw renderer response and `working_protocol.md` are byte-identical
+(`cmp` exit code `0`), so the mismatch is already present in the LLM renderer
+response. It is not introduced by Markdown file writing.
+
+## Renderer Input And Prompt Evidence
+
+Renderer metadata records the exact input and prompt:
+
+- `samples/benchmarks/meeting_context_v1/e2e_current_20260803_151000/working_protocol/metadata.json:2`
+  to `:4`
+
+The renderer prompt explicitly says:
+
+- use only the provided input:
+  `prompts/working_protocol.md:9` to `:10`
+- preserve all decisions, action items and open questions:
+  `prompts/working_protocol.md:24` to `:26`
+- remove presentation-level redundancy:
+  `prompts/working_protocol.md:23`
+- do not repeat information merely because it appears in multiple categories:
+  `prompts/working_protocol.md:65`
+- condense everything else:
+  `prompts/working_protocol.md:75`
+
+The prompt is therefore present and relevant, but the direct observed failure
+occurs in the model-generated renderer response.
+
+## Faithfulness Analysis
+
+### Rendered Section: Prozessrahmen und Projektideen-Eingang / Background
+
+Status: modified.
+
+Rendered lines:
+
+- `working_protocol.md:7`
+- `working_protocol.md:9`
+
+The section condenses several consolidated facts and decisions into background
+paragraphs. Examples:
+
+- `decision_0001` is restated in background and again as a decision.
+- `fact`: `Der Prozess ist ein F&E-Prozess gewesen, einfach historisch.`
+- `fact`: `Die Bearbeitung der Projekte muss und kann nur in den
+  Fachabteilungen passieren.`
+- `fact`: `Bevor F&E ein Projekt durchdenkt, müssen im Vorfeld Kriterien wie
+  Marktexistenz und Zulassungen geprüft werden.`
+- `decision_0003` and `decision_0005` are partially restated as background.
+
+This is a condensation, not a renderer-only invention.
+
+### Rendered Section: Prozessrahmen und Projektideen-Eingang / Decisions
+
+Status: partially faithful, partially omitted.
+
+Faithfully or near-faithfully preserved:
+
+- `decision_0001` -> `working_protocol.md:13`
+- `decision_0002` -> `working_protocol.md:14`
+- `decision_0003` -> `working_protocol.md:15`
+- `decision_0005` -> `working_protocol.md:16`
+- `decision_0006` -> `working_protocol.md:17`
+- `decision_0009` -> `working_protocol.md:18`
+- `decision_0011` -> `working_protocol.md:19`
+
+Omitted as decisions:
+
+- `decision_0004`: `Festlegung eines Reporting-Zyklus für abgelehnte
+  Projekte.`
+  - Consolidated evidence: `consolidated_extractions.json:1217` to `:1227`
+  - Rendered only as background: `working_protocol.md:72`
+- `decision_0007`: `Zusammengetragen und beantwortete Fragen führen zur
+  Sitzung mit fünf Leuten...`
+  - Consolidated evidence: `consolidated_extractions.json:1329` to `:1339`
+  - No matching rendered decision.
+- `decision_0008`: `Es wird vereinbart, den bestehenden Prozessrahmen zu
+  nutzen und auf die Bedürfnisse der F&E abzustimmen...`
+  - Consolidated evidence present in the input.
+  - No matching rendered decision.
+- `decision_0010`: `Es wird vereinbart, dass betriebliche
+  Verbesserungsvorschläge... ausgeschleust werden.`
+  - Consolidated evidence present in the input.
+  - No matching rendered decision.
+- `decision_0012`: `Die Diskussion wird beendet und die Änderungen werden
+  verschickt; Abwarten auf Rückmeldung von Johanna/Björn.`
+  - Consolidated evidence: `consolidated_extractions.json:1747` to `:1757`
+  - No matching rendered decision.
+
+### Rendered Section: Prozessrahmen und Projektideen-Eingang / Action Items
+
+Status: partially faithful, partially omitted, with upstream semantic problems
+preserved.
+
+Rendered lines:
+
+- `working_protocol.md:23` to `:32`
+
+Preserved action items include:
+
+- `action_item_0001` -> `working_protocol.md:23`
+- `action_item_0002` -> `working_protocol.md:24`
+- `action_item_0003` -> `working_protocol.md:25`
+- `action_item_0004` -> `working_protocol.md:26`
+- `action_item_0005` -> `working_protocol.md:27`
+- `action_item_0006` -> `working_protocol.md:28`
+- `action_item_0007` -> `working_protocol.md:29`
+- `action_item_0009` -> `working_protocol.md:30`
+- `action_item_0011` -> `working_protocol.md:31`
+- `action_item_0012` -> `working_protocol.md:32`
+
+Omitted or merged action items:
+
+- `action_item_0008`: `Diskussion über die Relevanz eines speziellen Marktes
+  (z.B. Turkmenistan) führen.`
+  - Present in consolidated input.
+  - No matching rendered action item.
+- `action_item_0010`: `Filterkriterien für verschiedene Fälle... definieren.`
+  - Present in consolidated input.
+  - Its meaning overlaps with rendered decision `working_protocol.md:18` and
+    action item `working_protocol.md:30`, but it is not preserved as its own
+    action item.
+
+Important boundary:
+
+Items such as `Feedback zu den Kriterien...`, `Einbinden der Fachbereiche...`
+and `Mail an Jovana und Björn...` are questionable todos, but they are already
+`action_item` entries in the consolidated input:
+
+- `consolidated_extractions.json:1007` to `:1019`
+- `consolidated_extractions.json:1537` to `:1549`
+- `consolidated_extractions.json:1651` to `:1663`
+
+The renderer preserves those upstream action-item categories. It does not
+create those todos from facts or prose.
+
+### Rendered Section: Prozessrahmen und Projektideen-Eingang / Open Questions
+
+Status: partially faithful, partially omitted.
+
+Rendered lines:
+
+- `working_protocol.md:36` to `:47`
+
+Preserved open questions:
+
+- `open_question_0001` -> `working_protocol.md:36`
+- `open_question_0002` -> `working_protocol.md:37`
+- `open_question_0003` -> `working_protocol.md:38`
+- `open_question_0004` -> `working_protocol.md:39`
+- `open_question_0005` -> `working_protocol.md:40`
+- `open_question_0006` -> `working_protocol.md:41`
+- `open_question_0007` -> `working_protocol.md:42`
+- `open_question_0009` -> `working_protocol.md:43`
+- `open_question_0010` -> `working_protocol.md:44`
+- `open_question_0011` -> `working_protocol.md:45`
+- `open_question_0012` -> `working_protocol.md:46`
+- `open_question_0013` -> `working_protocol.md:47`
+
+Omitted open questions:
+
+- `open_question_0008`: `Wer soll die Rolle des Gatekeepers übernehmen und wie
+  wird der Prozess konkret implementiert?`
+  - Consolidated evidence: `consolidated_extractions.json:1387` to `:1397`
+  - No matching rendered open question.
+- `open_question_0014`: `Welche Prüfsteine sind relevant für die
+  Fachabteilung?`
+  - Consolidated evidence: `consolidated_extractions.json:1765` to `:1775`
+  - No matching rendered open question.
+
+### Rendered Section: Projektkategorisierung und Status / Background
+
+Status: modified.
+
+Rendered line:
+
+- `working_protocol.md:53`
+
+This condenses:
+
+- fact: `Der Leiter F&E führt die Projektliste...`
+- `technical_detail_0010`: project type definition
+- fact: `Ein Projekt wandert direkt wieder in Business Development...`
+
+No renderer-only invention was verified in this section.
+
+### Rendered Section: Projektkategorisierung und Status / Decisions
+
+Status: category-changed.
+
+Rendered lines:
+
+- `working_protocol.md:57`
+- `working_protocol.md:58`
+
+Both rendered decisions are facts in the consolidated input:
+
+- fact: `Im Zweifel gehen Projekte durch.`
+  - Consolidated evidence: `consolidated_extractions.json:775` to `:784`
+  - Rendered as decision: `working_protocol.md:57`
+- fact: `Ein Projekt kann abgelehnt werden, aber es muss sichergestellt sein,
+  dass relevante Projekte nicht weggeschmissen werden.`
+  - Consolidated evidence: `consolidated_extractions.json:755` to `:764`
+  - Rendered as decision: `working_protocol.md:58`
+
+This is the clearest category change in the renderer output.
+
+### Rendered Section: Projektkategorisierung und Status / Action Items
+
+Status: omitted.
+
+Rendered line:
+
+- `working_protocol.md:62`: `*Keine.*`
+
+The consolidated input contains at least one action item that belongs to this
+topic area:
+
+- `action_item_0008`: `Diskussion über die Relevanz eines speziellen Marktes
+  (z.B. Turkmenistan) führen.`
+
+The renderer omitted it.
+
+### Rendered Section: Projektkategorisierung und Status / Open Questions
+
+Status: faithful to rendered grouping, but unfaithful to complete input.
+
+Rendered line:
+
+- `working_protocol.md:66`: `*Keine.*`
+
+The complete consolidated input still contains project-process open questions,
+including omitted `open_question_0008` and `open_question_0014`. They were not
+rendered elsewhere.
+
+### Rendered Section: Technische Details und Infrastruktur / Background
+
+Status: modified.
+
+Rendered line:
+
+- `working_protocol.md:72`
+
+This condenses facts and technical details:
+
+- fact: `Das Netzwerk bei Gemeinden ist momentan langsam.`
+- `technical_detail_0006`: `Das Netzwerk ist langsam (wie zu ISDN-Zeiten).`
+- `technical_detail_0007`: `Der Rechner schmiert ab...`
+- fact: `Das Dokument ist das aktuelle Projektdeckblatt...`
+- fact: `Es gibt einen Reporting-Zyklus.`
+- fact: `Sekretariate sind sehr abweisend...`
+
+The problem is not invention; the problem is that `decision_0004`
+(`Festlegung eines Reporting-Zyklus...`) is downgraded from decision to
+background.
+
+### Rendered Section: Technische Details und Infrastruktur / Decisions
+
+Status: omitted.
+
+Rendered line:
+
+- `working_protocol.md:76`: `*Keine.*`
+
+The consolidated input contains `decision_0004`, which is about a reporting
+cycle and is rendered only as background.
+
+### Rendered Section: Technische Details und Infrastruktur / Action Items
+
+Status: faithful to rendered items.
+
+Rendered lines:
+
+- `working_protocol.md:80`
+- `working_protocol.md:81`
+
+These correspond to:
+
+- `action_item_0013`
+- `action_item_0014`
+
+The semantic quality of `action_item_0014` is questionable, but that issue is
+upstream because the consolidated input already categorizes it as an action
+item.
+
+### Rendered Section: Technische Details und Infrastruktur / Open Questions
+
+Status: omitted relative to complete input.
+
+Rendered line:
+
+- `working_protocol.md:85`: `*Keine.*`
+
+No technical open questions are clearly required here, but the overall rendered
+protocol still omits consolidated open questions elsewhere.
+
+## Exact Mismatches
+
+| Consolidated item | Category before | Rendered text | Category after | Result |
+| --- | --- | --- | --- | --- |
+| `decision_0004`: `Festlegung eines Reporting-Zyklus...` | decision | `Es gibt einen Reporting-Zyklus...` | background | category weakened |
+| `decision_0007`: `...Sitzung mit fünf Leuten...` | decision | none | omitted | omitted |
+| `decision_0008`: `...Prozessrahmen nutzen...` | decision | none | omitted | omitted |
+| `decision_0010`: `...Verbesserungsvorschläge... ausgeschleust...` | decision | none | omitted | omitted |
+| `decision_0012`: `Die Diskussion wird beendet...` | decision | none | omitted | omitted |
+| `open_question_0008`: `Wer soll die Rolle des Gatekeepers übernehmen...` | open_question | none | omitted | omitted |
+| `open_question_0014`: `Welche Prüfsteine sind relevant...` | open_question | none | omitted | omitted |
+| fact: `Im Zweifel gehen Projekte durch.` | fact | `Im Zweifel gehen Projekte durch.` | decision | promoted |
+| fact: `Ein Projekt kann abgelehnt werden...` | fact | same meaning | decision | promoted |
+| `action_item_0008`: `Diskussion über die Relevanz... Turkmenistan...` | action_item | none | omitted | omitted |
+| `action_item_0010`: `Filterkriterien für verschiedene Fälle... definieren.` | action_item | overlapped by decision/action item text | merged / not preserved as action item | modified |
+
+## Invented Content Check
+
+No renderer-only invented people were verified in this comparison. `Guido` and
+`Noah` appear in the rendered protocol, but they are already present in the
+consolidated input. This belongs to BUG-003, not BUG-006.
+
+No clear renderer-only invented responsibility was verified in this comparison.
+Questionable todos in the rendered protocol are already categorized as action
+items in the consolidated input.
+
+## Merged And Split Items
+
+Verified merges:
+
+- Multiple facts and decisions are merged into background paragraphs in
+  `working_protocol.md:7`, `:9`, `:53` and `:72`.
+- `action_item_0010` is not preserved as a separate action item and overlaps
+  with rendered filter-criteria decision/action-item wording.
+
+Verified splits:
+
+- No clear split from one consolidated item into multiple materially different
+  rendered items was identified.
+
+## Earliest Point Where The Mismatch Occurs
+
+The earliest point is the Working Protocol Renderer LLM response.
+
+Evidence:
+
+- `metadata.json` records renderer input as
+  `semantic_consolidator/consolidated_extractions.json` and prompt file
+  `prompts/working_protocol.md`.
+- `raw_model_response.txt` already contains the omissions and category
+  changes.
+- `raw_model_response.txt` and `working_protocol.md` are byte-identical.
+
+Therefore the mismatch is not introduced by renderer post-processing, output
+normalization or Markdown generation.
+
+## Verified Root Cause
+
+Verified cause:
+
+The single-pass LLM Working Protocol Renderer does not reliably preserve the
+category and coverage constraints of the consolidated input. It generates a
+Markdown view that condenses and reorganizes the input, but the generated raw
+response omits required items and changes some categories.
+
+Cause classification:
+
+- Renderer prompt: not proven as the sole root cause. The prompt includes
+  explicit preservation rules, but also includes condensation and redundancy
+  instructions. The evidence proves the model output violates the preservation
+  rules; it does not prove which prompt sentence caused the violation.
+- Renderer post-processing: disproved. Raw response and final Markdown are
+  identical.
+- Renderer output normalization: disproved. No separate normalization changed
+  the raw response.
+- Markdown generation: disproved. The final file is the raw Markdown response.
+- Another verified cause: single-pass LLM renderer generation violates
+  structural faithfulness requirements.
+
+## Confidence
+
+High for the location of the failure and for disproving post-processing,
+normalization and Markdown generation as causes.
+
+Medium for root-cause classification beyond that. The evidence identifies the
+renderer LLM response as the failing point, but does not isolate one prompt
+sentence as the cause.
+
+## Conceptual Repair Strategy
+
+Do not attempt to repair this with free-form post-processing.
+
+Conceptually, renderer faithfulness needs a structural coverage contract:
+
+- every consolidated decision must be accounted for as a decision
+- every consolidated action item must be accounted for as an action item
+- every consolidated open question must be accounted for as an open question
+- facts may appear in background, but must not be promoted to decisions
+- omissions and category changes should be validator-detectable before the
+  protocol is accepted
+
+The renderer output should be validated against the consolidated input by item
+ID or another stable structured reference, rather than relying on prose-only
+Markdown to preserve category semantics implicitly.

docs/constraint-repair.md

@@ -0,0 +1,348 @@
+# Constraint Repair Engine V1
+
+Constraint Repair Engine V1 is a reusable structural repair stage for JSON
+outputs produced by local LLM pipeline steps.
+
+It exists for cases where a model produced semantically usable JSON, but a
+strict validator rejected the document because a structural invariant was
+violated. Typical examples are repeated identifiers, missing identifiers, empty
+containers or unstable item order.
+
+The repair stage is intentionally not integrated into the production pipeline
+yet. It is a standalone module that future stages can opt into explicitly.
+
+## Architecture
+
+Package:
+
+```text
+src/meeting_lab/constraint_repair/
+```
+
+The package contains:
+
+- `engine.py`: generic JSON repair logic and the generic repair prompt
+- `adapters/`: thin adapters from stage-specific validator results to the
+  generic validator report format
+
+The engine receives exactly two logical inputs:
+
+1. the complete original JSON output
+2. a machine-generated validator report
+
+It never reads the original transcript and never receives Meeting Context or
+other source material. The engine is domain-neutral: it operates on JSON
+pointers, list keys and validator-reported identifiers.
+
+## Validator Interface
+
+The generic validator report has this shape:
+
+```json
+{
+  "valid": false,
+  "violations": [
+    {
+      "type": "duplicate_id",
+      "collection_pointer": "/groups",
+      "id_list_key": "source_item_ids",
+      "id": "item_0001",
+      "occurrences": [
+        {"item_index": 0, "id_index": 1},
+        {"item_index": 3, "id_index": 0}
+      ],
+      "keep_occurrence": 0
+    }
+  ]
+}
+```
+
+Supported V1 violation types:
+
+- `duplicate_id`: remove repeated identifier occurrences from a list field
+- `missing_id`: restore an identifier by appending a validator-provided item
+  template or adding it to a validator-specified existing item
+- `empty_group`: remove an item whose identifier list is empty
+- `reorder_items`: reorder a collection by validator-provided keys
+
+The report must provide enough structural information for the engine to repair
+the document without interpreting content.
+
+## Meeting Context Constraint Validation Extension
+
+Meeting Context constraints can be added without making the repair engine
+Meeting Context aware.
+
+The validator may inspect a stage output together with authoritative
+`meeting_context.yaml`. It then converts violations into the generic validator
+report format. The Constraint Repair Engine still receives only the original
+JSON document and the validator report.
+
+Authoritative metadata is configuration, not meeting content. Examples include:
+
+- participant attendance
+- canonical participant identity
+- aliases
+- departments
+- roles
+
+Authoritative metadata may be consumed by LLMs and downstream pipeline stages.
+It must never be redefined, overwritten or inferred by any pipeline component.
+
+This includes, but is not limited to:
+
+- LLM extraction
+- Canonicalizer
+- Semantic Consolidator
+- Constraint Repair
+- Renderer
+
+These components may consume authoritative metadata, but they must treat it as
+immutable configuration.
+
+### Constraint Types
+
+`participant_attendance_conflict`
+
+A known participant from Meeting Context is represented in structured output
+as absent, mentioned-only, external or otherwise not attending, contradicting
+the authoritative attendance status.
+
+Example:
+
+```json
+{
+  "valid": false,
+  "constraint_source": {
+    "type": "meeting_context",
+    "meeting_id": "2026-07-27-projektprozess",
+    "source_file": "samples/real_live/project_process_meeting/meeting_context.yaml",
+    "schema_version": "1"
+  },
+  "violations": [
+    {
+      "type": "participant_attendance_conflict",
+      "severity": "error",
+      "collection_pointer": "/participants",
+      "item_index": 3,
+      "entity_id": "bjoern",
+      "display_name": "Björn",
+      "matched_alias": "Björn",
+      "field": "attendance_status",
+      "actual_value": "absent",
+      "expected_value": "present",
+      "repair": {
+        "operation": "set_field",
+        "field": "attendance_status",
+        "value": "present"
+      }
+    }
+  ]
+}
+```
+
+`participant_unknown`
+
+A person-like entity appears in a structured participant or mentioned-person
+field but is not known in Meeting Context as a participant, mentioned person or
+alias.
+
+Example:
+
+```json
+{
+  "type": "participant_unknown",
+  "severity": "error",
+  "collection_pointer": "/participants",
+  "item_index": 4,
+  "matched_text": "Guido",
+  "repair": {
+    "operation": "remove_item"
+  }
+}
+```
+
+Removal is allowed only when the unknown entity is a standalone structured
+participant-like item and removing it does not remove unrelated content. If the
+unknown name appears only inside generated prose, the repair must fail closed.
+
+`participant_alias_conflict`
+
+A structured entity reference uses an alias that maps to a different
+authoritative entity, or uses an ambiguous alias that cannot be resolved to
+exactly one Meeting Context entity.
+
+Example:
+
+```json
+{
+  "type": "participant_alias_conflict",
+  "severity": "error",
+  "json_pointer": "/participants/2/entity_id",
+  "matched_alias": "Johanna",
+  "expected_entity_id": "jovana",
+  "expected_display_name": "Jovana",
+  "actual_entity_id": "unknown",
+  "repair": {
+    "operation": "set_field",
+    "field": "entity_id",
+    "value": "jovana"
+  }
+}
+```
+
+Alias repair is allowed only for structured identity fields and only when
+Meeting Context maps the alias to exactly one entity.
+
+### Validation Principle
+
+The validator validates structured data whenever possible. Lexical analysis is
+a fallback only when no structured representation exists. The long-term
+objective is to reduce lexical validation over time by preserving Meeting
+Context metadata as structured data throughout the pipeline.
+
+Lexical fallback may report a violation, but it must not create repair
+instructions that require editing generated prose.
+
+### Repair Workflow
+
+```text
+Stage output
+    ↓
+Meeting Context Constraint Validator
+    ↓
+Generic validator report
+    ↓
+Constraint Repair Engine
+    ↓
+Meeting Context Constraint Validator
+```
+
+If Validator #1 succeeds, repair is skipped. If Validator #1 fails, exactly one
+repair pass may run when all violations map to deterministic structural
+operations. Validator #2 then checks the repaired document. If Validator #2
+fails, the pipeline stops and reports the remaining violations.
+
+### Allowed Repairs
+
+Allowed repairs are deterministic structural operations only:
+
+- set a structured attendance field to the authoritative value
+- set a structured entity ID to the authoritative entity ID
+- move a structured participant item between participant collections
+- remove a standalone structured unknown participant item
+- remove empty structured participant containers
+- reorder structured participant collections deterministically
+
+### Forbidden Repairs
+
+The repair engine must never perform free-form text editing.
+
+It must not:
+
+- remove names from generated prose
+- replace text inside prose fields
+- rewrite sentences
+- infer attendance from transcript content
+- invent participants
+- invent aliases
+- merge people
+- split people
+- change responsibility attribution
+- change fact, decision, action-item or open-question meaning
+- use Meeting Context directly
+
+If a violation exists only inside generated prose and cannot be repaired by a
+deterministic structural operation, the repair must fail closed and report the
+violation.
+
+### Integration Strategy
+
+Minimum useful integration for the current architecture:
+
+```text
+Semantic Consolidator
+    ↓
+Meeting Context Constraint Validator
+    ↓
+Constraint Repair
+    ↓
+Meeting Context Constraint Validator
+    ↓
+Renderer
+```
+
+This catches contradictions in the consolidated representation before the
+Working Protocol Renderer receives it. It does not require the renderer to
+infer attendance semantics from prose.
+
+Future architecture:
+
+Meeting Context metadata should remain structured throughout the pipeline so
+that the Renderer receives authoritative participant metadata directly instead
+of having to infer it from generated prose. In that architecture, Meeting
+Context validation can operate primarily on structured fields and use lexical
+analysis only as a diagnostic fallback.
+
+## Allowed Operations
+
+The engine may:
+
+- move identifiers
+- remove duplicate identifiers
+- restore missing identifiers
+- remove empty containers
+- reorder items
+
+The engine must not:
+
+- invent information
+- rewrite extracted text
+- reinterpret reasons or explanations
+- create new semantic relationships
+- split semantic relationships
+
+Missing identifier repair is intentionally conservative. If the validator does
+not provide an explicit target item or an item template, the engine refuses the
+repair.
+
+## Generic Repair Prompt
+
+The module defines a generic prompt contract for future model-backed repair
+backends. The prompt describes the task as repairing a structured JSON document
+from a validator report and deliberately avoids stage-specific vocabulary.
+
+V1 unit tests assert that the prompt does not mention the current consolidation
+stage, Meeting Context, facts, or merge groups.
+
+## Semantic Consolidator Adapter
+
+`constraint_repair.adapters.semantic_consolidator` converts the current
+consolidation validator shape into the generic validator report.
+
+The adapter knows the current consolidation output field names such as
+`groups` and `source_item_ids`. The generic repair engine does not. This keeps
+stage-specific schema knowledge at the edge and preserves the repair engine as
+a reusable JSON utility.
+
+The adapter currently reports:
+
+- repeated source IDs
+- missing expected source IDs
+- empty source-ID containers
+
+It does not call Ollama and does not change the production consolidation path.
+
+## Future Reuse
+
+Future pipeline stages can reuse the same engine by writing a small adapter
+that maps their validator failures to the generic report format. The required
+contract is that the adapter reports structural locations and does not ask the
+engine to infer domain meaning.
+
+Potential future uses:
+
+- enforcing exact identifier coverage in LLM-generated grouping output
+- removing empty generated containers before strict parsing
+- restoring validator-known singleton items
+- normalizing deterministic order after otherwise valid generation

docs/data-models.md

@@ -218,6 +218,138 @@ Owner remains empty if unknown.
 
 ---
 
+# Meeting Context V1
+
+Manually maintained YAML metadata scaffold with an implemented Python loader,
+validator and deterministic prompt renderer for chunk extraction.
+
+Top-level structure:
+
+```yaml
+schema_version: "1"
+meeting: {}
+participants: []
+mentioned_people: []
+organization: {}
+known_entities: {}
+context_rules: {}
+```
+
+Meeting Context separates participants, mentioned people, transcript speakers,
+responsible people, roles and departments. It is authoritative only for
+explicitly supplied metadata. It must not be used to infer responsibilities,
+decisions or commitments.
+
+Template:
+
+- `samples/templates/meeting_context.template.yaml`
+
+Documentation:
+
+- `docs/meeting-context.md`
+
+When `--meeting-context` is supplied to extraction, output JSON receives only
+minimal provenance:
+
+```json
+{
+    "context": {
+        "meeting_id": "...",
+        "source_file": "...",
+        "schema_version": "1"
+    }
+}
+```
+
+Later Canonicalizer, Semantic Consolidator, Canonical Meeting Knowledge and
+renderer integration remains planned.
+
+---
+
+# Entity Registry
+
+Accepted Architecture. Implementation deferred.
+
+The Entity Registry is the persistent cross-meeting knowledge source for
+confirmed entities, aliases and organizational metadata. It is independent from
+individual meetings and is the planned long-term source used to prepare Meeting
+Context V2.
+
+Entity types include:
+
+- people
+- organizations
+- departments
+- products
+- projects
+- locations
+- abbreviations
+
+Each entity has a stable internal identifier. The displayed name may change
+over time, but the internal identifier must remain stable.
+
+Conceptual shape:
+
+```json
+{
+    "entity_id": "person_0001",
+    "entity_type": "person",
+    "display_name": "Jovana",
+    "aliases": [
+        "Jovana",
+        "Giovanna",
+        "Jovanna",
+        "Giovana"
+    ],
+    "status": "confirmed"
+}
+```
+
+The registry never learns automatically. It may propose matches, but only
+confirmed user actions update it. Similarity search may suggest spelling
+variants, Whisper transcription variants, umlaut variants or OCR-like mistakes,
+but suggestions require explicit confirmation.
+
+Previously unseen names should be classified by the user as one of:
+
+- meeting participant
+- mentioned person
+- external person
+- transcription error
+- ignore
+
+The Entity Registry must not infer responsibility, decisions, attendance or
+ownership.
+
+---
+
+# Meeting Context V2
+
+Accepted Architecture. Implementation deferred.
+
+Meeting Context V2 is an authoritative meeting-specific YAML Point of Truth
+generated or assisted from:
+
+- Entity Registry
+- user confirmations
+- meeting metadata
+
+The YAML remains the extraction pipeline interface and the authoritative
+meeting-specific Point of Truth for that meeting run. It is also a reproducible
+input artifact: changes to the Entity Registry after a meeting run must not
+silently change the historical Meeting Context used for that run.
+
+The Entity Registry remains the persistent cross-meeting knowledge source. It
+must not override explicit meeting-specific confirmations.
+
+Meeting Context V2 should reduce manual work, improve alias handling, detect
+transcription errors earlier and make Meeting Context quality scalable across
+many meetings.
+
+See `docs/adr-meeting-context-v2-entity-registry.md`.
+
+---
+
 # Topic Result
 
 After extraction, every topic contains the collected information.
@@ -238,23 +370,196 @@ After extraction, every topic contains the collected information.
 }
 ```
 
-This object represents the main output of the analysis pipeline.
+This object feeds the Canonical Meeting Knowledge representation.
 
 ---
 
-# Meeting Result
+# Canonicalized Extractions
 
-The complete structured meeting.
+Implemented deterministic intermediate file created from raw chunk extraction
+JSON by Canonicalizer V1. This is not Canonical Meeting Knowledge.
+
+Top-level structure:
+
+```json
+{
+    "schema_version": "1",
+    "source_files": [],
+    "stats": {},
+    "items": []
+}
+```
+
+Each item contains at least:
+
+- item_id
+- category
+- text
+- evidence
+- source_file
+- source_index
+- original_value
+- source_references
+
+Action items also preserve deterministic fields such as `responsible` and
+`deadline` when present.
+
+Responsibility attribution is stricter than mention or participation. A
+`responsible` value may be kept only when source evidence explicitly assigns,
+accepts or confirms responsibility. If evidence is incomplete, ambiguous or
+only based on a suggestion, objection, topic expertise or department mention,
+the field remains `null` or unset and the evidence is preserved.
+
+Do not collapse these concepts into one field:
+
+- `speaker`: person who uttered the evidence.
+- `mentioned_person`: person named in the evidence.
+- `participant`: person present in the meeting.
+- `responsible_person`: person explicitly assigned to or accepting an action.
+- `department`: organizational unit discussed or represented.
+- `owner`: durable ownership of a process, system or knowledge object.
+- `assignee`: operational person or team assigned to a concrete task.
+
+Future compatible fields may include:
+
+- `responsibility_status`: `explicit`, `accepted`, `proposed` or `unclear`.
+- `attribution_evidence`: source evidence supporting the assignment status.
+
+Example:
+
+```json
+{
+    "id": "fact.chunk_03.0001",
+    "category": "fact",
+    "text": "...",
+    "source_references": [
+        {
+            "chunk_id": "chunk_03",
+            "source_file": "chunk_03_extraction.json",
+            "evidence": "..."
+        }
+    ]
+}
+```
+
+Canonicalizer V1 creates this kind of object without an LLM. It validates and
+normalizes raw extraction objects, assigns stable IDs and source references,
+normalizes category names and basic field structure, performs only safe
+deterministic cleanup, may group exact duplicates and must preserve all source
+evidence.
+
+It must not perform uncertain semantic merging.
+
+---
+
+# Semantic Fact Group
+
+Implemented by Semantic Consolidator V0.
+
+Example:
+
+```json
+{
+    "consolidated_id": "fact_group_0001",
+    "category": "fact",
+    "canonical_text": "...",
+    "source_item_ids": ["fact_0001"],
+    "source_references": [],
+    "evidence": [],
+    "merge_reason": "Singleton; no semantically equivalent fact found."
+}
+```
+
+Semantic Consolidator V0 only processes fact items. It merges semantically
+equivalent facts conservatively, preserves source references and evidence, and
+validates that every source fact appears exactly once. Non-fact categories are
+copied unchanged. It is not a summarizer, topic grouper, protocol renderer or
+Canonical Meeting Knowledge generator.
+
+---
+
+# Consolidated Topic
+
+Planned semantic object produced by the Semantic Consolidator.
+
+Example:
+
+```json
+{
+    "topic_id": "topic_001",
+    "title": "...",
+    "background": [],
+    "decisions": [],
+    "action_items": [],
+    "open_questions": [],
+    "durable_information": [],
+    "uncertainty": [],
+    "source_references": []
+}
+```
+
+Future Semantic Consolidator versions may use the local LLM to merge
+semantically equivalent statements beyond facts, group content by topic,
+preserve evidence from all contributing chunks, mark contradictions and
+uncertainty and separate durable information from transient discussion.
+
+It produces Canonical Meeting Knowledge. It does not directly write a protocol.
+
+---
+
+# Canonical Meeting Knowledge
+
+The canonical semantic representation of one meeting.
+
+This representation is the single source of truth for all downstream outputs.
+It is a structured representation, preferably JSON, and is not itself a prose
+protocol.
 
 ```json
 {
     "meeting_id": "meeting_001",
 
-    "topics": []
+    "metadata": {},
+    "topics": [],
+    "facts": [],
+    "decisions": [],
+    "todos": [],
+    "questions": [],
+    "positions": [],
+    "technical_details": [],
+    "durable_information": [],
+    "rationale": [],
+    "uncertainty": [],
+    "source_references": []
 }
 ```
 
-Protocol generation operates exclusively on this structure.
+This is the common intermediate representation for all final Output Views.
+The exact schema is not final and should be refined during future
+implementation work.
+
+---
+
+# Output Views
+
+The final outputs are independent renderings of the Canonical Meeting Knowledge.
+
+```text
+Canonical Meeting Knowledge
+    ├── Working Protocol
+    ├── Distribution Protocol
+    └── Knowledge Objects
+```
+
+The Working Protocol, Distribution Protocol and Knowledge Objects are not
+derived from one another. Each renderer reads the same canonical semantic
+model and selects the level of detail appropriate for its purpose.
+
+Knowledge Objects represent durable organizational knowledge such as processes,
+definitions, responsibilities, rules, accepted practices and long-term
+decisions. They are independent of the original meeting wording. Markdown is one
+possible presentation, but JSON or another structured format is expected to
+become the canonical storage format later.
 
 ---
 
@@ -272,4 +577,4 @@ Possible future additions include:
 
 These fields will only be introduced when they provide measurable benefits.
 
-The Meeting Lab intentionally avoids designing an overly complex schema in advance.
+The Meeting Lab intentionally avoids designing an overly complex schema in advance.

docs/design/evidence_commitment_model.md

@@ -0,0 +1,369 @@
+# Evidence / Commitment Model
+
+Status: architecture design study for BUG-015; no implementation recommendation is made here.
+
+## Motivation
+
+Meeting Lab currently asks extraction and the BUG-015 verifier to cross a category boundary in one step: a candidate is either a protocol-worthy Decision, Action Item or Open Question, or it is rejected. That combines two different questions:
+
+1. What does the transcript provide evidence for?
+2. Which evidenced states should a particular protocol view publish?
+
+Meetings do not move directly from absence to commitment. An option can become a proposal, then a preferred option, then a tentative agreement and finally a decision. Work can be suggested, requested, assigned, accepted, already underway or completed. A question can be asked and answered, or can remain explicitly unresolved. Rejecting everything below the final protocol threshold discards useful evidence; promoting it creates false commitments.
+
+The proposed model therefore records the evidenced semantic state first. A later policy selects protocol-worthy states. It preserves the existing separation between extraction, deterministic canonicalization, semantic consolidation and rendering, and it does not make rendered output the semantic source of truth.
+
+## Observed BUG-015 failures
+
+The BUG-015 Gold cases expose both sides of the binary-classification problem.
+
+| Progeo-derived evidence | Correct evidence state | Binary failure to avoid |
+| --- | --- | --- |
+| “Die Option steht im Raum, das Material chemisch recyceln zu lassen.” | option | False Decision |
+| “Ich würde nicht in eine reale Anlage gehen. Wenn überhaupt, können wir über ein Technikum reden.” | personal preference with a conditional option | False Decision |
+| “Nein, die Zusammenarbeit mit Dr. Schlummer machen wir nicht. … das ist entschieden.” | explicit decision: rejection | False rejection |
+| “Die Geometrie kann man vielleicht noch optimieren.” | possible next step | False Action Item |
+| “Marleen müsste vielleicht mal äußern …” | suggested/requested action; no accepted or confirmed responsibility | False Action Item and false owner |
+| “Wir könnten Dirk Textor vielleicht noch einmal kontaktieren.” | suggestion | False Action Item |
+| “Nina, übernimmst du …? – Ja, ich übernehme …” | accepted action with explicit responsibility and deadline | False rejection |
+| “Den CET-Artikel erstellen wir bereits …” | ongoing established work; owner not evidenced | Consistent false rejection by the binary verifier |
+| “Ob sich das Waschen lohnt, weiß ich nicht.” | uncertainty | False Open Question |
+| “Gibt es schon ein Programm? – Ja …” | explicit, resolved question | False Open Question if local resolution is ignored |
+| “Welche Daten … dürfen wir veröffentlichen? … weiterhin ungeklärt.” | explicit unresolved question | Consistent false rejection by the binary verifier |
+
+The verifier was reliable on several negative cases and on explicit commitment language, but not on valid states whose evidence did not resemble a fresh agreement: already-established work and an explicitly unresolved information need. This suggests a representation problem, not merely an insufficient keep/reject prompt.
+
+## Model shape
+
+The model is deliberately small and compositional. Each evidence item has:
+
+- a **domain**: decision, action or information need;
+- a **semantic state** within that domain;
+- an **evidence support level** describing how directly the transcript supports that label;
+- preserved transcript evidence and source references;
+- domain-specific independent attributes, such as responsibility or resolution;
+- no automatic claim that the item belongs in a final protocol.
+
+Semantic maturity and evidence support are independent. An explicitly worded proposal remains a proposal; it is not a weak decision. Conversely, ongoing work can be strongly evidenced without a recorded moment of assignment.
+
+## Semantic state diagrams
+
+The arrows show common progressions, not mandatory workflows. Meetings may enter at any state, skip states, regress, or end without commitment.
+
+### Decision evolution
+
+```text
+idea -> option -> proposal -> preferred_option -> tentative_agreement -> decision
+          |          |              |                    |              |
+          +----------+--------------+--------------------+----------> withdrawn
+                                                                    superseded
+                                                                    reopened
+```
+
+An **idea** is an undeveloped possibility. An **option** is a candidate alternative. A **proposal** asks the group to adopt an outcome. A **preferred option** expresses comparative preference without settlement. A **tentative agreement** records provisional convergence that is explicitly conditional or awaiting confirmation. A **decision** records an outcome the meeting settled, selected, approved, rejected or committed to. The intermediate preferred and tentative states matter because they prevent likely direction from being confused with commitment.
+
+### Action evolution
+
+```text
+possible_next_step -> recommendation -> requested_action -> established_action -> ongoing_work -> completed
+        |                  |                 |                    |               |
+        +------------------+-----------------+--------------------+----------> cancelled
+
+Responsibility (independent):
+unset -> proposed_responsible -> assigned -> accepted/confirmed
+```
+
+An action can enter directly as **established_action** through explicit assignment, acceptance or commitment. It can enter directly as **ongoing_work** when the transcript clearly says that the work is already being performed, as in the CET example. `proposed_responsible` is evidence about a suggestion, not permission to populate the protocol's responsible field. Only `assigned`, `accepted` or `confirmed` supports recorded responsibility, and only where the meeting evidence explicitly assigns, accepts or confirms it.
+
+### Information-need evolution
+
+```text
+uncertainty ---------> information_need(unresolved) ---------> resolved
+curiosity -----------> explicit_question(unresolved) --------> resolved
+request_for_clarification(unresolved) -----------------------> resolved
+missing_information(unresolved) -----------------------------> resolved
+
+rhetorical_question -> discourse only
+```
+
+Uncertainty and curiosity do not automatically create an information need. An explicit question may be resolved immediately. “Open Question” is therefore a policy result derived primarily from a qualifying kind plus `unresolved`, rather than a primitive utterance category.
+
+## Proposed taxonomy
+
+### Common fields
+
+| Field | Proposed values | Purpose |
+| --- | --- | --- |
+| `domain` | `decision`, `action`, `information_need` | Selects the domain taxonomy. |
+| `state` | Domain-specific values below | Records what the evidence says now. |
+| `support` | `indirect`, `direct`, `explicit` | Rates support for the chosen state, not protocol importance. |
+| `polarity` | `positive`, `negative` where applicable | Preserves approval/rejection and adoption/refusal without rewriting meaning. |
+| `evidence` | transcript excerpt(s) | Proves the state and attributes. |
+| `source_refs` | stable source references | Retains provenance across stages. |
+
+`support` is intentionally not `weak / medium / strong`. Those terms mix confidence, semantic maturity and number of witnesses. The proposed meanings are narrower:
+
+- `indirect`: the state is supported by context but not stated in a self-contained utterance; downstream commitment policy should normally be conservative.
+- `direct`: an utterance directly expresses the state, such as a proposal, preference, ongoing-work statement or question.
+- `explicit`: the utterance also names the decisive status, for example “das ist entschieden”, “ich übernehme”, “wir erstellen bereits” or “weiterhin ungeklärt”.
+
+This common axis simplifies evidence auditing and threshold policy, but cannot replace domain state. An explicit suggestion is still not an Action Item, and an explicit uncertainty is still not an Open Question. Model confidence, if retained at all, must be a separate operational field and must not be presented as evidence strength.
+
+### Decision states
+
+| State | Meaning | Default protocol treatment |
+| --- | --- | --- |
+| `idea` | Undeveloped possibility or brainstorming contribution | Exclude |
+| `option` | Candidate alternative under consideration | Exclude |
+| `proposal` | Outcome offered for adoption | Exclude |
+| `preferred_option` | Expressed preference among alternatives | Exclude |
+| `tentative_agreement` | Provisional convergence with an expressed condition or pending confirmation | Exclude from Decisions; potentially expose to an editorial view |
+| `decision` | Settled, selected, approved, rejected or committed outcome | Include as Decision when evidence is sufficient |
+| `reopened` | Earlier decision explicitly returned to unresolved consideration | Do not render the earlier decision as currently settled without qualification |
+| `superseded` | Earlier decision replaced by a later one | Retain provenance; normally render only the current decision |
+| `withdrawn` | Candidate state explicitly withdrawn | Exclude as current commitment |
+
+`idea`, `option`, `proposal`, `preferred_option`, `tentative_agreement` and `decision` are necessary distinctions for BUG-015. `reopened`, `superseded`, `withdrawn` are lifecycle states needed to avoid treating historical evidence as current policy; they need not be first-iteration extraction targets.
+
+### Action states and attributes
+
+| State | Meaning | Default protocol treatment |
+| --- | --- | --- |
+| `possible_next_step` | Hypothetical or exploratory action | Exclude |
+| `recommendation` | Action advocated but not established as work | Exclude |
+| `requested_action` | Someone asks that work be done, without enough evidence that it is established | Exclude by default |
+| `established_action` | Concrete future work established by assignment, acceptance, commitment or confirmation | Include as Action Item |
+| `ongoing_work` | Concrete work explicitly already underway | Include when still relevant; do not require a newly witnessed assignment |
+| `completed` | Work explicitly reported complete | Exclude from open Action Items; retain as status/history |
+| `cancelled` | Work explicitly cancelled or declined | Exclude from open Action Items; retain provenance |
+
+`suggestion` is represented as `possible_next_step` or `recommendation`, depending on whether the speaker advocates it. `accepted_action` and `assigned_work` should not be competing lifecycle states: both establish `established_action`, while the independent commitment basis records `accepted`, `assigned`, `self_committed` or `confirmed_existing`. This avoids an artificial choice when, as with Nina, an assignment and acceptance occur together.
+
+Responsibility is independent:
+
+| Responsibility status | Meaning | May populate `responsible`? |
+| --- | --- | --- |
+| `unset` | No person/team explicitly tied to ownership | No |
+| `proposed` | A person is suggested, asked speculatively or mentioned near the work | No |
+| `assigned` | The meeting explicitly assigns the work | Yes |
+| `accepted` | The party explicitly accepts or volunteers | Yes |
+| `confirmed` | Existing ownership is explicitly confirmed | Yes |
+
+This preserves the project invariant: discussion, expertise, adjacency, organizational role and likely ownership never establish responsibility. An action may be valid with `responsibility_status: unset`, as with established CET work.
+
+### Information-need kinds and resolution
+
+Question form and resolution are separate attributes.
+
+| Kind | Meaning | Can become an Open Question? |
+| --- | --- | --- |
+| `uncertainty` | Speaker expresses doubt or lack of certainty without establishing a concrete need | No, by itself |
+| `curiosity` | Interest without a concrete need requiring follow-up | No, by itself |
+| `explicit_question` | Direct interrogative seeking an answer | Yes, if unresolved |
+| `request_for_clarification` | Explicit request to clarify a concrete matter | Yes, if unresolved |
+| `missing_information` | Concrete required information is stated as absent | Yes, if unresolved |
+| `rhetorical_question` | Interrogative used for emphasis rather than an answer | No |
+
+Resolution is one of `unresolved`, `resolved`, or `resolution_unclear`. `resolved_question` is therefore not a separate kind: it is, for example, `explicit_question + resolved`. The publication example is `explicit_question + unresolved`; the event-program example is `explicit_question + resolved`; the washing example is `uncertainty` unless later evidence establishes a concrete unresolved need. `resolution_unclear` preserves evidence but should not silently pass a precision-first Open Question policy.
+
+An “unresolved question” is a derived, protocol-relevant combination rather than a fourth kind. This makes the classification testable: kind answers what communicative act occurred, and resolution answers what remained at the end of the available context.
+
+## Progeo examples under the model
+
+| Evidence | Proposed representation | Working Protocol policy result |
+| --- | --- | --- |
+| Chemical recycling “Option steht im Raum” | `decision / option / explicit` | Not a Decision |
+| Technikum preference | `decision / preferred_option / direct`; personal scope preserved | Not a Decision |
+| Schlummer collaboration rejected and “entschieden” | `decision / decision / explicit / negative` | Decision |
+| Geometry “kann man vielleicht … optimieren” | `action / possible_next_step / direct`, responsibility unset | Not an Action Item |
+| Marleen “müsste vielleicht mal” | `action / requested_action / direct`, responsibility proposed only | Not an Action Item; no responsible party |
+| Textor “könnten … kontaktieren” | `action / possible_next_step / direct`, responsibility unset | Not an Action Item |
+| Nina asks and accepts the review by Friday | `action / established_action / explicit`, basis assigned + accepted, responsible Nina, deadline Friday | Action Item |
+| CET article “erstellen wir bereits” and later circulation | `action / ongoing_work / explicit`, responsibility unset | Action Item without invented owner |
+| Washing “ob sich das lohnt, weiß ich nicht” | `information_need / uncertainty / direct`, resolution unclear | Not an Open Question |
+| Event program asked and answered | `information_need / explicit_question / direct`, resolved | Not an Open Question |
+| Publishable energy-audit data “weiterhin ungeklärt” | `information_need / explicit_question / explicit`, unresolved | Open Question |
+
+These labels preserve every BUG-015 distinction without treating rejected protocol candidates as meaningless.
+
+## Thematic protocol as the primary structure
+
+The Evidence / Commitment Model supplies semantic distinctions inside a larger
+meeting reconstruction. It does not imply that the primary protocol should be
+organized as one section per semantic category.
+
+The central Version 2 requirement is:
+
+> **The protocol is primarily a topic-oriented reconstruction of the meeting, not a category-oriented listing of extracted information.**
+
+A primary protocol should reconstruct which topics were discussed, what
+relevant information emerged within each topic, how the discussion developed,
+which alternatives, ideas, objections or proposals mattered, what outcome or
+current state was reached, and which actions or unresolved questions resulted
+from that topic.
+
+Semantic categories remain essential, but as metadata and supporting structure
+attached to topics. Facts, technical findings, ideas, alternatives, proposals,
+objections, decisions, action items and open questions must not dictate the
+main document structure.
+
+For example, a human-style topic section may read:
+
+```text
+## Trial setup
+
+Several variants for the next trial were discussed.
+
+A thinner carrier material was proposed as one possible alternative.
+Concerns were raised regarding its mechanical suitability.
+The group therefore decided to continue with the existing setup for the next trial.
+
+Nina will obtain the remaining samples before the next production run.
+
+The publication question remains unresolved.
+```
+
+This preserves the relationship between the proposal, objection, decision,
+resulting work and unresolved question. A primary document split into separate
+Ideas, Objections, Decisions and Action Items sections would lose that thematic
+and conversational relationship.
+
+Category-oriented outputs remain valuable as derived secondary views. An
+Action Item table, Decision register, Open Questions list or Management summary
+can be generated from the same underlying meeting knowledge after thematic
+reconstruction. These indexes and summaries do not replace the primary
+topic-oriented protocol.
+
+The conceptual Version 2 flow is:
+
+```text
+Transcript
+    ->
+Evidence Extraction
+    ->
+Topic Reconstruction
+    ->
+Semantic Synthesis
+    ->
+Protocol Rendering
+```
+
+Evidence items and their semantic metadata remain attached to topics and
+support Semantic Synthesis. The Version 2 renderer should receive
+topic-oriented semantic knowledge rather than a flat collection grouped by
+category. This direction does not define the final Topic Reconstruction schema,
+redesign the current pipeline or remove the existing Working Protocol V2
+architecture. It is an accepted target architecture whose implementation is
+postponed.
+
+## Architectural impact
+
+### Extraction
+
+Extraction could emit evidence records with richer labels instead of immediately claiming `decision`, `action_item` or `open_question`. This is a bounded increase in extraction vocabulary, not a request for larger context windows, a multi-chunk strategy or a monolithic synthesis prompt. Existing Facts, Positions and Technical Details remain distinct categories; the new domains refine only commitment-sensitive content.
+
+The immediate output would describe the observed state. Protocol category selection would happen later through an explicit policy. Some policy rules can be deterministic once semantic labels are trustworthy, for example:
+
+```text
+Decision       := domain=decision AND state=decision
+Action Item    := domain=action AND state IN {established_action, ongoing_work}
+Open Question  := domain=information_need
+                  AND kind IN {explicit_question, request_for_clarification, missing_information}
+                  AND resolution=unresolved
+Responsible    := responsibility_status IN {assigned, accepted, confirmed}
+```
+
+This keeps downstream selection simple, but does not make semantic extraction deterministic. The LLM still has to distinguish proposals from decisions and uncertainty from unresolved needs.
+
+### LLM stability
+
+The architecture should reduce one source of instability: the model no longer has to erase a supported proposition merely because it falls below a protocol threshold, nor relocate it into another category to retain it. Labels correspond more closely to observable speech acts and lifecycle statements, and downstream thresholds become explicit.
+
+It will not eliminate instability. More labels create adjacent-class boundaries, local context may not reveal resolution, and indirect language remains difficult. Stability depends on small schemas, evidence spans, one best supported state, conservative handling of `resolution_unclear`, and later evaluation against the Gold corpus. A generic evidence-strength score alone would likely worsen instability because it invites subjective grading.
+
+### Canonicalizer
+
+The Canonicalizer would benefit from carrying normalized state names, independent responsibility fields, resolution, polarity and stable source references. It could deterministically validate allowed combinations, normalize aliases, preserve evidence, group exact duplicates and reject structurally impossible combinations. It must not promote a proposal to a decision, infer resolution, infer responsibility or perform uncertain semantic merging.
+
+Richer labels make safe comparisons easier: two `option` records can be recognized as candidates about the same subject without being merged into a `decision`; an `explicit_question + resolved` item is not confused with an unresolved instance. Provenance improves because a later decision can link back to earlier option/proposal evidence rather than overwriting it.
+
+Semantic merging becomes better informed, but not automatically easy. Equivalence and lifecycle transitions remain semantic work. A future consolidator should preserve all source evidence, distinguish duplicate evidence from state evolution, and mark contradictions or uncertainty rather than collapsing them.
+
+### Renderer and output policy
+
+The renderer should not make commitment classification decisions. A
+policy/view-selection stage should determine protocol-worthy semantic states
+while preserving their topic associations. In the Version 2 target
+architecture, the primary protocol renderer should receive topic-oriented
+semantic knowledge containing eligible evidence and state transitions, not a
+flat category-oriented collection. It must not silently promote raw proposals
+to Decisions or present conversational coordination as Meeting Content.
+
+Proposals may still be visible to a renderer for a view explicitly designed to show them, such as a discussion appendix or editorial drafting view. That access must be typed and intentional; a renderer must never silently format a proposal under “Decisions.” Different output views may select different states while sharing the same Canonical Meeting Knowledge.
+
+Category-oriented renderers remain valid for secondary views such as Action
+Item tables, Decision registers and Open Questions lists. This accepted
+direction supplements rather than removes the current Working Protocol V2
+architecture; it does not change current rendering behavior.
+
+### Future BPD-style protocol generation
+
+Richer labels would give editorial generation better material without granting it authority to invent commitment. A BPD-style view could explain the path from options through tentative agreement to decision, separate current obligations from completed work, and describe why an information need remains open. Proposals and preferred options could be useful appendix material when the requested view values discussion history.
+
+The editorial layer may condense or order these records, but it must preserve state, polarity, responsibility status and provenance. Appendix inclusion is a view policy, not a semantic promotion.
+
+## Trade-offs
+
+Benefits:
+
+- preserves valid evidence below the final-protocol threshold;
+- separates meeting semantics from publication policy;
+- represents established work without inventing an assignment event or owner;
+- treats question kind and resolution independently;
+- makes responsibility independently auditable;
+- improves provenance across lifecycle changes;
+- prevents renderers from silently converting proposals into commitments;
+- gives future editorial views useful, explicitly non-final material.
+
+Costs and risks:
+
+- expands the extraction schema and Gold specification;
+- introduces adjacent semantic labels that require precise definitions;
+- requires consolidation to distinguish duplicates from state transitions;
+- may retain more evidence records, increasing storage and review volume;
+- depends on adequate local context to determine resolution and lifecycle state;
+- requires explicit view policies so consumers do not treat every evidence record as protocol-worthy;
+- cannot guarantee LLM consistency merely by replacing a binary verdict with a taxonomy.
+
+The taxonomy should remain closed and small. In particular, modality, confidence, support, commitment state and responsibility must not be collapsed into a single scalar.
+
+## Migration strategy
+
+This is a staged design path, not a recommendation to implement it now.
+
+1. Specify the taxonomy and invariants against the existing BUG-015 Gold candidates and the cited Progeo excerpts, without changing current expected outputs.
+2. Annotate a design-only mapping from each current Decision, Action Item and Open Question example to evidence state, support and independent attributes. Confirm objectively unique ground truth, especially for `requested_action` versus `possible_next_step` and `tentative_agreement` versus `preferred_option`.
+3. Define a versioned evidence-record schema and deterministic protocol-selection policy on paper. Keep responsibility and question resolution independent.
+4. Design evaluation measures separately for state accuracy, resolution accuracy, responsibility accuracy and protocol-policy output. A correct lower state must not count as a false protocol commitment.
+5. Only after the design is validated, plan an experiment that compares the evidence-first approach with current extraction and the binary verifier. Any prompt or Python changes would be separate, explicitly scoped tasks following the Gold methodology and LLM safety rules.
+6. If later adopted, preserve compatibility through an adapter that maps protocol-worthy evidence states to the current canonical categories while Canonical Meeting Knowledge evolves. Do not ask the renderer to interpret raw states.
+
+No database, prompt, code, test or current output-schema migration is proposed by this document.
+
+## Open questions
+
+- Is `requested_action` useful as a distinct state when a direct assignment already creates `established_action`, or should it be limited to unaccepted requests?
+- Does `tentative_agreement` have sufficiently unique evidence in the current corpus, or should it remain an annotation until more Gold examples exist?
+- Should an ongoing-work item whose relevance to the meeting is unclear pass the Working Protocol policy, or require an explicit continuation/follow-up signal?
+- How much local context is required to label a question `resolved` safely when the answer occurs across a technical chunk boundary?
+- Should `resolution_unclear` be retained only in Canonical Meeting Knowledge, or also exposed to a review view?
+- Should support be limited to `direct / explicit`, treating `indirect` as review-only, to reduce subjective classification?
+- How should consolidation represent one subject moving from proposal to decision: linked immutable evidence records, or a current-state object with a preserved event history?
+- Which output views, if any, should include withdrawn proposals, cancelled work and resolved questions?
+- Can polarity and lifecycle links be normalized deterministically without introducing semantic inference?
+
+## Recommendation
+
+The evidence-first architecture should replace the current binary keep/reject classification approach as the target architecture. The replacement should be conceptual and staged, not implemented yet: extract a small, domain-specific semantic state plus independent support, responsibility and resolution attributes; preserve evidence and provenance; then apply explicit policy to produce protocol categories.
+
+A single common Evidence Strength axis should complement this taxonomy but must not replace it. The decisive improvement is separation of semantic state from protocol eligibility. That separation directly explains the BUG-015 false positives and false negatives, supports the Progeo cases without invented ownership, simplifies view selection, and provides a sounder basis for Canonical Meeting Knowledge and future BPD-style rendering.

docs/diarization.md

@@ -0,0 +1,67 @@
+# Optional Speaker Diarization
+
+The direct-protocol MVP keeps speaker diarization disabled by default. Enable
+anonymous Community-1 speaker labels with `--diarization auto`, `gpu`, or
+`cpu`:
+
+```bash
+python3 scripts/run_mvp_meeting.py meeting.wav \
+  --whisper-model /path/to/ggml-model.bin \
+  --diarization auto
+```
+
+Native mode (the default runtime) requires a compatible local PyTorch and
+`pyannote.audio==4.0.7`. For isolated ROCm/CUDA environments, select the
+container runtime and provide its image and hardware arguments explicitly:
+
+```bash
+python3 scripts/run_mvp_meeting.py meeting.wav \
+  --whisper-model /path/to/ggml-model.bin \
+  --diarization gpu \
+  --diarization-runtime container \
+  --diarization-container-image IMAGE \
+  --diarization-container-arg=--device=/dev/kfd \
+  --diarization-container-arg=--device=/dev/dri \
+  --diarization-container-arg=--group-add \
+  --diarization-container-arg=video
+```
+
+The container receives `HF_TOKEN` by environment-variable name only. It mounts
+the source audio and repository read-only and writes diarization artifacts into
+the current run directory. Meeting Lab loads mono 16 kHz PCM16 WAV with
+Python's `wave` module and sends an in-memory tensor to pyannote, avoiding its
+torchcodec file decoder.
+
+Anonymous `SPEAKER_XX` labels are aligned to Whisper segments by maximum
+temporal overlap with Community-1 exclusive diarization. The original Whisper
+transcript is preserved; the derived transcript under `diarization/` is used as
+the direct-protocol generator's source input.
+
+The full diarized JSON and timestamped text remain immutable audit artifacts,
+but their per-segment formatting is too verbose for a full-meeting LLM prompt:
+timestamps and repeated speaker labels can more than double input size. For
+protocol generation, Meeting Lab deterministically groups only adjacent
+segments assigned to the same anonymous speaker and omits timestamps. A later
+return by the same speaker starts a new block, and unassigned segments remain
+under `SPEAKER_UNASSIGNED`. `protocol/transcript_input.txt` preserves the exact
+derived representation sent to prompt construction.
+
+Before contacting Ollama, Meeting Lab conservatively estimates prompt tokens
+from UTF-8 byte count without adding a model tokenizer dependency. The default safe
+budget is 29,000 estimated tokens within the explicitly configured 32,768-token
+Ollama context. The estimate is calibrated against the currently validated
+German BPD input and is configurable through
+`MvpMeetingConfig.protocol_safe_input_token_budget` or
+`--protocol-safe-input-token-budget`.
+
+If compact diarized input exceeds the budget, the generator deterministically
+uses the complete plain segment transcript and records the fallback. If that
+also exceeds the budget, generation fails before model lookup or generation;
+it never truncates, chunks, summarizes, retries, or makes multiple protocol
+calls implicitly. Full diarization artifacts are never overwritten by this
+selection.
+
+Glossary aliases are recorded as configuration provenance, never applied as
+deterministic replacements to the compact/plain protocol input. Canonical
+terminology guides generation through Meeting Context. Raw Whisper and
+diarization artifacts remain unchanged. `glossary_replacements` is always empty.

docs/meeting-context.md

@@ -0,0 +1,346 @@
+# Meeting Context V1
+
+## Purpose
+
+Meeting Context V1 is a manually maintained YAML file for reliable meeting
+metadata. It gives later pipeline stages known names, aliases, organizational
+terms and vocabulary without asking an LLM to infer them from a transcript.
+
+The context is authoritative only for metadata that is explicitly supplied in
+the file. It must not be used to infer responsibilities, decisions or
+commitments.
+
+## Scope
+
+V1 is implemented for loading, validation and optional injection into the
+chunk extraction prompt. It is not yet integrated with the Canonicalizer,
+Semantic Consolidator, Canonical Meeting Knowledge or output renderers.
+
+Supported metadata:
+
+- meeting title, language, date, objective and notes
+- actual participants and participant aliases
+- participant role and department when known
+- known non-participants mentioned during the meeting
+- known departments and aliases
+- abbreviations
+- relevant products, projects, systems, locations and technical terms
+
+## Future Direction: V2
+
+Accepted Architecture. Implementation deferred.
+
+Meeting Context V2 should be generated from an interactive entity confirmation
+workflow after Whisper transcription:
+
+```text
+Whisper
+    ↓
+Entity Detection
+    ↓
+User Confirmation
+    ↓
+Entity Registry Update
+    ↓
+Meeting Context Builder
+    ↓
+meeting_context.yaml
+    ↓
+Extraction Pipeline
+```
+
+The YAML remains the extraction interface and the authoritative
+meeting-specific Point of Truth for a meeting run. It should become a
+meeting-specific snapshot generated or assisted from the Entity Registry, user
+confirmations and meeting metadata.
+
+The Entity Registry is the persistent cross-meeting knowledge source for
+confirmed entities, aliases and organizational metadata. It stores stable
+internal identifiers and never learns automatically. The Registry must not
+override explicit meeting-specific confirmations, and Registry changes after a
+meeting run must not silently change the historical Meeting Context used for
+that run.
+
+Unknown names should be explicitly classified by the user as meeting
+participant, mentioned person, external person, transcription error or ignore.
+Similarity suggestions for spelling variants, Whisper variants, umlaut
+handling and OCR-like mistakes require explicit confirmation.
+
+See `docs/adr-meeting-context-v2-entity-registry.md`.
+
+## File Locations
+
+- Generic template: `samples/templates/meeting_context.template.yaml`
+- Real-Life Sample context:
+  `samples/real_live/project_process_meeting/meeting_context.yaml`
+- Future meeting-specific contexts should live next to the meeting input data.
+
+## Field Descriptions
+
+`schema_version`: Version of the Meeting Context file shape.
+
+`meeting.title`: Required for future GUI entry. Human-readable meeting title.
+
+`meeting.meeting_id`: Required stable meeting identifier used for extraction
+context provenance.
+
+`meeting.language`: Required for future GUI entry. Dominant meeting language,
+for example `de` or `en`.
+
+`meeting.date`: Optional ISO date or `null`.
+
+`meeting.objective`: Optional objective entered by the user.
+
+`meeting.notes`: Optional neutral notes about context or scope.
+
+`participants`: Actual meeting attendees. Participant names are required for
+future GUI entry.
+
+`participant_id`: Stable identifier. It should not change when display names
+or aliases are corrected.
+
+`display_name`: Preferred display name.
+
+`aliases`: Alternative spellings, short forms or Whisper variants.
+
+`role`: Organizational function. Optional and nullable.
+
+`department`: Organizational unit. Optional and nullable.
+
+`attendance_status`: exactly `present` for participants or `mentioned_only` for
+people who are relevant but did not attend. For backward compatibility, a
+missing status defaults to `present` in `participants` and `mentioned_only` in
+`mentioned_people`.
+
+`mentioned_people`: People discussed or referenced but not present. They are
+not participants and must not be treated as speakers.
+
+`organization.name`: Optional organization name.
+
+`organization.departments`: Known departments with stable ids, names and
+aliases.
+
+`organization.abbreviations`: Known abbreviation expansions. Empty strings mean
+the expansion is not yet confirmed.
+
+`known_entities`: Meeting vocabulary for projects, products, systems,
+locations and technical terms. These lists do not imply responsibility.
+
+`context_rules`: Conservative defaults for later integrations.
+
+## Filled Example
+
+```yaml
+schema_version: "1"
+
+meeting:
+  title: "Projektprozess fuer neue Initiativen"
+  language: "de"
+  date: "2026-08-01"
+  objective: "Klaeren, wie der bestehende Projektprozess angepasst wird."
+  notes: ""
+
+participants:
+  - participant_id: "martin"
+    display_name: "Martin"
+    aliases: ["Martin T."]
+    role: null
+    department: null
+    attendance_status: "present"
+    notes: null
+
+mentioned_people:
+  - person_id: "alex"
+    display_name: "Alex"
+    aliases: []
+    role: null
+    department: null
+    attendance_status: "mentioned_only"
+    notes: "Wurde erwaehnt, war aber nicht anwesend."
+
+organization:
+  name: null
+  departments:
+    - id: "pm"
+      name: "PM"
+      aliases: ["Projektmanagement"]
+  abbreviations:
+    PM: "Projektmanagement"
+    BD: "Business Development"
+    MK: ""
+    GF: ""
+
+known_entities:
+  projects: []
+  products: []
+  systems: []
+  locations: []
+  technical_terms: ["Lastenheft"]
+
+context_rules:
+  participant_list_is_authoritative: true
+  do_not_infer_roles: true
+  do_not_infer_departments: true
+  do_not_infer_responsibilities: true
+  mentioned_people_are_not_participants: true
+```
+
+## Concept Distinctions
+
+Participant: a person who actually attended the meeting.
+
+Mentioned person: a person discussed or referenced but not present.
+
+Speaker: transcript-level attribution, which may be unknown or unreliable.
+
+Responsible person: a person explicitly assigned to or accepting an action
+item.
+
+Role: the person's organizational function.
+
+Department: the organizational unit to which the person belongs.
+
+These concepts must never be collapsed automatically. A participant may discuss
+a topic outside their own department. Discussing, objecting to or suggesting
+work does not establish responsibility.
+
+## Editing Guidance
+
+Enter only objective context that is known independently or confirmed by the
+user. Do not guess uncertain names, roles, departments or abbreviation
+expansions. Leave unknown values as `null`, an empty string or an empty list.
+
+Use aliases for spelling variants, shortened names and Whisper variants. Keep
+stable ids unchanged after a context file has been used in experiments.
+
+Do not copy responsibilities from generated protocols into Meeting Context.
+Responsibilities belong to evidence-backed extraction and later action-item
+models, not to this metadata file.
+
+## Extraction Integration
+
+The chunk extraction CLI accepts an optional Meeting Context file:
+
+```text
+PYTHONPATH=src .venv/bin/python -m meeting_lab.extraction.extract_chunks \
+  samples/chunks/chunk_01_normalized.txt \
+  -o /tmp/chunk_01_extraction.json \
+  --meeting-context samples/real_live/project_process_meeting/meeting_context.yaml
+```
+
+When supplied, the file is validated and rendered as deterministic
+authoritative metadata inside the extraction prompt. When omitted, prompt
+construction and extraction output remain unchanged.
+
+The shared extraction prompt is assembled from:
+
+- `common.md`
+- `decisions.md`
+- `todos.md`
+
+Extraction JSON receives only minimal context provenance:
+
+```json
+{
+  "context": {
+    "meeting_id": "2026-07-27-projektprozess",
+    "source_file": "samples/real_live/project_process_meeting/meeting_context.yaml",
+    "schema_version": "1"
+  }
+}
+```
+
+Full personal metadata is not copied into every extraction result.
+
+Meeting Context loading uses PyYAML when installed. `PyYAML>=6.0` is declared
+as a project dependency.
+
+## Prompt Behavior
+
+Meeting Context validates identity, role, department and attendance, but never
+establishes responsibility.
+
+The todo prompt records a named responsible person only when the transcript
+explicitly assigns the task, the person volunteers, or the person accepts or
+confirms the task. Addressing a person, requesting department input, discussing
+department-specific criteria, stating expertise, objecting, suggesting, or
+listing Meeting Context role metadata is not enough.
+
+The decision prompt treats a personal commitment to concrete future work as a
+todo unless the group separately establishes a binding outcome, rule, approval,
+rejection, deferral, selection, process state or responsibility policy. The
+same proposition should not be duplicated under decisions and todos; extract
+both only when the transcript contains semantically separate propositions.
+
+## Validation Rules
+
+The current validator checks that:
+
+- YAML syntax is valid
+- `schema_version` is supported
+- `meeting.meeting_id`, `meeting.title` and `meeting.language` are present
+- participant ids are unique and non-empty
+- mentioned-person ids are unique and non-empty
+- participant ids and mentioned-person ids do not collide
+- referenced departments exist in `organization.departments`
+- `attendance_status` values are valid
+- speaker mappings reference present participants only; mentioned-only people
+  cannot be diarized speakers
+- participants are marked `present`
+- mentioned people are not marked `present`
+
+Invalid values are not inferred or repaired.
+
+## Gold Tests
+
+Two focused Gold scenarios cover the main responsibility boundary:
+
+- `responsibility_attribution_negative`: discussion, objection and department
+  proximity must not create a named owner.
+- `position_explicit_objection`: explicit objection extraction is tested
+  separately as a position scenario.
+
+Responsibility attribution and position extraction are intentionally tested
+independently so each scenario has unique ground truth.
+
+## Confidentiality
+
+Meeting Context can contain real names, departments, project names and internal
+terminology. Treat it as confidential meeting data. Keep private sample
+contexts inside the private repository and avoid exposing them in screenshots,
+logs or generated reports.
+
+## Future GUI Entry
+
+Future product UI should make these fields easy to enter before processing.
+
+Required GUI fields:
+
+- meeting title
+- language
+- participant names
+
+Optional GUI fields:
+
+- objective
+- aliases
+- role
+- department
+- mentioned non-participants
+- abbreviations
+- known entities
+- notes
+
+## Future Pipeline Integration
+
+Later stages may use Meeting Context to normalize names, recognize aliases,
+avoid treating absent mentioned people as speakers and avoid expanding
+abbreviations incorrectly. This later-stage integration is still planned.
+
+Integration must remain conservative:
+
+- Meeting Context may supply metadata only.
+- It must not infer decisions.
+- It must not infer responsibilities.
+- It must not override source evidence.
+- It must preserve uncertainty when transcript evidence is ambiguous.

docs/output-views.md

@@ -0,0 +1,228 @@
+# 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

docs/pipeline.md

@@ -10,10 +10,28 @@ The guiding principle is simple:
 
 > **Each processing stage has exactly one responsibility.**
 
+Cross-cutting invariant:
+
+> **Responsibility attribution requires explicit evidence.**
+
+A person, team or department may be recorded as responsible only when the
+source material explicitly assigns, accepts or confirms that responsibility.
+The pipeline must not infer ownership from thematic proximity, discussion
+participation, mentioning a task, commenting on another department,
+organizational assumptions, likely job roles, speaker adjacency or model world
+knowledge.
+
+When support is incomplete or ambiguous, leave the responsible person unset,
+mark the item as unclear where supported, and preserve the attribution
+evidence. This applies to extraction, canonicalization, semantic consolidation,
+Canonical Meeting Knowledge and every Output View renderer.
+
 ---
 
 # Pipeline Overview
 
+Current analysis pipeline:
+
 ```text
 Whisper Transcript
         │
@@ -33,17 +51,70 @@ Topic Segmentation
 Specialized Extraction
         │
         ▼
-Consolidation
+Deterministic Canonicalization
         │
         ▼
-Structured Meeting
+Semantic Consolidation
         │
         ▼
-Protocol Generation
+Canonical Meeting Knowledge
+        │
+        ▼
+Output View Rendering
+        │
+        ├── Working Protocol
+        ├── Distribution Protocol
+        └── Knowledge Objects
 ```
 
 Each stage receives a well-defined input and produces a well-defined output.
 
+Meeting Context V1 exists as a manually maintained YAML metadata scaffold. It
+is implemented for validation, optional `--meeting-context` use during chunk
+extraction, deterministic prompt injection and minimal extraction JSON
+provenance. Later Canonicalizer, Semantic Consolidator, Canonical Meeting
+Knowledge and renderer integration remains future work.
+
+Accepted future Meeting Context V2 preparation flow:
+
+```text
+Whisper
+        │
+        ▼
+Entity Detection
+        │
+        ▼
+User Confirmation
+        │
+        ▼
+Entity Registry Update
+        │
+        ▼
+Meeting Context Builder
+        │
+        ▼
+meeting_context.yaml
+        │
+        ▼
+Extraction Pipeline
+```
+
+This preparation flow is not implemented. It is the accepted long-term
+direction for reducing manual Meeting Context work while preserving explicit
+user control. The Entity Registry is the persistent cross-meeting knowledge
+source for confirmed entities, aliases and organizational metadata. It stores
+stable internal IDs and confirmed aliases, and never updates itself
+automatically.
+
+For each meeting run, `meeting_context.yaml` remains the authoritative
+meeting-specific Point of Truth and reproducible input artifact consumed by the
+pipeline. V2 changes how that artifact is prepared: it may be generated or
+assisted from Registry data, user confirmations and meeting metadata. The
+Registry must not override explicit meeting-specific confirmations, and
+Registry changes after a meeting run must not silently change the historical
+Meeting Context used for that run. Similarity suggestions and unknown entity
+classifications require explicit user confirmation.
+
 ---
 
 # Stage 1 – Normalization
@@ -128,7 +199,15 @@ Deterministic
 
 ## Current Status
 
-Planned
+Implemented as Canonicalizer V1.
+
+CLI:
+
+```text
+PYTHONPATH=src .venv/bin/python -m meeting_lab.consolidation.canonicalize \
+  samples/whisper/meeting_speech_cleaned_chunks \
+  -o /tmp/canonicalized_extractions.json
+```
 
 ---
 
@@ -224,7 +303,7 @@ LLM
 
 ## Current Status
 
-Planned
+Implemented as Canonicalizer V1.
 
 ---
 
@@ -253,6 +332,22 @@ Each extractor has:
 - one responsibility
 - one output schema
 
+The current shared extraction prompt is assembled from:
+
+- `common.md`
+- `decisions.md`
+- `todos.md`
+
+The todo prompt requires explicit assignment, volunteering or acceptance before
+recording a named responsible person. Meeting Context may validate identity,
+role, department and attendance, but never establishes responsibility.
+
+The decision prompt treats a personal commitment to concrete future work as a
+todo unless the group separately establishes a binding outcome, rule, approval,
+rejection, deferral, selection, process state or responsibility policy. The
+same proposition should not be duplicated under decisions and todos; extract
+both only for semantically separate propositions.
+
 ## Processing Type
 
 LLM
@@ -263,35 +358,41 @@ Prototype exists as a combined extractor.
 
 ---
 
-# Stage 6 – Consolidation
+# Stage 6 – Deterministic Canonicalization
 
 ## Purpose
 
-Merge analysis results originating from different discussion segments.
+Normalize raw chunk extraction JSON into stable canonical extraction objects
+without changing uncertain semantics.
 
 ## Input
 
-Extraction results.
+Chunk extraction JSON files.
 
 ## Output
 
-Unified topic representation.
+Validated canonical extraction objects with stable source references and IDs.
 
 ## Responsibilities
 
-- Merge duplicates
-- Merge complementary information
-- Preserve contradictions
-- Separate positions from decisions
-- Combine related todos
+- Validate extraction objects
+- Normalize category names
+- Normalize basic field structure
+- Assign stable source references and IDs
+- Preserve all source evidence
+- Perform only safe deterministic cleanup
+- Group exact duplicates where unambiguous
+
+## Must Not
+
+- Use an LLM
+- Perform uncertain semantic merging
+- Infer missing information
+- Drop source evidence
 
 ## Processing Type
 
-Hybrid
-
-Deterministic wherever possible.
-
-LLM support only if necessary.
+Deterministic Python
 
 ## Current Status
 
@@ -299,13 +400,64 @@ Planned
 
 ---
 
-# Stage 7 – Structured Meeting
+# Stage 7 – Semantic Consolidation
 
 ## Purpose
 
-Produce a complete machine-readable representation of the meeting.
+Merge canonicalized extraction objects into an evidence-preserving semantic
+meeting representation.
 
-This is the primary output of the analysis pipeline.
+## Input
+
+Canonicalized extraction objects.
+
+## Output
+
+Semantic Consolidator V0 output is `consolidated_extractions.json` with fact
+groups and unchanged non-fact items.
+
+Future broader semantic consolidation should produce Canonical Meeting
+Knowledge.
+
+## Responsibilities
+
+- V0: merge semantically equivalent fact items only
+- V0: preserve all non-fact categories unchanged
+- V0: validate that every source fact ID appears exactly once
+- Future: merge semantically equivalent statements across categories
+- Future: group content by topic
+- Preserve evidence from all contributing chunks
+- Future: mark contradictions and uncertainty
+- Future: separate durable information from transient discussion
+- Future: reconcile category shifts where supported by evidence
+
+## Must Not
+
+- Directly write a protocol
+- Invent information
+- Drop conflicting evidence silently
+
+## Processing Type
+
+Local LLM, with deterministic pre/post-processing where useful.
+
+## Current Status
+
+Semantic Consolidator V0 is implemented and experimentally validated for
+facts-only conservative duplicate detection. Broader semantic consolidation and
+Canonical Meeting Knowledge generation remain planned.
+
+---
+
+# Stage 8 – Canonical Meeting Knowledge
+
+## Purpose
+
+Produce the canonical semantic representation of one meeting.
+
+This representation is the single source of truth for all downstream outputs.
+It is a structured representation, preferably JSON, and is not itself a prose
+protocol.
 
 Example:
 
@@ -326,29 +478,63 @@ Example:
 
 The exact schema will evolve during development.
 
+Conceptually, the Canonical Meeting Knowledge should 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 remains future implementation work.
+
 ## Current Status
 
 Planned
 
 ---
 
-# Stage 8 – Protocol Generation
+# Stage 9 – Output View Rendering
 
 ## Purpose
 
-Generate human-readable documents from structured meeting data.
+Render purpose-specific outputs from Canonical Meeting Knowledge.
 
-Possible outputs include:
+The planned output products are:
 
-- Full protocol
-- Executive summary
-- Action list
-- Decision log
-- Technical report
+- Working Protocol (`working_protocol.md`, Arbeitsprotokoll)
+- Distribution Protocol (`distribution_protocol.md`, Verteilerprotokoll)
+- Knowledge Objects, rendered as a Knowledge-base Entry (`knowledge_entry.md`)
+  and later stored in a structured format such as `knowledge_entry.json`
+  (Wissensdatenbankeintrag)
+- Later additional views such as action lists
 
-Protocol generation never performs additional analysis.
+Output rendering never performs additional analysis.
 
-It only transforms existing structured information into readable text.
+It only transforms existing structured information into the required view.
+
+The outputs are rendered in parallel from the canonical representation. The
+Distribution Protocol is not derived from the Working Protocol, and Knowledge
+Objects are not derived from either protocol.
+
+Rendering may be deterministic, template-based or LLM-assisted depending on the
+output and implementation maturity.
+
+Completeness differs by output:
+
+- The Working Protocol optimizes for recall and traceability.
+- The Distribution Protocol optimizes for relevance and brevity.
+- Knowledge Objects optimize for durability and reuse.
+
+Rendered protocol language should normally match the dominant language of the
+source transcript or consolidated meeting knowledge unless an explicit output
+language is requested.
 
 ## Processing Type
 
@@ -418,11 +604,18 @@ A processing stage may be replaced by another implementation as long as it prese
 
 ⬜ Specialized Extraction
 
-⬜ Consolidation
+✔ Deterministic Canonicalization
 
-⬜ Structured Meeting
+✅ Semantic Consolidation V0 - facts-only duplicate detection
 
-⬜ Protocol Generation
+⬜ Canonical Meeting Knowledge
+
+⬜ Output View Rendering
 ```
 
-The immediate development focus is **Topic Segmentation**, as it provides the semantic structure on which all subsequent processing stages depend.
+The immediate evaluation focus is using the Semantic Consolidator V0 output as
+input for the unchanged Working Protocol renderer. Canonicalizer V1 now
+preserves source evidence, and Semantic Consolidator V0 conservatively merges
+semantically equivalent fact items. Broader semantic consolidation should later
+recover global context from independent chunk extractions and prepare Canonical
+Meeting Knowledge for parallel Output View rendering.

docs/protocol-generation-regression.md

@@ -0,0 +1,25 @@
+# Direct-protocol regression reproduction
+
+The August 2026 glossary regression was isolated with frozen inputs. Condition
+A used the original derived transcript; condition B differed only by these
+seven deterministic substitutions:
+
+- `Carbofool` to `Carbofol` (two occurrences)
+- `Bento Fix` to `Bentofix` (two occurrences)
+- `Sikirgut-Heistlöse` to `Secugrid HS` (one occurrence)
+- `Lumini` to `Luminy` (two occurrences)
+
+To repeat the manual comparison, copy the investigated run to a new temporary
+directory, retain its Meeting Context and speaker mapping, and invoke
+`regenerate_mvp_protocol` through the same parameters used by Meeting
+Assistant. Never run the comparison in the historical run directory. Preserve
+the model, `num_ctx`, `num_predict`, temperature, think setting, thread setting,
+and Meeting Context. Compare the new generation's `exact_prompt.txt` and
+`transcript_input.txt` with the frozen A and B artifacts before comparing model
+output.
+
+The required fixed condition is A: configured glossary aliases remain visible
+in Meeting Context terminology guidance, while `transcript_input.txt` retains
+the original seven source spellings. Automated tests mock the model and enforce
+that invariant; this full historical experiment remains an explicit manual LLM
+validation so normal tests do not depend on a local model.

docs/protocol_generation_decision.md

@@ -0,0 +1,229 @@
+# Protocol Generation Decision
+
+## Executive Summary
+
+Meeting Lab tested ten protocol-generation and runtime variants against the
+same 93.5-minute reference meeting, `project_process_meeting`. The current
+evidence does not support a fully automatic protocol. The best practical local
+baseline remains one direct call to `qwen3.6:35B-A3B`, followed by informed
+human review. It is fast and produces readable, broadly useful Markdown, but it
+still overstates consensus, compresses unresolved process boundaries, misses
+some challenge and follow-up paths, and can infer unsafe ownership. Its current
+quality verdict is **C — promising but insufficient**.
+
+Additional prompting, review, Meeting Map, hierarchical, diarized, dense-model
+and 70B-scale variants did not produce a reliable step change. Some improved
+individual dimensions, but none reached a stable B result or removed the need
+for substantive review. This is a current evidence-based product choice, not a
+permanent architecture decision.
+
+## Experiments Compared
+
+All protocol rows used the complete cleaned transcript and meeting context
+unless stated otherwise. A dash means that the artifact did not record the
+number; it is not an estimate. Verdicts marked “assessment” are comparative
+assessments of saved outputs because those older artifact directories contain
+no formal `quality_review.json`.
+
+| Experiment | Model | Architecture | LLM calls | Prompt tokens | Runtime | Human editing | Verdict | Main strength | Main failure | MVP | Research |
+| --- | --- | --- | ---: | ---: | ---: | --- | --- | --- | --- | --- | --- |
+| Direct one-shot baseline | Qwen3.6 35B-A3B | Direct full-context protocol | 1 | 18,385 | 72.5 s cold; about 38 s inference | Not recorded | C | Fast, readable, broad topic outline | Consensus and ownership overpromotion; missing boundaries and follow-up | **Yes, with review** | Baseline |
+| Conservative one-shot | Qwen3.6 35B-A3B | Direct with stronger safety instructions | 1 | 19,120 | 39.5 s warm | Not recorded | C (assessment) | Better uncertainty and pending-feedback language | Still invents or upgrades named follow-up actions | No | Limited |
+| Draft → review | Qwen3.6 35B-A3B | Conservative draft plus review call | 2 | 39,071 total | About 110.4 s summed | Not recorded | C (assessment) | Removes some unsafe named attribution | Does not reliably restore omitted content; empty/weak action sections remain | No | Limited |
+| Meeting Map → protocol | Qwen3.6 35B-A3B | Semantic map followed by rendering | 2 | 39,129 total | 134.8 s | Not recorded | C (assessment) | Explicit intermediate structure | Map errors propagate: false consensus and named ownership remain | No | Yes |
+| Hierarchical notes → protocol | Qwen3.6 35B-A3B | Five chunk-note calls plus synthesis | 6 | 32,145 total | 251.1 s | Not recorded | C (assessment) | Highest recall in several detailed/open topics | Amplifies unsupported speaker/name interpretations and confirmed actions | No | Yes |
+| Segment-level anonymous diarization | Qwen3.6 35B-A3B | One-shot over 1,154 labeled segments | 1 | 39,308 | 125.4 s | 25–35 min | C | Preserves some filtered-idea challenge structure | Token count more than doubled; actions and deadlines became less safe | No | No further protocol tests |
+| Turn-merged anonymous diarization | Qwen3.6 35B-A3B | One-shot over 435 merged turns | 1 | 22,490 | 101.2 s | 25–35 min | C | Corrected token inflation; recovered some topic and feedback detail | Still did not beat raw input; unsafe actions/deadlines persisted | No | UI/search only |
+| Dense one-shot | Qwen3.5 27B | Direct full-context protocol | 1 | 18,385 | 181.2 s | Not recorded | C (assessment) | Somewhat better recall of process details | Much slower; no material overall quality gain | No | No |
+| 70B scale one-shot | Llama 3.3 70B Q3_K_S | Dense, 64% CPU / 36% GPU | 1 | 21,156 | 470.1 s warm | 45–60 min | D | Technically proved a 70B hybrid load can run | Severe coverage loss, invented governance, internal contradiction | No | Negative scale result |
+| Ollama vs native llama.cpp | Qwen3.6 35B-A3B | Same Q4_K_M GGUF; ROCm/Vulkan servers | 1 per backend | 18,385 | ROCm 38.4 s; Vulkan 42.3 s | N/A | Runtime only | Native ROCm reached 51.38 generated tok/s | No meaningful end-to-end advantage; more operational complexity | Ollama | Runtime reference |
+
+The draft-review total combines the saved conservative draft call and the
+saved review call. Its review metadata itself reports only the one new review
+call (19,951 prompt tokens and 70.8 seconds). The direct baseline's 72.5-second
+wall time includes a 34.5-second cold load; its measured prompt evaluation plus
+generation was 37.8 seconds. These distinctions explain apparent runtime
+differences between otherwise similar Qwen3.6 calls.
+
+### Recurring quality patterns
+
+- **Topic coverage and factual accuracy:** Direct Qwen3.6 captures the main
+  process but misses the second review after enrichment, project reporting and
+  parts of the filtered-idea challenge path. Hierarchical processing recalls
+  more detail but introduces too many unsupported interpretations. Llama 3.3
+  loses most of the meeting and invents a governance role for the
+  Geschäftsführung.
+- **Consensus and unresolved boundaries:** Every broad one-shot family remains
+  vulnerable to turning discussion or a working direction into agreement. The
+  unresolved boundary between central coordination and autonomous department
+  work, and the uncertainty around universal filter criteria, are especially
+  fragile.
+- **Visibility, veto and reconsideration:** No approach consistently preserves
+  initial filtering, later cross-functional challenge, reconsideration after
+  enrichment and the return through the project cycle together.
+- **Stakeholder feedback:** Pending Jovana and Björn feedback is an important
+  quality probe. Some variants preserve both; segment-level diarization drops
+  Björn, while Llama 3.3 drops both.
+- **Actions and attribution:** Added structure does not guarantee safety.
+  Conservative, reviewed, Meeting Map, hierarchical and diarized outputs still
+  promote proposals or expected work into confirmed actions, infer owners from
+  roles or conversational context, or invent deadlines. Human review remains
+  mandatory.
+
+## Model Findings
+
+### Qwen3.6:35B-A3B
+
+Qwen3.6 is the best overall local practical baseline. Its Q4_K_M model is
+operationally fast on the RX 9070/CPU hybrid setup, follows the requested
+Markdown form and usually provides a useful first draft. It remains verdict C:
+larger context and fluent synthesis do not reliably protect evidence strength,
+responsibility attribution or unresolved process boundaries.
+
+### Qwen3.5:27b dense
+
+The dense 27B run recalled some process details better than the MoE baseline,
+but took 181.2 seconds and generated at 8.45 tokens/s. The gains did not amount
+to a material overall quality improvement. This result does not prove that
+dense models are generally inferior; it shows that this dense model is not a
+better product choice on this hardware and meeting.
+
+### Llama 3.3 70B Q3_K_S
+
+Llama 3.3 70B was technically runnable at 32k context with a 42 GB loaded
+footprint and a 64% CPU / 36% GPU split. Its 7m50s warm meeting run produced a
+very short, materially worse protocol: one critical invented governance claim,
+five new major errors and an estimated 45–60 minutes of editing. Raw parameter
+count alone is therefore insufficient. The older model generation and
+aggressive Q3 quantization are plausible contributors, but this experiment
+does not isolate or prove either cause.
+
+## Runtime Findings
+
+The native comparison reused the exact 23,938,321,664-byte Qwen3.6 Q4_K_M GGUF
+that Ollama uses. The tested `llama-server` binary was the llama.cpp runtime
+shipped with the installed Ollama distribution, not an independent source
+build.
+
+Native ROCm processed the reference request in 38.4 seconds and generated at
+51.38 tokens/s. Vulkan took 42.3 seconds and generated at 46.73 tokens/s. The
+comparable Ollama baseline generated at 44.68 tokens/s, with about 37.8 seconds
+of prompt evaluation plus generation when load time is excluded. Output token
+counts differed, so generation throughput alone is not an end-to-end quality or
+latency comparison.
+
+Native ROCm gained some generation throughput, but did not provide a meaningful
+end-to-end advantage for this workload. Vulkan required more host spill and was
+not preferable. Ollama already provides the relevant llama.cpp runtime
+components, model lifecycle and API integration; it remains the preferred
+routine Meeting Lab runtime.
+
+## Diarization Findings
+
+### Technical feasibility
+
+Pyannote `speaker-diarization-community-1` successfully processed the
+93.5-minute meeting on CPU in 1,647 seconds (about 27m27s), an RTF of 0.293. It
+detected four anonymous clusters and assigned 1,145 of 1,154 Whisper segments
+(99.2%). Peak RSS was about 3.3 GiB. This establishes technical feasibility; it
+does not establish speaker identity or diarization accuracy against labeled
+ground truth.
+
+### Protocol-quality impact
+
+Annotating every Whisper segment increased the Qwen prompt from 18,385 to
+39,308 tokens, confounding speaker structure with fragmentation and token
+inflation. Deterministic turn merging reduced 1,154 segments to 435 turns and
+the complete prompt to 22,490 tokens. That controlled the main representation
+confound, but the resulting protocol still did not materially outperform the
+raw transcript and remained verdict C.
+
+Anonymous diarization is therefore not justified as a mandatory MVP
+protocol-quality feature. This does **not** mean diarization is generally
+useless. It may remain valuable for speaker-aware UI, navigation and search,
+participation statistics, traceability, or later carefully validated real-name
+mapping.
+
+## Semantic Research Findings
+
+The semantic experiments provide architectural evidence, but should not
+dominate the product decision:
+
+- **Evidence Observation V3** is a strong evidence-near candidate stage. With
+  Qwen3.5 9B it achieved 8 PASS, 1 PARTIAL and 0 FAIL while preserving hedges,
+  alternatives, requests, commitments and boundaries in natural language.
+- **Request/Acceptance** and **Collective Commitment** show that narrow semantic
+  recognition followed by deterministic provenance, ordering, addressee,
+  negation and deadline gates can safely derive limited consequences. Model
+  recognition errors were contained without inventing individual ownership.
+- **Explicit Rejection** failed when reduced to a coarse binary recognition
+  problem: semantically valid false positives passed structural gates.
+- **Negative Act Form** worked better by distinguishing non-pursuit, personal
+  preference, recommendation and temporary non-action before any normative
+  derivation. All eight form classifications matched Gold, although normalized
+  action text was imperfect in three cases.
+- **Target Resolution V0** failed because prompt examples and a weak JSON
+  boundary encouraged the string `"null"` instead of typed linkage.
+  **Target Resolution V1** fixed all linkage/ID failures with deterministic
+  self-linkage, closed ID lists and true JSON Schema, but normalization remained
+  incomplete.
+- **Target Normalization V0** improved polarity and scope preservation to 3/4
+  PASS, but still lost continuation meaning in the collaboration case.
+
+These findings support Meeting Lab as a research and validation track. They do
+not yet justify placing a multi-stage semantic pipeline on the MVP critical
+path.
+
+## Current MVP Decision
+
+The current product path is:
+
+```text
+Audio
+-> transcription
+-> direct qwen3.6:35B-A3B protocol generation through Ollama
+-> informed human review
+-> final protocol
+```
+
+The first MVP should treat the generated protocol as an editable draft, not an
+authoritative semantic record. Human review must specifically check consensus,
+unresolved boundaries, competing positions, action status, owners, deadlines
+and pending stakeholder feedback.
+
+Diarization is optional and deferred. The semantic research pipeline remains
+in Meeting Lab, outside the MVP critical path. Ollama remains the default local
+runtime.
+
+## Rejected / Deferred Directions
+
+- Do not continue Qwen3.6 prompt variants as the main quality strategy.
+- Do not add draft-review, Meeting Map or hierarchical generation to the MVP;
+  their added calls and complexity did not deliver reliable quality gains.
+- Do not continue anonymous-diarization protocol experiments. Revisit
+  diarization for UI, search, statistics or traceability instead.
+- Do not use Qwen3.5 27B or Llama 3.3 70B Q3_K_S as the routine protocol model.
+- Do not replace Ollama with a manually managed native llama.cpp service for
+  this workload.
+- Retain semantic experiments, but defer production integration and broad
+  semantic consolidation.
+
+## Open Questions
+
+1. How does a genuinely newer, materially stronger model perform when a useful
+   quantization fits the available RAM/VRAM without severe swap?
+2. If project policy permits, what quality ceiling does the unchanged reference
+   prompt achieve with a commercial frontier model?
+3. What is the measured reviewer time and correction distribution once the
+   direct Qwen3.6 draft path is exercised in an end-to-end MVP workflow?
+4. Which non-protocol product benefits justify revisiting diarization later?
+
+No further Qwen3.6 prompt variants, anonymous-diarization protocol runs or old
+70B Q3 scale tests are recommended.
+
+## Recommended Next Product Step
+
+Build the practical end-to-end MVP around direct Qwen3.6 generation and an
+explicit human review handoff. Measure reviewer time and correction categories
+in real use. Keep the experiment artifacts and semantic Gold work as validation
+evidence, but do not block the first product loop on broader research stages.

docs/quality-readiness.md

@@ -0,0 +1,54 @@
+# Quality Readiness
+
+Meeting Lab quality status should distinguish engineering readiness from
+practical usability.
+
+## Engineering Readiness
+
+Status: NOT READY
+
+The current end-to-end pipeline is not ready to replace the previous
+extraction pipeline. The latest quality milestone records seven known
+regression bugs, two documented root-cause investigations and a renderer
+faithfulness failure where consolidated items are omitted or reclassified.
+
+Engineering readiness requires at least:
+
+- faithful rendering of consolidated decisions, action items and open questions
+- no false responsibility attribution
+- no participant-attendance contradictions against Meeting Context
+- no unverified person/entity names entering final protocols unchecked
+- regression tests or validation coverage for fixed bugs
+
+## Practical Usability
+
+Status: READY FOR MANUAL EDIT
+
+The generated working protocol can still be useful as a draft when reviewed by
+a human editor against the known meeting content. This status does not imply
+engineering readiness and must not be used as evidence that the pipeline is
+faithful or production-ready.
+
+Practical usability means:
+
+- the broad meeting structure is recognizable
+- many relevant topics and process points are present
+- manual correction is still required before the protocol can be trusted
+
+Known manual correction areas include:
+
+- false or over-strong responsibility attribution
+- incorrect open questions
+- synthetic or unverified names from transcript artifacts
+- participant-attendance contradictions
+- reversed or over-broad process meaning
+
+## Current Benchmark Reference
+
+Latest benchmark reviewed for this distinction:
+
+- `samples/benchmarks/meeting_context_v1/e2e_current_20260803_151000/benchmark_report.md`
+
+The benchmark report concludes `NOT READY` for engineering replacement. This
+document adds the separate practical-usability classification for manual-edit
+workflows only.

docs/releases/v0.1.0-alpha.1.md

@@ -0,0 +1,25 @@
+# Meeting Assistant — First functional alpha
+
+Version: `0.1.0a1`
+Tag: `v0.1.0-alpha.1`
+
+This paired Meeting Lab revision supports the first functional end-to-end
+Meeting Assistant alpha: reusable transcription and optional diarization,
+explicit speaker mapping and regeneration, German and English protocol
+generation, glossary provenance without transcript mutation, configurable
+protocol thread profiles, generation history with atomic publication, and the
+GTM-Hub qualitative regression case.
+
+Validated candidate revisions:
+
+- Assistant: `b50b87c32b3941310c719f459fd45faa87658b68`
+- Meeting Lab: `d2e3636b949280402728308022c99bdee6ea1066`
+
+The immutable release revisions are the commits targeted by the paired
+`v0.1.0-alpha.1` tags in the two repositories.
+
+Accepted limitations are documented in the Assistant release notes, including
+the requirement for local runtime/model/container setup, human review of
+generated protocols, imperfect diarization, context limits, local POSIX
+publication assumptions, and the historical ignored fixtures needed by some
+old experiment tests.

docs/run-meeting.md

@@ -0,0 +1,142 @@
+# Running A Meeting Benchmark
+
+This page documents the repository-native runner for the current Meeting Lab
+production benchmark on the Linux AI-PC. It does not run Whisper. It starts
+from a converted, normalized Whisper JSON file.
+
+## Prerequisites
+
+- Git
+- Python 3.11 or newer
+- Ollama running locally
+- Required Ollama model installed
+- Meeting Lab dependencies installed in a virtual environment
+
+## Setup
+
+From the repository root on Linux:
+
+```bash
+python3 -m venv .venv
+source .venv/bin/activate
+python -m pip install --upgrade pip
+python -m pip install -e .
+```
+
+Install the reference model in Ollama if it is not already present:
+
+```bash
+ollama pull qwen3.5:9b
+```
+
+Confirm Ollama sees the model:
+
+```bash
+ollama list
+ollama ps
+```
+
+`ollama ps` must show no loaded model before a reference benchmark run. By
+default, the runner fails pre-flight if Ollama reports a loaded model. Use
+`--allow-loaded-models` only for a deliberately non-clean run; the default
+reference command does not use that override.
+
+## Progeo Reference Command
+
+Run from the repository root:
+
+```bash
+python scripts/run_meeting.py \
+  --input samples/real_live/progeo_meeting/progeo_whispercpp_vulkan_turbo_trimmed_converted.json \
+  --context samples/real_live/progeo_meeting/meeting_context.yaml \
+  --model qwen3.5:9b \
+  --benchmark-label progeo_ai_pc
+```
+
+## Windows / PowerShell Example
+
+For local Windows development, activate the virtual environment through
+PowerShell and run the same benchmark:
+
+```powershell
+python -m venv .venv
+.\.venv\Scripts\Activate.ps1
+python -m pip install --upgrade pip
+python -m pip install -e .
+ollama pull qwen3.5:9b
+python scripts\run_meeting.py `
+  --input samples\real_live\progeo_meeting\progeo_whispercpp_vulkan_turbo_trimmed_converted.json `
+  --context samples\real_live\progeo_meeting\meeting_context.yaml `
+  --model qwen3.5:9b `
+  --benchmark-label progeo_ai_pc
+```
+
+## Production Defaults
+
+The Progeo reference benchmark defaults match the latest controlled experiment
+selection:
+
+- Chunking: `target_chars=4500`, `max_chars=5500`, `min_chars=2500`,
+  `overlap_blocks=0`
+- LLM: `qwen3.5:9b`, `think=false`, `temperature=0`, `num_ctx=32768`
+- Extraction: context-aware chunk extraction with current committed prompts
+- Consolidation: Canonicalizer V1, Semantic Consolidator V0 adaptive sizing,
+  strict source-coverage validation and deterministic source-coverage repair
+- Rendering: Working Protocol Renderer V2
+- No semantic retries and no manual intervention
+
+Use `--help` to see explicit overrides.
+
+## Output
+
+The runner creates a unique directory:
+
+```text
+samples/benchmarks/<benchmark-label>_<timestamp>/
+```
+
+It never overwrites an existing run. Artifacts include:
+
+- `chunks/`
+- `normalized_chunks/`
+- `extractions/`, including parsed extraction JSON and raw successful model
+  responses
+- `canonicalizer/canonicalized_extractions.json`
+- `semantic_consolidator/`, including raw response, repaired groups,
+  validator reports, repair metadata and consolidated output
+- `working_protocol/`, including raw renderer response and validation report
+- `working_protocol.md` only when the renderer contract is valid
+- `run_metadata.json`
+- `benchmark_report.md`
+
+If a stage fails, artifacts produced up to the failure are preserved and the
+report records the failure.
+
+## Comparing Benchmarks
+
+For AI-PC comparison, compare the new `progeo_ai_pc_<timestamp>` directory
+against:
+
+```text
+samples/benchmarks/progeo_qwen35_9b_20260805_133942/
+```
+
+Key fields are in `run_metadata.json` and summarized in `benchmark_report.md`:
+
+- branch and commit
+- operating system, CPU, RAM, Python version and Ollama version
+- model tag, observed Ollama active models and whether
+  `--allow-loaded-models` was used
+- chunk count and chunk-size distribution
+- runtime per stage and total wall-clock runtime
+- average extraction time per chunk
+- validator violations and deterministic repair count
+- renderer contract result
+
+## Known Limitation
+
+The current Working Protocol Renderer V2 often produces contract-invalid output
+that does not start with `# Working Protocol`. The runner preserves the raw
+renderer response and validation report, and writes `working_protocol.md` only
+when the contract validator passes. This is the known BUG-011 renderer
+limitation, not a runner failure by itself.

prompts/classification.md

@@ -0,0 +1,55 @@
+Classification contract for Decisions, Action Items, and Open Questions:
+
+Classify each supported proposition into the one best category. Do not move an
+unsupported candidate into another category merely to retain it. Prefer
+omission over a false Decision or Action Item.
+
+Decision:
+
+A Decision requires evidence that the meeting settled, selected, approved,
+rejected, or committed to an outcome. Explicit agreement, selection,
+approval/rejection, commitment, or a clear statement that a decision was made
+is sufficient. A proposal, suggestion, preference, possibility, option,
+recommendation, consideration, or unresolved plan is not sufficient without
+explicit acceptance or commitment. A personal commitment to perform work is an
+Action Item, not a Decision, unless the meeting also establishes a distinct
+group-level outcome.
+
+Action Item:
+
+An Action Item is a concrete future action that the meeting establishes as work
+to be done. Explicit assignment, explicit acceptance, a personal commitment,
+or clear evidence that the work is already established and underway is
+sufficient. A suggestion, hypothetical action, possible next step,
+recommendation, brainstorming option, or exploratory statement is not
+sufficient. Do not create an Action Item merely because a statement contains an
+imperative-like verb.
+
+First decide whether the action itself exists. Only then attribute
+responsibility. An Action Item may exist without a named responsible person. A
+person may be named only when explicitly assigned, volunteering, or explicitly
+accepting/confirming the task. Mention, proximity, expertise, role, a request,
+or language that someone should/could/might act does not establish
+responsibility. Do not preserve an unsupported action merely by setting
+responsible to null.
+
+Open Question:
+
+An Open Question requires a concrete unresolved information, decision, or
+clarification need that remains open after the available context. An explicit
+question left unanswered or an explicit statement that clarification remains
+needed is sufficient. Uncertainty, doubt, ignorance, difficulty, an
+observation, an incomplete fragment, or a rhetorical question alone is not
+sufficient. A question answered in the available context is not open. Do not
+invent question wording or convert a rejected Decision/Action candidate into an
+Open Question without independent evidence of an unresolved need.
+
+Evidence discipline:
+
+- Every emitted item must include the shortest transcript evidence that proves
+  the category threshold.
+- Evidence for an Action Item must prove both the concrete work and that it was
+  established, not merely possible.
+- Evidence for an Open Question must prove both the specific need and that it
+  remains unresolved.
+- Use an empty list when a category has no supported item.

prompts/common.md

@@ -0,0 +1,33 @@
+Du extrahierst Informationen aus Meeting-Transkripten.
+
+Arbeite ausschließlich mit dem vorgelegten Transkript.
+Verwende kein eigenes Fachwissen, keine Vermutungen und keine üblichen
+Funktionsweisen technischer Systeme.
+
+Regeln:
+1. Erfinde nichts.
+2. Interpretiere technische Aussagen nicht über den Wortlaut hinaus.
+3. Korrigiere keine Aussagen anhand vermeintlichen Weltwissens.
+4. Wenn etwas widersprüchlich oder unklar ist, kennzeichne es als unklar.
+5. Übernimm wichtige technische Aussagen möglichst nah am Wortlaut.
+6. Nenne bei Fakten nach Möglichkeit den Sprecher.
+7. Ein Beschluss ist nur dann ein Beschluss, wenn das Meeting etwas erkennbar
+   geeinigt, ausgewählt, freigegeben, abgelehnt oder verbindlich festgelegt hat.
+8. Eine Aufgabe ist nur dann eine Aufgabe, wenn das Meeting eine konkrete
+   zukünftige Handlung als zu erledigende Arbeit festgelegt hat. Vorschläge,
+   Möglichkeiten und hypothetische nächste Schritte genügen nicht.
+9. Prüfe erst, ob die Aufgabe selbst belegt ist. Ordne danach nur bei expliziter
+   Zuweisung oder Annahme eine verantwortliche Person zu. Eine belegte Aufgabe
+   darf auch keine bekannte verantwortliche Person haben.
+10. Eine offene Frage erfordert einen konkreten, weiterhin offenen Informations-,
+    Entscheidungs- oder Klärungsbedarf. Bloße Unsicherheit genügt nicht; eine im
+    verfügbaren Kontext beantwortete Frage bleibt nicht offen.
+11. Gib ausschließlich gültiges JSON aus. Kein Markdown, keine Erläuterungen.
+
+Hinweise zur Ausgabe:
+- Alle obersten Schlüssel müssen vorhanden sein.
+- Verwende leere Listen, wenn keine Einträge vorhanden sind.
+- Verwende null, wenn Verantwortliche, Sprecher oder Termine nicht erkennbar sind.
+- "evidence" muss sich eng am Transkript orientieren.
+- Ersetze technische Aussagen niemals durch eine vermeintlich korrektere Erklärung.
+- Confidence-Werte sind ausdrücklich nicht erwünscht.

prompts/consolidate_facts.md

@@ -0,0 +1,52 @@
+You consolidate fact items from Meeting Lab.
+
+Return only valid JSON.
+
+Semantic equivalence is stricter than topical similarity.
+
+Merge fact items only when they express the same core factual proposition.
+Related facts are not enough. Facts from the same topic are not enough.
+
+Preserve distinctions in:
+
+- actor
+- scope
+- timing
+- condition
+- certainty
+- responsibility
+- current state versus future intention
+
+Do not merge:
+
+- broader and narrower statements
+- cause and effect
+- process and responsibility
+- fact and interpretation
+- related statements from the same topic
+- statements that differ in actor, scope, timing, condition, or certainty
+
+Use only the provided fact items.
+Do not invent information.
+Do not rewrite evidence.
+Do not add source item IDs that were not provided.
+Every provided fact item ID must appear exactly once.
+When uncertain, keep items separate.
+False negatives are preferable to false-positive merges.
+
+Return JSON with this exact top-level shape:
+
+{
+  "groups": [
+    {
+      "canonical_text": "One factual statement preserving the shared meaning",
+      "source_item_ids": ["fact_0001"],
+      "merge_reason": "Why these items are equivalent, or why this singleton remains separate"
+    }
+  ]
+}
+
+For singleton groups, use the original fact text as canonical_text.
+For merged groups, canonical_text must contain only information shared by all
+source facts in the group.
+

prompts/decisions.md

@@ -0,0 +1,105 @@
+You extract decisions from meeting transcript text.
+
+Return only valid JSON.
+
+Schema:
+
+{
+  "decisions": [
+    {
+      "decision": "Concise decision text",
+      "evidence": "Short quote from the transcript"
+    }
+  ]
+}
+
+Definition:
+
+A decision exists only when the participants explicitly agreed, approved,
+confirmed, adopted, assigned, or otherwise made something binding during the
+meeting.
+
+Extract a decision only if the transcript contains clear decision language or
+clear agreement language, such as:
+
+- "we agree"
+- "agreed"
+- "approved"
+- "confirmed"
+- "we will do it this way"
+- "this is decided"
+- "we assign this to ..."
+- "let's do that" when accepted by the group
+- an explicit agreement to postpone, defer, or intentionally suspend a
+  substantive decision until additional information is available; this is a
+  valid process decision
+
+Do not classify the following as decisions:
+
+- proposals
+- suggestions
+- wishes
+- ideas
+- assumptions
+- explanations
+- descriptions of existing processes
+- statements about normal procedures
+- discussion
+- open questions
+- planned future discussion
+- someone saying what could be done
+- someone saying what usually happens
+- someone describing a document, workflow, or process
+- someone saying that something stays unchanged, as-is, or for now, unless the
+  group explicitly agrees to keep it that way as a binding choice
+
+If a statement is only a proposal or suggestion, do not extract it.
+
+If participants discuss something but do not explicitly agree to it, do not
+extract it.
+
+A personal commitment to perform concrete future work is normally an action
+item, not a decision. Do not extract it as a decision unless the group also
+establishes a binding outcome, rule, approval, rejection, deferral, selection,
+process state, or responsibility policy beyond the personal work assignment
+itself.
+
+Do not duplicate the same proposition under decisions and todos.
+
+A single transcript passage may nevertheless contain both:
+
+- a group-level decision, rule, approval, rejection, deferral or process state
+- and a distinct resulting action item
+
+Extract both when they are semantically separate propositions, even if they
+occur in the same sentence or evidence passage.
+
+A concrete personal work commitment without a separate group-level outcome
+belongs only under todos.
+
+If the transcript describes an existing process, rule, template, document, or
+workflow, do not extract it unless the participants explicitly adopt or change it
+in this meeting.
+
+If no explicit decision exists, return:
+
+{
+  "decisions": []
+}
+
+Prefer an empty list over a false positive.
+
+For each decision:
+
+- Write one concise decision text.
+- Extract each decision as one atomic commitment.
+- Do not combine separate agreements, unchanged conditions, background
+  information, explanations, or follow-up remarks into one decision.
+- If two distinct matters were agreed, return two separate decisions.
+- Include one short evidence quote from the transcript.
+- Include only the shortest evidence passage that directly proves the decision.
+- Do not invent responsible persons.
+- Do not invent deadlines.
+- Do not invent priorities.
+- Do not add confidence values.
+- Do not explain your reasoning.

prompts/todos.md

@@ -0,0 +1,16 @@
+Action-item responsibility rule:
+
+A named responsible person may be extracted only when the transcript contains
+clear evidence that the person was explicitly assigned the task, explicitly
+volunteered, or explicitly accepted/confirmed the task.
+
+The following are not assignments: addressing a person while discussing a
+topic; saying that a person or department will have different criteria;
+requesting input from a department; stating expertise, competence, or
+organizational role; suggestions, expectations, objections, or preferences;
+Meeting Context role or department metadata by itself.
+
+When work is clearly needed but no person accepted it, keep the action item
+without a responsible person if the schema allows it; otherwise do not create a
+named assignment. Meeting Context may validate identity, role, and attendance,
+but never establishes responsibility.

prompts/working_protocol.md

@@ -0,0 +1,133 @@
+You are the Working Protocol renderer for Meeting Lab.
+
+Render the provided Canonical Meeting Knowledge, or the current consolidated
+meeting representation, as one professional internal working protocol in
+Markdown.
+
+Your task is presentation only.
+
+Use only information contained in the provided input. Do not use outside
+knowledge. Do not infer missing facts. Do not merge semantically different
+items. Do not resolve conflicts. Do not add conclusions that are not present in
+the input.
+
+Output language:
+
+- Use the dominant language of the consolidated meeting knowledge.
+- Do not translate.
+- Change language only if an explicit output language is requested.
+
+Renderer responsibilities:
+
+- Organize information for human readers.
+- Remove presentation-level redundancy.
+- Preserve all decisions.
+- Preserve all action items.
+- Preserve all open questions.
+- Preserve evidence-relevant context when needed to understand a decision,
+  action item or open question.
+
+The renderer is not responsible for:
+
+- semantic consolidation
+- deduplication of meaning
+- fact extraction
+- conflict resolution
+- inventing topics that are not supported by the supplied structure
+- protocol-independent knowledge synthesis
+
+Target document:
+
+Write a professional internal working protocol for meeting participants who
+need to reconstruct what was discussed, what was decided, what remains open and
+who has to do what.
+
+This is not a management summary, a narrative meeting report, verbatim minutes
+or marketing text.
+
+Writing style:
+
+- precise
+- factual
+- neutral
+- concise
+- technically accurate
+
+Avoid narrative framing and generic report phrases, including:
+
+- "The discussion focused on..."
+- "It was noted that..."
+- "Participants discussed..."
+- "The meeting emphasized..."
+
+Do not restate decisions inside background paragraphs.
+Do not explain action items multiple times.
+Do not repeat the same information merely because it appears in multiple
+categories.
+
+Priorities:
+
+1. Decisions
+2. Action Items
+3. Open Questions
+4. Required background
+
+Condense everything else.
+
+Structure:
+
+Start immediately with:
+
+# Working Protocol
+
+Then organize by topic. For each topic, use only the sections that contain
+information:
+
+## Topic title
+
+### Background
+
+Use at most one or two short paragraphs. Include only context required to
+understand the decisions, action items or open questions.
+
+### Decisions
+
+Preserve every decision. Do not weaken or strengthen the decision. Do not
+attribute it to a person unless the input explicitly provides that attribution.
+
+### Action Items
+
+Preserve every action item. Include responsible person and deadline only when
+explicitly present. If either is missing, do not invent it.
+
+Never infer or strengthen responsibility. Only render an action item with a
+named responsible person if the consolidated input explicitly contains that
+assignment. If the input contains uncertainty, preserve it. If an item has no
+explicit responsible person, render it without one or mark it as
+"Verantwortung offen". Do not convert opinions into assignments, suggestions
+into commitments, objections into ownership, or departmental discussion into
+role attribution.
+
+### Open Questions
+
+Preserve every open question. Do not convert open questions into decisions or
+action items.
+
+Do not create empty sections.
+
+Faithfulness rules:
+
+- Never invent facts.
+- Never strengthen uncertainty.
+- Never weaken decisions.
+- Never attribute statements to people unless explicitly present.
+- Keep distinctions between background, decisions, action items and open
+  questions.
+- If information appears contradictory in the input, preserve the uncertainty
+  without resolving it.
+- If two items are similar but not already consolidated, keep their meanings
+  distinct in the rendered document.
+
+Return Markdown only.
+Do not include an introductory explanation.
+Do not include a concluding summary.

pyproject.toml

@@ -0,0 +1,8 @@
+[project]
+name = "meeting-lab"
+version = "0.1.0a1"
+requires-python = ">=3.11"
+dependencies = [
+  "PyYAML>=6.0",
+  "requests>=2.31",
+]

samples/benchmarks/canonicalizer_v1/report.md

@@ -0,0 +1,168 @@
+# Canonicalizer V1 Evaluation Run
+
+## Scope
+
+This run evaluates Canonicalizer V1 as deterministic input preparation for a
+future semantic consolidator. It does not evaluate protocol prose and does not
+run the semantic consolidator.
+
+Input files:
+
+- `samples/whisper/meeting_speech_cleaned_chunks/chunk_01_extraction.json`
+- `samples/whisper/meeting_speech_cleaned_chunks/chunk_02_extraction.json`
+- `samples/whisper/meeting_speech_cleaned_chunks/chunk_03_extraction.json`
+- `samples/whisper/meeting_speech_cleaned_chunks/chunk_04_extraction.json`
+- `samples/whisper/meeting_speech_cleaned_chunks/chunk_05_extraction.json`
+- `samples/whisper/meeting_speech_cleaned_chunks/chunk_06_extraction.json`
+- `samples/whisper/meeting_speech_cleaned_chunks/chunk_07_extraction.json`
+- `samples/whisper/meeting_speech_cleaned_chunks/chunk_08_extraction.json`
+- `samples/whisper/meeting_speech_cleaned_chunks/chunk_09_extraction.json`
+
+Output:
+
+- `samples/benchmarks/canonicalizer_v1/canonicalized_extractions.json`
+
+## Run Metrics
+
+- Runtime: 0.04 seconds
+- Input file count: 9
+- Input byte size: 22,695 bytes
+- Output byte size: 115,924 bytes
+- Exact duplicate count: 0
+- Merged exact duplicate count: 0
+- Malformed or unparsed items: 0
+- Source-reference mismatches found during comparison: 0
+
+Input item count by category:
+
+- fact: 33
+- decision: 14
+- action_item: 16
+- open_question: 10
+- position: 0
+- technical_detail: 14
+
+Output item count by category:
+
+- fact: 33
+- decision: 14
+- action_item: 16
+- open_question: 10
+- position: 0
+- technical_detail: 14
+
+## Representative Inspection
+
+### Fact
+
+- Item: `fact_0001`
+- Source: `chunk_01_extraction.json`, index 0
+- Text: `Das ist das aktuelle Projektdeckblatt, was wir in der F&E benutzen.`
+- Speaker: `Martin`
+- Status: `clear`
+- Evidence preserved from the original extraction item.
+
+Assessment: original information and evidence were preserved, and the source
+reference points back to the correct original item.
+
+### Decision
+
+- Item: `decision_0001`
+- Source: `chunk_02_extraction.json`, index 0
+- Text: `Der bestehende Prozess wird grundsätzlich auch für Business Development (BD)-Projekte genutzt, wobei die spezifischen Dokumente je nach Projekttyp angepasst werden.`
+- Evidence preserved from the original extraction item.
+
+Assessment: decision text and evidence were preserved without semantic
+rewriting.
+
+### Action Item
+
+- Item: `action_item_0001`
+- Source: `chunk_01_extraction.json`, index 0
+- Text: `Giovanna stellt die Kriterien zusammen und erstellt einen ersten Entwurf für den Auswahlkatalog, der EDD-, Marketing- und PM-Kriterien integriert.`
+- Responsible: `Giovanna`
+- Deadline: `null`
+- Evidence preserved from the original extraction item.
+
+Assessment: responsibility was parsed from the legacy string and no deadline
+was invented.
+
+### Open Question
+
+- Item: `open_question_0001`
+- Source: `chunk_01_extraction.json`, index 0
+- Text: `Wie werden spezifische Auswahlkriterien für digitale Produkte (z.B. Portal) versus Realprodukte definiert und integriert?`
+- Evidence preserved from the original extraction item.
+
+Assessment: question text and evidence were preserved.
+
+### Position
+
+The input extraction files contain zero `positions` items. The canonicalized
+output correctly reports zero `position` items.
+
+### Technical Detail
+
+- Item: `technical_detail_0001`
+- Source: `chunk_01_extraction.json`, index 0
+- Subject: `Projektdeckblatt Struktur`
+- Text: `Das ist eine kurze Projektidee, Ziel, Gegenüber, Entwicklungshemmnisse (Patente), Budgetabfrage.`
+- Status: `clear`
+- Evidence preserved from the original extraction item.
+
+Assessment: subject, statement, status and evidence were parsed without adding
+technical interpretation.
+
+## Comparison Findings
+
+- Original information is preserved. All output items retain `original_value`.
+- Source references are correct. A comparison against the nine original JSON
+  files found zero source-reference mismatches.
+- No semantic merges occurred. Output item counts match input item counts in
+  every category.
+- Names and responsibilities were not invented. Missing optional values remain
+  `null`; for example, `action_item_0001` has `deadline: null`.
+- Similar but non-identical items remain separate. For example, `fact_0025`
+  and `fact_0031` both discuss the F&E lead maintaining the project list, but
+  they have different wording and remain separate items.
+- The output is suitable as deterministic input for a later LLM consolidator:
+  it has stable IDs, normalized categories, source references, evidence and
+  original values.
+
+## Conclusion
+
+1. Is the deterministic representation lossless enough?
+
+Yes for the current extraction format. The canonicalized output preserves the
+original value, parsed text fields, evidence and source references for each
+item. The output is larger than the input because it adds deterministic
+metadata and source-reference structure.
+
+2. Are exact duplicates handled correctly?
+
+Yes for this run. No exact duplicates were present, so no items were merged.
+The input and output category counts are identical.
+
+3. Are legacy extraction strings parsed reliably?
+
+Yes for the inspected current files. Legacy pipe-delimited strings were parsed
+into category-specific fields such as `speaker`, `status`, `responsible`,
+`deadline` and `subject` where safely available. No malformed or unparsed items
+were detected.
+
+4. Does the result reduce avoidable work for the semantic consolidator?
+
+Yes. The future consolidator can consume normalized categories, stable item
+IDs, source references, evidence and parsed optional fields instead of
+re-reading heterogeneous legacy strings directly.
+
+5. What unresolved transformations must remain an LLM task?
+
+- Merging semantically equivalent but differently worded statements.
+- Grouping items into coherent topics.
+- Reconciling facts, decisions, action items and questions across chunks.
+- Detecting contradictions and uncertainty.
+- Separating durable organizational knowledge from transient discussion.
+- Deciding whether similar items such as `fact_0025` and `fact_0031` should be
+  merged, related or kept separate.
+

samples/benchmarks/hardware_experimental_qwen35_9b/hardware_benchmark_report.md

@@ -0,0 +1,106 @@
+# Hardware Benchmark Report
+
+## System
+
+- OS: Microsoft Windows 11 Pro 10.0.26200, 64-bit
+- CPU: AMD Ryzen 5 9600X 6-Core Processor, 6 cores / 12 logical processors
+- RAM: 33,988,124,672 bytes installed (~31.7 GiB)
+- GPU: AMD Radeon RX 9070
+- GPU memory: `ollama ps` reported 6.7 GB model resident on GPU; Windows CIM AdapterRAM reported 4,293,918,720 bytes, likely driver-limited reporting
+- Ollama version: 0.32.5
+- Model: `qwen3.5:9B` / `qwen3.5:9b`, 9.7B, Q4_K_M, digest `6488c96fa5faab64bb65cbd30d4289e20e6130ef535a93ef9a49f42eda893ea7`
+- Commit: `63075eaca91088beb92e646b6b0a2539cfe049ca`
+- Branch: `feature/windowed-segmentation`
+- Upstream: `origin/feature/windowed-segmentation`
+
+## Runtime comparison
+
+| Stage | MacBook Air M4 | Experimental computer | Speedup |
+|---|---:|---:|---:|
+| Semantic Consolidator V0 | 390.119 s | 38.451 s | 10.15x |
+| Working Protocol Renderer V2 | 722.900 s | 37.675 s | 19.19x |
+| Total | 1113.019 s | 76.126 s | 14.62x |
+
+## Semantic Consolidator V0
+
+- Runtime state: cold start; `ollama ps` was empty before the measured run
+- Wall-clock runtime: 38.451 s
+- Ollama total_duration: 38.4172797 s
+- load_duration: 4.0657233 s
+- prompt_eval_count: 4295
+- prompt_eval_duration: 1.629666 s
+- eval_count: 2399
+- eval_duration: 32.712261 s
+- Fact count: 33
+- Merged fact groups: 1
+- Singleton groups: 31
+- Validation: passed
+- Source fact coverage: every source fact occurred exactly once
+- Missing IDs: none
+- Duplicate source IDs: none
+- Non-fact categories unchanged: yes
+- Accepted duplicate: `fact_0025` + `fact_0031`, F&E project list / biweekly interface stand-up
+- GPU acceleration: active; `ollama ps` showed `PROCESSOR 100% GPU`, context 32768, model size 6.7 GB while inference was active
+- Monitoring: see `semantic_consolidator_v0/monitoring_log.txt`
+
+## Working Protocol Renderer V2 - official Python benchmark
+
+- Result: valid benchmark run
+- Execution method: synchronous foreground Python using `requests.post`; no PowerShell background job, no `Invoke-WebRequest`, no PowerShell response redirection
+- Runtime state: cold start; `ollama ps` was empty before the measured run
+- Wall-clock runtime: 37.675 s
+- MacBook Air M4 baseline: 722.900 s
+- Speedup: 19.19x
+- total_duration: 37.6437146 s
+- load_duration: 4.0374398 s
+- prompt_eval_count: 28349
+- prompt_eval_duration: 14.694067 s
+- eval_count: 1268
+- eval_duration: 18.840999 s
+- Prompt characters: 112964
+- Output characters: 5567
+- Output bytes: 5626
+- Detected output language: German
+- Readable Markdown: true
+- HTTP status: 200
+- Content-Type: `application/json; charset=utf-8`
+- Raw response byte length: 148913
+- Top-level JSON keys: `context, created_at, done, done_reason, eval_count, eval_duration, load_duration, model, prompt_eval_count, prompt_eval_duration, response, total_duration`
+- done: true
+- done_reason: stop
+- Request count: 1, recorded in `working_protocol_renderer_v2_python/request_count_marker.txt`
+- GPU acceleration: active; `ollama ps` showed `PROCESSOR 100% GPU`, context 32768, model size 6.7 GB after the request
+- Output path: `working_protocol_renderer_v2_python/working_protocol.md`
+- Raw response path: `working_protocol_renderer_v2_python/raw_ollama_response.json`
+- Run report: `working_protocol_renderer_v2_python/report.md`
+
+## Working Protocol Renderer V2 - original invalid attempt
+
+- Result: invalid benchmark run; no valid `working_protocol.md` was produced
+- Runtime state at attempted start: warm; model was still loaded from Run 1
+- Reason: the PowerShell background job started outside the repository working directory and failed to resolve `prompts/working_protocol.md` and the consolidated input path
+- Comparability: not valid; no speedup claimed
+- Monitoring: see `working_protocol_renderer_v2/monitoring_log.txt`
+
+## Working Protocol Renderer V2 - PowerShell retry invalid attempt
+
+- Result: invalid benchmark run; no valid `working_protocol.md` was produced
+- Runtime state at attempted start: cold; `ollama ps` was empty before the request
+- Request count marker: exactly one request start and one request end were recorded locally in `working_protocol_renderer_v2_retry/request_count_marker.txt`
+- Failure: the wrapper wrote `$resp.Content`, but `$resp.Content` was null/empty in the background job. `Set-Content -Encoding utf8` therefore created a 3-byte UTF-8 BOM file, and the following `$data.response` access produced the null-reference error.
+- GPU acceleration during attempt: active; `ollama ps` showed `PROCESSOR 100% GPU`, context 32768, model size 6.7 GB while inference was active
+- Comparability: not valid; no speedup claimed
+- Monitoring: see `working_protocol_renderer_v2_retry/monitoring_log.txt`
+
+## Renderer Diagnosis
+
+- No committed renderer CLI or module exists in this checkout for Working Protocol Renderer V2.
+- The Mac benchmark artifact identifies a temporary prompt file at `/private/tmp/meeting_lab_working_protocol_synthesis_prompt.txt`, input adapter required, one LLM call, model `qwen3.5:9B`, and `think=false`.
+- The successful Python benchmark used the same practical request shape as the successful Mac artifact: `/api/generate`, `stream=false`, `think=false`, no JSON format constraint, `temperature=0.0`, `num_ctx=32768`, `num_predict=4096`, prompt file plus consolidated JSON input.
+- Response parsing reads the top-level Ollama `response` string and writes it directly as `working_protocol.md`. The complete raw HTTP response JSON is preserved before parsing.
+
+## Comparability limitations
+
+- Semantic Consolidator V0 used the requested input, model, quantization, endpoint, prompt, and `think=false` setting.
+- Working Protocol Renderer V2 used the requested prompt, hardware Semantic Consolidator V0 output, model, quantization, endpoint, and `think=false` setting.
+- The renderer prompt character count differs from the Mac artifact because this run used the newly generated hardware Semantic Consolidator V0 output, as requested.

samples/benchmarks/hardware_experimental_qwen35_9b/semantic_consolidator_v0/benchmark_stdout.txt

@@ -0,0 +1,28 @@
+Fact item count:                 33
+Estimated prompt size chars:     15393
+Estimated prompt tokens:         3849
+Expected LLM call count:         1
+Expected runtime:                5-10 minutes on current local benchmark basis
+Ollama request start:            2026-08-01T08:42:34
+Ollama endpoint:                 http://127.0.0.1:11434/api/generate
+Ollama model:                    qwen3.5:9B
+Ollama stream:                   False
+Ollama think:                    False
+Ollama timeout seconds:          1800
+Ollama options:                  {"num_ctx": 32768, "num_predict": 4096, "temperature": 0.0}
+Waiting for Ollama response:     30.0 seconds elapsed
+Ollama response metadata:
+  total_duration: 38417279700
+  load_duration: 4065723300
+  prompt_eval_count: 4295
+  prompt_eval_duration: 1629666000
+  eval_count: 2399
+  eval_duration: 32712261000
+Runtime seconds:                 38.451
+Merged fact groups:              1
+Source facts involved in merges: 2
+Singleton fact groups:           31
+Validation result:               passed
+Output:                          samples\benchmarks\hardware_experimental_qwen35_9b\semantic_consolidator_v0\consolidated_extractions.json
+Report:                          samples\benchmarks\hardware_experimental_qwen35_9b\semantic_consolidator_v0\report.md
+Raw model response:              samples\benchmarks\hardware_experimental_qwen35_9b\semantic_consolidator_v0\raw_model_response.txt

samples/benchmarks/hardware_experimental_qwen35_9b/semantic_consolidator_v0/monitoring_log.txt

@@ -0,0 +1,32 @@
+SAMPLE 0 2026-08-01T08:42:34.7197665+02:00 FreeMemKB=16797340 OllamaCPU=13.84375 OllamaWS=49446912
+NAME    ID    SIZE    PROCESSOR    CONTEXT    UNTIL
+
+SAMPLE 1 2026-08-01T08:42:39.9119216+02:00 FreeMemKB=15942168 OllamaCPU=14.234375 OllamaWS=69578752
+NAME          ID              SIZE      PROCESSOR    CONTEXT    UNTIL              
+qwen3.5:9b    6488c96fa5fa    6.7 GB    100% GPU     32768      4 minutes from now
+
+SAMPLE 2 2026-08-01T08:42:45.0374639+02:00 FreeMemKB=15835780 OllamaCPU=14.25 OllamaWS=69705728
+NAME          ID              SIZE      PROCESSOR    CONTEXT    UNTIL              
+qwen3.5:9b    6488c96fa5fa    6.7 GB    100% GPU     32768      4 minutes from now
+
+SAMPLE 3 2026-08-01T08:42:50.1735639+02:00 FreeMemKB=17120500 OllamaCPU=14.296875 OllamaWS=66314240
+NAME          ID              SIZE      PROCESSOR    CONTEXT    UNTIL              
+qwen3.5:9b    6488c96fa5fa    6.7 GB    100% GPU     32768      4 minutes from now
+
+SAMPLE 4 2026-08-01T08:42:55.3234153+02:00 FreeMemKB=18431496 OllamaCPU=14.328125 OllamaWS=66527232
+NAME          ID              SIZE      PROCESSOR    CONTEXT    UNTIL              
+qwen3.5:9b    6488c96fa5fa    6.7 GB    100% GPU     32768      4 minutes from now
+
+SAMPLE 5 2026-08-01T08:43:00.4718461+02:00 FreeMemKB=18403816 OllamaCPU=14.40625 OllamaWS=66707456
+NAME          ID              SIZE      PROCESSOR    CONTEXT    UNTIL              
+qwen3.5:9b    6488c96fa5fa    6.7 GB    100% GPU     32768      4 minutes from now
+
+SAMPLE 6 2026-08-01T08:43:05.6096000+02:00 FreeMemKB=18421668 OllamaCPU=14.421875 OllamaWS=66990080
+NAME          ID              SIZE      PROCESSOR    CONTEXT    UNTIL              
+qwen3.5:9b    6488c96fa5fa    6.7 GB    100% GPU     32768      4 minutes from now
+
+SAMPLE 7 2026-08-01T08:43:10.7368162+02:00 FreeMemKB=18445280 OllamaCPU=14.4375 OllamaWS=67121152
+NAME          ID              SIZE      PROCESSOR    CONTEXT    UNTIL              
+qwen3.5:9b    6488c96fa5fa    6.7 GB    100% GPU     32768      4 minutes from now
+
+PROCESS_EXIT 2026-08-01T08:43:15.8756249+02:00 ExitCode= ActiveConfirmed=True

samples/benchmarks/hardware_experimental_qwen35_9b/semantic_consolidator_v0/raw_model_response.txt

@@ -0,0 +1,164 @@
+{
+  "groups": [
+    {
+      "canonical_text": "Das ist das aktuelle Projektdeckblatt, was wir in der F&E benutzen.",
+      "source_item_ids": ["fact_0001"],
+      "merge_reason": "Singleton: No other items express the specific identity and usage of this document."
+    },
+    {
+      "canonical_text": "Das Ding ist kein Filtersystem.",
+      "source_item_ids": ["fact_0002"],
+      "merge_reason": "Singleton: Specific negation regarding system type, not equivalent to general process descriptions or other project attributes."
+    },
+    {
+      "canonical_text": "Die Kriterien sind nicht relevant für ein Realprodukt.",
+      "source_item_ids": ["fact_0003"],
+      "merge_reason": "Singleton: Specific statement about criterion relevance for real products, distinct from general process steps or other criteria lists."
+    },
+    {
+      "canonical_text": "Der Prozess ist im Wesentlichen abgestimmt auf Entwicklungsideen und geht um Projekte, die entweder physische oder nicht-physischer Natur sind.",
+      "source_item_ids": ["fact_0004"],
+      "merge_reason": "Singleton: Describes the scope and nature of projects in a specific process context. Distinct from general flow descriptions or responsibility assignments."
+    },
+    {
+      "canonical_text": "Der grundsätzliche Ablauf bleibt gleich, aber andere Fragestellungen und Dokumente werden verwendet.",
+      "source_item_ids": ["fact_0005"],
+      "merge_reason": "Singleton: Describes a variation in process flow and documents. Distinct from specific document identities or general scope definitions."
+    },
+    {
+      "canonical_text": "Die Projektleitung ist überhaupt nicht abteilungszugeordnet.",
+      "source_item_ids": ["fact_0006"],
+      "merge_reason": "Singleton: Specific organizational attribute of the project leadership. Distinct from general responsibility assignments or process steps."
+    },
+    {
+      "canonical_text": "Die Variante mit PowerPoint-Folien und Stichpunkten hat sich im letzten Jahr als wirklich sehr gut funktionierend und im Arbeitsalltag wertvoll erwiesen.",
+      "source_item_ids": ["fact_0007"],
+      "merge_reason": "Singleton: Specific evaluation of a presentation format's utility. Distinct from process steps or general criteria."
+    },
+    {
+      "canonical_text": "Bevor ein Projekt entsteht, müssen im Vorfeld andere Kriterien abgehandelt werden.",
+      "source_item_ids": ["fact_0008"],
+      "merge_reason": "Singleton: Describes a prerequisite step before project initiation. Distinct from the specific criteria themselves or general process flow."
+    },
+    {
+      "canonical_text": "Solange die Sachen nicht geklärt sind, brauchen wir noch gar nicht loslegen.",
+      "source_item_ids": ["fact_0009"],
+      "merge_reason": "Singleton: Describes a condition for starting work. Distinct from the specific criteria or general process steps."
+    },
+    {
+      "canonical_text": "Die Aufgabe im Vorfeld alles zu machen liegt im kaufmännischen Bereich.",
+      "source_item_ids": ["fact_0010"],
+      "merge_reason": "Singleton: Assigns a specific responsibility (pre-project work) to the commercial area. Distinct from general process steps or other responsibilities."
+    },
+    {
+      "canonical_text": "Der Prozess ist ein F&E-Prozess gewesen, einfach historisch.",
+      "source_item_ids": ["fact_0011"],
+      "merge_reason": "Singleton: Historical classification of the process. Distinct from current definitions or specific steps."
+    },
+    {
+      "canonical_text": "Eine neue Idee muss mindestens folgende Punkte beantworten: Titel, Projektidee und ein Projektziel.",
+      "source_item_ids": ["fact_0012"],
+      "merge_reason": "Singleton: Defines mandatory content for a new idea. Distinct from optional criteria or other validation steps."
+    },
+    {
+      "canonical_text": "Optional ist eine konkrete Aufzählung der zugrunde liegenden Annahmen, zum Beispiel erwartbares Marktvolumen.",
+      "source_item_ids": ["fact_0013"],
+      "merge_reason": "Singleton: Defines optional content for a new idea. Distinct from mandatory requirements or other validation steps."
+    },
+    {
+      "canonical_text": "Ideen müssen geprüft werden, ob sie auf Team- oder Abteilungsebene abzuarbeiten sind.",
+      "source_item_ids": ["fact_0014"],
+      "merge_reason": "Singleton: Describes a specific scope validation step. Distinct from other criteria or responsibility assignments."
+    },
+    {
+      "canonical_text": "Ideen müssen abgefragt werden, ob sie abteilungsübergreifend, strategisch relevant sind oder ein Budget notwendig ist.",
+      "source_item_ids": ["fact_0015"],
+      "merge_reason": "Singleton: Describes a specific relevance/budget validation step. Distinct from other criteria or responsibility assignments."
+    },
+    {
+      "canonical_text": "Die Netzwerkverbindung bei Gemeinden ist sehr langsam.",
+      "source_item_ids": ["fact_0016"],
+      "merge_reason": "Singleton: Specific technical status statement regarding network speed at a specific location. Distinct from process or organizational facts."
+    },
+    {
+      "canonical_text": "Sekretariate sind da sehr abweisend, weil sie sagen, dass sie keine Ahnung davon haben und viel anderes zu tun.",
+      "source_item_ids": ["fact_0017"],
+      "merge_reason": "Singleton: Describes the attitude and reasoning of secretariats. Distinct from process steps or technical facts."
+    },
+    {
+      "canonical_text": "Filter müssen definiert werden und dienen als grobe Filter, nicht bis ins Kleinste.",
+      "source_item_ids": ["fact_0018"],
+      "merge_reason": "Singleton: Describes the nature and necessity of defining filters. Distinct from specific filter criteria or process steps."
+    },
+    {
+      "canonical_text": "Das Schlimmste ist, dass einer kommt und sagt, er wirft nur ein Stichwort rein.",
+      "source_item_ids": ["fact_0019"],
+      "merge_reason": "Singleton: Describes a negative behavior pattern in the process. Distinct from positive criteria or structural facts."
+    },
+    {
+      "canonical_text": "Man sollte nicht im Vorhinein versuchen, alles zu planen.",
+      "source_item_ids": ["fact_0020"],
+      "merge_reason": "Singleton: Expresses an intention/strategy against early planning. Distinct from factual process steps or criteria."
+    },
+    {
+      "canonical_text": "Die Durchsetzung und Umsetzung ist das Entscheidende am Schluss.",
+      "source_item_ids": ["fact_0021"],
+      "merge_reason": "Singleton: Highlights the importance of implementation at the end. Distinct from planning steps or criteria."
+    },
+    {
+      "canonical_text": "Wir machen keine Teppiche für Autos.",
+      "source_item_ids": ["fact_0022"],
+      "merge_reason": "Singleton: Specific business scope limitation/negation. Distinct from general process descriptions."
+    },
+    {
+      "canonical_text": "Die Geschäftsführung hat den Überblick über Projekte im Haus zu behalten.",
+      "source_item_ids": ["fact_0023"],
+      "merge_reason": "Singleton: Assigns a specific responsibility (overview) to the Management Board. Distinct from other responsibilities or process steps."
+    },
+    {
+      "canonical_text": "Der F&E-Topf wird gemeinsam geführt.",
+      "source_item_ids": ["fact_0024"],
+      "merge_reason": "Singleton: Describes a specific organizational arrangement for funding/resources. Distinct from general responsibility assignments."
+    },
+    {
+      "canonical_text": "Der Leiter F&E führt die Projektliste auf dem zweiwöchentlichen Schnittstellen-Stand-Up.",
+      "source_item_ids": ["fact_0025", "fact_0031"],
+      "merge_reason": "Semantic equivalence: Both items state that the Head of R&D leads the project list at the bi-weekly interface stand-up meeting. The difference in wording ('auf den' vs 'auf dem') and minor context does not change the core factual proposition."
+    },
+    {
+      "canonical_text": "Zu diesem Zeitpunkt sind Projekte bereits nach gewissen Kriterien kategorisiert; Vorfilter haben entlaufen.",
+      "source_item_ids": ["fact_0026"],
+      "merge_reason": "Singleton: Describes a state of categorization and filtering. Distinct from the definition of filters or specific criteria."
+    },
+    {
+      "canonical_text": "Die Bearbeitung der Projekte muss und kann nur in den Fachabteilungen passieren.",
+      "source_item_ids": ["fact_0027"],
+      "merge_reason": "Singleton: Defines a strict constraint on where project processing occurs. Distinct from general responsibility assignments or process steps."
+    },
+    {
+      "canonical_text": "Ich kann nicht darüber entscheiden, ob ein Marketingprojekt erfolgreich gelaufen ist.",
+      "source_item_ids": ["fact_0028"],
+      "merge_reason": "Singleton: Expresses a lack of competence/authority regarding marketing project success. Distinct from general responsibility assignments or process steps."
+    },
+    {
+      "canonical_text": "Bestimmte Dinge müssen bereits jetzt im Prozess definiert werden.",
+      "source_item_ids": ["fact_0029"],
+      "merge_reason": "Singleton: Expresses a requirement for early definition. Distinct from specific criteria or process steps."
+    },
+    {
+      "canonical_text": "Jede Abteilung hat diese Kriterien ja im Grunde sowieso.",
+      "source_item_ids": ["fact_0030"],
+      "merge_reason": "Singleton: States a general assumption about departmental possession of criteria. Distinct from the specific content or application of those criteria."
+    },
+    {
+      "canonical_text": "Der erste Filter dient als Entscheidungsvorlage und nicht als endgültige Entscheidung.",
+      "source_item_ids": ["fact_0032"],
+      "merge_reason": "Singleton: Defines the specific nature/function of the first filter. Distinct from other filters or general filtering concepts."
+    },
+    {
+      "canonical_text": "Es gibt zwei Orte zum Filtern: einmal vorher (Vorfilter) und dann das Gremium.",
+      "source_item_ids": ["fact_0033"],
+      "merge_reason": "Singleton: Describes the structure of filtering locations. Distinct from specific criteria or filter definitions."
+    }
+  ]
+}

samples/benchmarks/hardware_experimental_qwen35_9b/semantic_consolidator_v0/report.md

@@ -0,0 +1,20 @@
+# Semantic Consolidator V0 Report
+
+- Scope: facts only
+- Model: `qwen3.5:9B`
+- LLM call count: 1
+- Runtime: 38.451 seconds
+- Fact item count: 33
+- Prompt characters: 15393
+- Estimated prompt tokens: 3849
+- Merged fact groups: 1
+- Source facts involved in merges: 2
+- Singleton fact groups: 31
+- Output path: `samples\benchmarks\hardware_experimental_qwen35_9b\semantic_consolidator_v0\consolidated_extractions.json`
+
+## Actual Merges
+
+### Der Leiter F&E führt die Projektliste auf dem zweiwöchentlichen Schnittstellen-Stand-Up.
+
+- Source fact IDs: fact_0025, fact_0031
+- Merge reason: Semantic equivalence: Both items state that the Head of R&D leads the project list at the bi-weekly interface stand-up meeting. The difference in wording ('auf den' vs 'auf dem') and minor context does not change the core factual proposition.

samples/benchmarks/hardware_experimental_qwen35_9b/working_protocol_renderer_v2/monitoring_log.txt

@@ -0,0 +1,5 @@
+SAMPLE 0 2026-08-01T08:44:56.1505788+02:00 FreeMemKB=18388280 OllamaCPU=14.4375 OllamaWS=67276800
+NAME          ID              SIZE      PROCESSOR    CONTEXT    UNTIL              
+qwen3.5:9b    6488c96fa5fa    6.7 GB    100% GPU     32768      3 minutes from now
+
+JOB_EXIT 2026-08-01T08:45:01.4585914+02:00 State=Running ActiveConfirmed=True

samples/benchmarks/hardware_experimental_qwen35_9b/working_protocol_renderer_v2/report.md

@@ -0,0 +1,13 @@
+# Working Protocol Renderer V2 Report
+
+- Result: invalid benchmark run
+- Valid Working Protocol output: no
+- Runtime: not measured
+- Model state at attempted start: warm (`qwen3.5:9b` was loaded from Run 1)
+- Intended model: `qwen3.5:9B`
+- Intended thinking setting: disabled (`think=false`)
+- Intended endpoint: `http://127.0.0.1:11434/api/generate`
+- Intended prompt: `prompts/working_protocol.md` unchanged
+- Intended input: `samples/benchmarks/hardware_experimental_qwen35_9b/semantic_consolidator_v0/consolidated_extractions.json`
+- Failure: PowerShell background job used the wrong working directory and could not resolve repository-relative paths.
+- Retry policy: no second renderer request was started because exactly-one-request compliance could not be proven after the failed wrapper attempt.

samples/benchmarks/hardware_experimental_qwen35_9b/working_protocol_renderer_v2_python/report.md

@@ -0,0 +1,43 @@
+# Working Protocol Renderer V2 Python Report
+
+- Result: valid benchmark run
+- Model: `qwen3.5:9B`
+- Thinking setting: disabled (`think=false`)
+- Endpoint: `http://127.0.0.1:11434/api/generate`
+- Prompt path: `C:\Users\marti\Documents\git-projects\meeting-lab\prompts\working_protocol.md`
+- Input path: `C:\Users\marti\Documents\git-projects\meeting-lab\samples\benchmarks\hardware_experimental_qwen35_9b\semantic_consolidator_v0\consolidated_extractions.json`
+- Cold/warm state: cold
+- Request count: 1
+- Wall-clock runtime: 37.675 seconds
+- MacBook Air M4 baseline: 722.900 seconds
+- Speedup: 19.19x
+- total_duration: 37643714600
+- load_duration: 4037439800
+- prompt_eval_count: 28349
+- prompt_eval_duration: 14694067000
+- eval_count: 1268
+- eval_duration: 18840999000
+- Prompt characters: 112964
+- Output characters: 5567
+- Output bytes: 5626
+- Detected output language: German
+- Readable Markdown: True
+- Output path: `C:\Users\marti\Documents\git-projects\meeting-lab\samples\benchmarks\hardware_experimental_qwen35_9b\working_protocol_renderer_v2_python\working_protocol.md`
+- Raw response path: `C:\Users\marti\Documents\git-projects\meeting-lab\samples\benchmarks\hardware_experimental_qwen35_9b\working_protocol_renderer_v2_python\raw_ollama_response.json`
+
+## Response Diagnostics
+
+- HTTP status code: 200
+- Content-Type: `application/json; charset=utf-8`
+- Response byte length: 148913
+- Top-level JSON keys: `context, created_at, done, done_reason, eval_count, eval_duration, load_duration, model, prompt_eval_count, prompt_eval_duration, response, total_duration`
+- Response text length: 5567
+- done: True
+- done_reason: stop
+
+## GPU Snapshot
+
+```text
+NAME          ID              SIZE      PROCESSOR    CONTEXT    UNTIL              
+qwen3.5:9b    6488c96fa5fa    6.7 GB    100% GPU     32768      4 minutes from now
+```

samples/benchmarks/hardware_experimental_qwen35_9b/working_protocol_renderer_v2_python/request_count_marker.txt

@@ -0,0 +1,2 @@
+REQUEST_START 2026-08-01T09:09:01+0200 endpoint=http://127.0.0.1:11434/api/generate
+REQUEST_END 2026-08-01T09:09:38+0200 status=200

samples/benchmarks/hardware_experimental_qwen35_9b/working_protocol_renderer_v2_python/run_renderer_benchmark.py

@@ -0,0 +1,274 @@
+#!/usr/bin/env python3
+"""Run the Meeting Lab Working Protocol Renderer V2 hardware benchmark once."""
+
+from __future__ import annotations
+
+import json
+import subprocess
+import sys
+import time
+from pathlib import Path
+from typing import Any
+
+import requests
+
+
+REPO = Path(r"C:\Users\marti\Documents\git-projects\meeting-lab")
+PROMPT_PATH = REPO / "prompts" / "working_protocol.md"
+INPUT_PATH = (
+    REPO
+    / "samples"
+    / "benchmarks"
+    / "hardware_experimental_qwen35_9b"
+    / "semantic_consolidator_v0"
+    / "consolidated_extractions.json"
+)
+OUTPUT_DIR = (
+    REPO
+    / "samples"
+    / "benchmarks"
+    / "hardware_experimental_qwen35_9b"
+    / "working_protocol_renderer_v2_python"
+)
+RAW_RESPONSE_PATH = OUTPUT_DIR / "raw_ollama_response.json"
+PROTOCOL_PATH = OUTPUT_DIR / "working_protocol.md"
+REPORT_PATH = OUTPUT_DIR / "report.md"
+REQUEST_MARKER_PATH = OUTPUT_DIR / "request_count_marker.txt"
+
+MODEL = "qwen3.5:9B"
+ENDPOINT = "http://127.0.0.1:11434/api/generate"
+NUM_CTX = 32768
+NUM_PREDICT = 4096
+TEMPERATURE = 0.0
+TIMEOUT_SECONDS = 1800
+MAC_RENDERER_BASELINE_SECONDS = 722.9
+
+
+def run_ollama_ps() -> str:
+    result = subprocess.run(
+        ["ollama", "ps"],
+        check=False,
+        capture_output=True,
+        text=True,
+        encoding="utf-8",
+        errors="replace",
+    )
+    return result.stdout.strip()
+
+
+def detect_language(text: str) -> str:
+    lower = text.lower()
+    german_markers = [
+        " der ",
+        " die ",
+        " das ",
+        " und ",
+        " nicht ",
+        " verantwortlich",
+        " entscheidung",
+        " offene",
+        " fragen",
+        " maßnahmen",
+        " fuer ",
+        " für ",
+    ]
+    english_markers = [
+        " the ",
+        " and ",
+        " not ",
+        " responsible",
+        " decision",
+        " open questions",
+        " action items",
+    ]
+    german_score = sum(lower.count(marker) for marker in german_markers)
+    english_score = sum(lower.count(marker) for marker in english_markers)
+    if german_score > english_score:
+        return "German"
+    if english_score > german_score:
+        return "English"
+    return "unknown"
+
+
+def response_text_from_ollama_data(data: dict[str, Any]) -> str | None:
+    text = data.get("response")
+    if isinstance(text, str):
+        return text
+    message = data.get("message")
+    if isinstance(message, dict):
+        content = message.get("content")
+        if isinstance(content, str):
+            return content
+    return None
+
+
+def is_readable_markdown(text: str) -> bool:
+    stripped = text.strip()
+    return bool(stripped) and stripped.startswith("#") and "\n" in stripped
+
+
+def write_report(lines: list[str]) -> None:
+    REPORT_PATH.write_text("\n".join(lines).rstrip() + "\n", encoding="utf-8")
+
+
+def main() -> int:
+    OUTPUT_DIR.mkdir(parents=True, exist_ok=True)
+    if not PROMPT_PATH.exists():
+        print(f"Missing prompt: {PROMPT_PATH}", file=sys.stderr)
+        return 1
+    if not INPUT_PATH.exists():
+        print(f"Missing input: {INPUT_PATH}", file=sys.stderr)
+        return 1
+
+    cold_warm = "warm" if MODEL.lower() in run_ollama_ps().lower() else "cold"
+    prompt = PROMPT_PATH.read_text(encoding="utf-8")
+    input_text = INPUT_PATH.read_text(encoding="utf-8-sig")
+    full_prompt = (
+        prompt
+        + "\n\nCONSOLIDATED MEETING REPRESENTATION:\n"
+        + input_text
+    )
+    payload = {
+        "model": MODEL,
+        "prompt": full_prompt,
+        "think": False,
+        "stream": False,
+        "options": {
+            "temperature": TEMPERATURE,
+            "num_ctx": NUM_CTX,
+            "num_predict": NUM_PREDICT,
+        },
+    }
+
+    REQUEST_MARKER_PATH.write_text(
+        f"REQUEST_START {time.strftime('%Y-%m-%dT%H:%M:%S%z')} endpoint={ENDPOINT}\n",
+        encoding="utf-8",
+    )
+    started = time.perf_counter()
+    response = requests.post(ENDPOINT, json=payload, timeout=TIMEOUT_SECONDS)
+    runtime = time.perf_counter() - started
+    REQUEST_MARKER_PATH.write_text(
+        REQUEST_MARKER_PATH.read_text(encoding="utf-8")
+        + f"REQUEST_END {time.strftime('%Y-%m-%dT%H:%M:%S%z')} status={response.status_code}\n",
+        encoding="utf-8",
+    )
+
+    RAW_RESPONSE_PATH.write_bytes(response.content)
+
+    print(f"HTTP status code: {response.status_code}")
+    print(f"response Content-Type: {response.headers.get('Content-Type', '')}")
+    print(f"response byte length: {len(response.content)}")
+
+    try:
+        data = response.json()
+    except ValueError as exc:
+        print(f"Invalid JSON response: {exc}", file=sys.stderr)
+        write_report(
+            [
+                "# Working Protocol Renderer V2 Python Report",
+                "",
+                "- Result: invalid benchmark run",
+                f"- HTTP status code: {response.status_code}",
+                f"- Response byte length: {len(response.content)}",
+                f"- Error: invalid JSON response: {exc}",
+                "- Request count: 1",
+            ]
+        )
+        return 1
+
+    if not isinstance(data, dict):
+        print("Top-level JSON is not an object.", file=sys.stderr)
+        return 1
+
+    keys = sorted(data.keys())
+    text = response_text_from_ollama_data(data)
+    text_length = len(text) if isinstance(text, str) else 0
+    print(f"top-level JSON keys: {keys}")
+    print(f"response text length: {text_length}")
+    print(f"done flag: {data.get('done')}")
+    print(f"done_reason: {data.get('done_reason')}")
+
+    if response.status_code != 200 or not response.content or not isinstance(text, str):
+        write_report(
+            [
+                "# Working Protocol Renderer V2 Python Report",
+                "",
+                "- Result: invalid benchmark run",
+                f"- HTTP status code: {response.status_code}",
+                f"- Response byte length: {len(response.content)}",
+                f"- Top-level JSON keys: {', '.join(keys)}",
+                f"- Response text length: {text_length}",
+                f"- done: {data.get('done')}",
+                f"- done_reason: {data.get('done_reason')}",
+                "- Request count: 1",
+            ]
+        )
+        return 1
+
+    PROTOCOL_PATH.write_text(text, encoding="utf-8")
+
+    language = detect_language(text)
+    markdown_ok = is_readable_markdown(text)
+    speedup = MAC_RENDERER_BASELINE_SECONDS / runtime if runtime > 0 else 0.0
+    output_bytes = len(text.encode("utf-8"))
+    validation_ok = bool(text.strip()) and markdown_ok and language == "German"
+
+    total_duration = data.get("total_duration")
+    load_duration = data.get("load_duration")
+    prompt_eval_count = data.get("prompt_eval_count")
+    prompt_eval_duration = data.get("prompt_eval_duration")
+    eval_count = data.get("eval_count")
+    eval_duration = data.get("eval_duration")
+    gpu_snapshot = run_ollama_ps()
+
+    write_report(
+        [
+            "# Working Protocol Renderer V2 Python Report",
+            "",
+            "- Result: valid benchmark run" if validation_ok else "- Result: invalid benchmark run",
+            f"- Model: `{MODEL}`",
+            "- Thinking setting: disabled (`think=false`)",
+            f"- Endpoint: `{ENDPOINT}`",
+            f"- Prompt path: `{PROMPT_PATH}`",
+            f"- Input path: `{INPUT_PATH}`",
+            f"- Cold/warm state: {cold_warm}",
+            "- Request count: 1",
+            f"- Wall-clock runtime: {runtime:.3f} seconds",
+            f"- MacBook Air M4 baseline: {MAC_RENDERER_BASELINE_SECONDS:.3f} seconds",
+            f"- Speedup: {speedup:.2f}x",
+            f"- total_duration: {total_duration}",
+            f"- load_duration: {load_duration}",
+            f"- prompt_eval_count: {prompt_eval_count}",
+            f"- prompt_eval_duration: {prompt_eval_duration}",
+            f"- eval_count: {eval_count}",
+            f"- eval_duration: {eval_duration}",
+            f"- Prompt characters: {len(full_prompt)}",
+            f"- Output characters: {len(text)}",
+            f"- Output bytes: {output_bytes}",
+            f"- Detected output language: {language}",
+            f"- Readable Markdown: {markdown_ok}",
+            f"- Output path: `{PROTOCOL_PATH}`",
+            f"- Raw response path: `{RAW_RESPONSE_PATH}`",
+            "",
+            "## Response Diagnostics",
+            "",
+            f"- HTTP status code: {response.status_code}",
+            f"- Content-Type: `{response.headers.get('Content-Type', '')}`",
+            f"- Response byte length: {len(response.content)}",
+            f"- Top-level JSON keys: `{', '.join(keys)}`",
+            f"- Response text length: {text_length}",
+            f"- done: {data.get('done')}",
+            f"- done_reason: {data.get('done_reason')}",
+            "",
+            "## GPU Snapshot",
+            "",
+            "```text",
+            gpu_snapshot,
+            "```",
+        ]
+    )
+    return 0 if validation_ok else 1
+
+
+if __name__ == "__main__":
+    raise SystemExit(main())

samples/benchmarks/hardware_experimental_qwen35_9b/working_protocol_renderer_v2_python/working_protocol.md

@@ -0,0 +1,97 @@
+# Working Protocol
+
+## Prozessstruktur und Projekttypen
+
+### Background
+
+Der bestehende F&E-Prozess wird grundsätzlich auch für Business Development (BD)-Projekte genutzt. Der grundsätzliche Ablauf bleibt gleich, wobei spezifische Dokumente je nach Projekttyp angepasst werden. Die Bearbeitung der Projekte muss und kann nur in den Fachabteilungen passieren; die Projektleitung ist dabei nicht abteilungszugeordnet.
+
+### Decisions
+
+- Der bestehende Prozess wird grundsätzlich auch für Business Development (BD)-Projekte genutzt, wobei die spezifischen Dokumente je nach Projekttyp angepasst werden.
+- Die Prozessschritte für verschiedene Projekttypen (F&E, PM, Marketing, BD) werden im Swimlane-Diagramm offen gelassen und nicht formal festgelegt.
+- Es wird vereinbart, dass für BD-Projekte ein Projektdeckblatt und Lastenheft erstellt werden müssen.
+- Der erste Filter dient als Entscheidungsvorlage und nicht als endgültige Entscheidung.
+
+### Action Items
+
+- Giovanna stellt die Kriterien zusammen und erstellt einen ersten Entwurf für den Auswahlkatalog, der EDD-, Marketing- und PM-Kriterien integriert. (Verantwortlich: Giovanna)
+- Björn definiert andere Kriterien für Business Development Projekte (z.B. digitale Affinität, kulturelle Hürden) und integriert diese in den Filter. (Verantwortlich: Björn)
+
+### Open Questions
+
+- Wie werden spezifische Auswahlkriterien für digitale Produkte (z.B. Portal) versus Realprodukte definiert und integriert?
+- Wie genau sollen die Anforderungen an das Lastenheft für nicht-F&E-Projekte definiert werden?
+- Sollte die Vorab-Filterung durch eine zentrale Stelle oder dezentral in den Abteilungen erfolgen?
+- Wer übernimmt die Prozessverantwortlichkeit für die erste Prüfung von Projektideen?
+
+## Minimalanforderungen und Filterkriterien
+
+### Background
+
+Neue Ideen müssen mindestens Titel, Projektidee und ein Projektziel beantworten. Optional ist eine konkrete Aufzählung der zugrunde liegenden Annahmen (z.B. erwartbares Marktvolumen). Vorab-Filter dienen als Entscheidungsvorlage; weitere Kriterien werden je nach Fall definiert. Strategiekonformität ist ein Filterkriterium.
+
+### Decisions
+
+- Festlegung der Mindestanforderungen für neue Projektideen (Titel, Idee, Ziel) und optionaler Annahmen.
+- Etablierung eines Prüfprozesses zur Unterscheidung zwischen abteilungsinternen Aufgaben und strategisch relevanten Ideen.
+- Zustimmung zur Einbindung von Business Development für die Vorsortierung und das Abfragen der Minimaldaten.
+
+### Action Items
+
+- Ideen müssen mit Minimalanforderungen angereichert werden, bevor sie bearbeitet werden können. (Verantwortung offen)
+- Bei BD-Projekten müssen typische drei bis vier typische BD-Sachen abgefragt werden. (Verantwortung offen)
+- Definition von Filterkriterien für verschiedene Fälle (neue Produkte/Anwendungen vs. bestehende Märkte). (Verantwortung offen)
+
+### Open Questions
+
+- Welche Prüfsteine sind relevant für die Fachabteilung?
+
+## Projektlaufbahn und Gremiumsarbeit
+
+### Background
+
+Der Prozess beginnt mit der Entscheidung, ob ein Projekt in die Strategie passt. Wenn ja, wird entschieden, in welche Abteilung (BD, PM, Marketing) es tropft. Zu diesem Zeitpunkt sind Projekte bereits nach gewissen Kriterien kategorisiert; Vorfilter haben entlaufen. Ab dem Termin, wo das Projekt vorgestellt wird, muss jemand den Hut aufsetzen und prüfen oder einen Projektplan erstellen.
+
+### Decisions
+
+- Die Bearbeitung der Projekte muss und kann nur in den Fachabteilungen passieren.
+- Der Prozess soll nicht zu komplex gemacht werden; es wird ein Gefühl für notwendige Informationen entwickelt.
+- Der Miro-Link wird in den Chat kopiert und allen relevanten Personen (insb. Henning) zur Verfügung gestellt.
+
+### Action Items
+
+- Björn soll mit PM oder Business Development über die Diskussion von Projekten (z.B. Papatikus-Anker) sprechen und diese zu den Fachabteilungen rüberspielen.
+- Fachabteilungen sollen den Katalog ausarbeiten und zur Entscheidung bringen.
+- Eine Liste führen, die zeigt, wer sich um was kümmert.
+- Prozess etablieren, in dem Filter sicher abgefragt werden.
+- Gatekeeper (z.B. James und David) sollen formal ein paar Sachen abarbeiten und Informationen zusammentragen.
+- Raik muss Ideen in den Pool tragen lassen (nicht nur Stichworte reinwerfen).
+- Nachdem eine Idee im Prozess ist (z.B. nach 4 Wochen), Status prüfen: Wird es bearbeitet?
+- Miro-Link in den Chat kopieren und an alle verteilen. (Verantwortlich: Malte)
+
+### Open Questions
+
+- Für welche Projekte soll das übergeordnete Projektmanagement gewünscht werden?
+- Wer stellt welches Projekt in welchem Gremium vor?
+
+## Organisationale Rahmenbedingungen und Ressourcen
+
+### Background
+
+Die Geschäftsführung hat den Überblick über Projekte im Haus zu behalten. Der F&E-Topf wird gemeinsam geführt. Das Netzwerk bei Gemeinden ist sehr langsam, Sekretariate sind da sehr abweisend. Die Durchsetzung und Umsetzung ist das Entscheidende am Schluss. Man sollte nicht im Vorhinein versuchen, alles zu planen.
+
+### Decisions
+
+- Es wurde vereinbart, Filterkriterien für verschiedene Fälle (neue Produkte/Anwendungen vs. bestehende Märkte) zu definieren.
+- Die Gruppe stimmt der gemeinsamen Meinung und dem vorgeschlagenen Vorgehen zur Prozessanpassung zu.
+
+### Action Items
+
+- Ein paar Prüfsteine definieren. (Verantwortung offen)
+- Giovanna und Björn in die Diskussion über Filterkriterien einbeziehen. (Verantwortung offen)
+
+### Open Questions
+
+- Sind wir so davon überzeugt, dass wir die Marktstudie anschieben?
+- An welcher Stelle entscheidet eine Abteilung einfach so und an welcher Stelle nicht?

samples/benchmarks/hardware_experimental_qwen35_9b/working_protocol_renderer_v2_retry/monitoring_log.txt

@@ -0,0 +1,32 @@
+SAMPLE 0 2026-08-01T08:51:07.5108682+02:00 FreeMemKB=19747780 OllamaCPU=14.6875 OllamaWS=43548672
+NAME    ID    SIZE    PROCESSOR    CONTEXT    UNTIL
+
+SAMPLE 1 2026-08-01T08:51:12.6834762+02:00 FreeMemKB=18754304 OllamaCPU=15.1875 OllamaWS=61841408
+NAME          ID              SIZE      PROCESSOR    CONTEXT    UNTIL              
+qwen3.5:9b    6488c96fa5fa    6.7 GB    100% GPU     32768      4 minutes from now
+
+SAMPLE 2 2026-08-01T08:51:17.8264165+02:00 FreeMemKB=18733028 OllamaCPU=15.1875 OllamaWS=61841408
+NAME          ID              SIZE      PROCESSOR    CONTEXT    UNTIL              
+qwen3.5:9b    6488c96fa5fa    6.7 GB    100% GPU     32768      4 minutes from now
+
+SAMPLE 3 2026-08-01T08:51:22.9486785+02:00 FreeMemKB=18508580 OllamaCPU=15.1875 OllamaWS=61841408
+NAME          ID              SIZE      PROCESSOR    CONTEXT    UNTIL              
+qwen3.5:9b    6488c96fa5fa    6.7 GB    100% GPU     32768      4 minutes from now
+
+SAMPLE 4 2026-08-01T08:51:28.0758752+02:00 FreeMemKB=18453568 OllamaCPU=15.21875 OllamaWS=46608384
+NAME          ID              SIZE      PROCESSOR    CONTEXT    UNTIL              
+qwen3.5:9b    6488c96fa5fa    6.7 GB    100% GPU     32768      4 minutes from now
+
+SAMPLE 5 2026-08-01T08:51:33.2017774+02:00 FreeMemKB=18453764 OllamaCPU=15.265625 OllamaWS=46620672
+NAME          ID              SIZE      PROCESSOR    CONTEXT    UNTIL              
+qwen3.5:9b    6488c96fa5fa    6.7 GB    100% GPU     32768      4 minutes from now
+
+SAMPLE 6 2026-08-01T08:51:38.3370762+02:00 FreeMemKB=18457940 OllamaCPU=15.28125 OllamaWS=46653440
+NAME          ID              SIZE      PROCESSOR    CONTEXT    UNTIL              
+qwen3.5:9b    6488c96fa5fa    6.7 GB    100% GPU     32768      4 minutes from now
+
+SAMPLE 7 2026-08-01T08:51:43.4802353+02:00 FreeMemKB=18472864 OllamaCPU=15.3125 OllamaWS=46653440
+NAME          ID              SIZE      PROCESSOR    CONTEXT    UNTIL              
+qwen3.5:9b    6488c96fa5fa    6.7 GB    100% GPU     32768      4 minutes from now
+
+JOB_EXIT 2026-08-01T08:51:48.6321784+02:00 State=Running ActiveConfirmed=True

samples/benchmarks/hardware_experimental_qwen35_9b/working_protocol_renderer_v2_retry/raw_ollama_response.json

@@ -0,0 +1 @@
+

samples/benchmarks/hardware_experimental_qwen35_9b/working_protocol_renderer_v2_retry/report.md

@@ -0,0 +1,20 @@
+# Working Protocol Renderer V2 Retry Report
+
+- Result: invalid benchmark run
+- Valid Working Protocol output: no
+- Runtime: not valid for benchmark comparison
+- Preflight repository root: `C:\Users\marti\Documents\git-projects\meeting-lab`
+- Required prompt existed: yes
+- Required consolidated input existed: yes
+- Renderer request currently running before start: no visible request in `ollama ps`
+- Model state before start: cold; `ollama ps` was empty
+- Intended model: `qwen3.5:9B`
+- Intended thinking setting: disabled (`think=false`)
+- Intended endpoint: `http://127.0.0.1:11434/api/generate`
+- Intended prompt: `prompts/working_protocol.md` unchanged
+- Intended input: `samples/benchmarks/hardware_experimental_qwen35_9b/semantic_consolidator_v0/consolidated_extractions.json`
+- Request marker: one request start and one request end recorded in `request_count_marker.txt`
+- Failure: captured raw response file contains only a UTF-8 BOM; no usable Ollama JSON body was available for renderer output or metrics extraction
+- GPU confirmation: `ollama ps` showed `qwen3.5:9b` with `PROCESSOR 100% GPU`, context 32768, model size 6.7 GB during the request
+- Validation: failed; `working_protocol.md` does not exist
+- Retry policy: no additional renderer request was started

samples/benchmarks/hardware_experimental_qwen35_9b/working_protocol_renderer_v2_retry/request_count_marker.txt

@@ -0,0 +1,2 @@
+REQUEST_START 2026-08-01T08:51:07.6738275+02:00 endpoint=http://127.0.0.1:11434/api/generate
+REQUEST_END 2026-08-01T08:51:48.6341848+02:00 status=

samples/benchmarks/meeting_context_v1/chunk_01_extraction_with_context.json

@@ -0,0 +1,39 @@
+{
+  "facts": [
+    "Martin | Wir haben einmal die größeren Punkte zusammengeschrieben. Einmal ist das Thema was Sie wahrscheinlich brennend interessiert, das Thema der Lüftungsanlage Haus 2 bis 4. | clear | Einmal ist das Thema was Sie wahrscheinlich brennend interessiert, das Thema der Lüftungsanlage Haus 2 bis 4.",
+    "Die Firma Thies durch den Geschäftsführerwechsel. Der Geschäftsführer es mir interessiert die Probleme zu lösen. | clear | was sich ja positiv entwickelt hat war die Firma Thies durch den Geschäftsführerwechsel was wir seit Mai haben der Geschäftsführer es mir interessiert die Probleme zu lösen.",
+    "Der Gutachter hat sozusagen an uns wieder eine Liste an Unterlagen geschickt. Die haben wir über den Fachplaner beigestellt. | clear | der Gutachter hat sozusagen an uns wieder eine Liste an Unterlagen geschickt die wir haben möchten.",
+    "Die Abdichtungen am Dach wo sie zusätzlich nochmal aufgetragen worden sind sind alle aufgebracht worden. | clear | Hier haben wir die Rückmeldung bekommen. Die Abdichtungen am Dach wo sie zusätzlich nochmal aufgetragen worden sind sind alle aufgebracht worden.",
+    "Die Firma Hermann hat alle freigemeldet. | clear | Der hat alle gemacht. Also die Firma Hermann hat alle freigemeldet.",
+    "Herr Bentes wird das auch nicht weiter betreuen sondern der Herr Lott wird da sozusagen federführend in diese Sache einsteigen. | clear | der Herr Bentes wird das... Genau der Herr Bentes wird das auch nicht weiter betreuen sondern der Herr Lott wird da sozusagen federführend in diese Sache einsteigen.",
+    "Frau Grüßes ist zwei Tage im Urlaub. Ab Montag ist sie wieder für sie da. | clear | Die Frau Grüßes zum Beispiel können Sie direkt anrufen oder ansprechen. Und wenn sie jetzt gerade im Urlaub ist weil das Problem habe ich Herr Tietken dann weg. Sie ist zwei Tage im Urlaub.",
+    "Herr Radeke: Ich fühle mich veranlasst da kurz zu erwidern. | clear | Ich fühle mich veranlasst da kurz zu erwidern, Frau Arngold.",
+    "Herr Tietken scheidet aus. Wir haben einen externen Ersatz jetzt geschaffen der reagieren kann. | clear | Wir werden jetzt bis entsprechend ein Ersatz hundertprozentig da ist. Wir haben einen externen Ersatz jetzt geschaffen der reagieren kann.",
+    "Wenn Sie Herrn Bent das anrufen wenn das ein Notfall ist fein aber wenn Sie Herrn Bent das zu Sachen fragen die irgendwelche Mangelabarbeitung sind bitte wenden Sie sich dann lieber an uns. | clear | wenn Sie Herrn Bent das anrufen wenn das ein Notfall ist fein aber wenn Sie Herrn Bent das zu Sachen fragen die irgendwelche Mangelabarbeitung sind die nicht drängen. Bitte wenden Sie sich dann lieber an uns.",
+    "Wenn der Hausmeister keinen 24 Stunden Notdienst macht verstehe ich weil es kostet ja viel Geld müssen halt Eigentümer einen Schlüssel haben dass man in die Räume kommt und auch selbst absperren. | clear | Also ich würde da nicht so viel auch fremde Hilfe immer bauen sondern sagen okay, es sind Leute vor Ort. Wenn ich daheim bin kann ich alles vorbereitet.",
+    "Wir müssen jetzt schauen dass wir das Thema Wartungsverträge hinbringen weil dann haben Sie einen Heizungsnotdienst. | clear | Also wir müssen jetzt schauen dass wir das Thema Wartungsverträge hinbringen weil dann haben Sie einen Heizungsnotdienst dann haben Sie einen Elektronotdienst.",
+    "Die Lüftungsanlage ist seit dem 6. Mai ausgeschaltet. | clear | Ja. Die ist seit dem 6. Mai ausgeschaltet."
+  ],
+  "decisions": [],
+  "todos": [
+    "Herr Lott übernimmt die federführende Betreuung der Dachabdichtungsarbeiten. | Martin | der Herr Bentes wird das auch nicht weiter betreuen sondern der Herr Lott wird da sozusagen federführend in diese Sache einsteigen.",
+    "Herr Schmidt druckt Bestandspläne (Heizung, Lüftung, Sanitär) aus und hängt sie an Ort und Stelle auf. | Martin | Ich kümmere mich gerne darum das in entsprechender Papierform auszudrucken in Hefter zu tun und dann an Ort und Stelle zu verbringen.",
+    "BPD prüft die Möglichkeit eines Wartungsvertrags für Pumpen-Notdienst (z.B. Firma 'Pumpen Kahl'). | Gibt es Wartungsvertrag wie Sie sagen vom Pumpen Kahl rufe ich dann an 24 Stunden Notdienst und dann kommt er halt und pumpt mir den Keller aus.",
+    "BPD klärt mit der Feuerwehr die Kostenübernahme bei Wassereintritten in Tiefgaragen. | Also wir müssen es halt dann bezahlen wenn wir die Schuldigen sind."
+  ],
+  "questions": [
+    "Wann wird die Lüftungsanlage in den Häusern wieder vollständig in Betrieb genommen? | Die ist seit dem 6. Mai ausgeschaltet. Die Bäder fangen an zu schimmeln.",
+    "Wer hat die Lichtkuppel geöffnet, wodurch es zum zweiten Wassereintritt kam? | Einmal war die Lichtkuppel offen... Wer macht denn sowas auf?"
+  ],
+  "positions": [],
+  "technical": [
+    "Lüftungsgutachter | Die Firma Grossmann ist ein anerkannter öffentlich bestellter Lüftungsgutachter. | clear | Der Firma Grossmann ist ein anerkannter öffentlich bestellter Lüftungsgutachter.",
+    "Dachabdichtungsstand | Die Abdichtungen am Dach sind alle aufgebracht worden, es fehlen aber noch kleinere Arbeiten wo sozusagen nochmal so Metallteile noch hinkommen. | clear | Es fehlen aber noch kleinere Arbeiten wo sozusagen nochmal so Metallteile noch hinkommen.",
+    "Verantwortung für Mängelabarbeitung vs. Notfall | Für den Notfall rufen Sie die Nummer an die Sie finden. Bitte aber auch nur für den Notfall. | clear | Bitte aber auch nur für den Notfall."
+  ],
+  "context": {
+    "meeting_id": "2026-07-27-projektprozess",
+    "source_file": "samples\\real_live\\project_process_meeting\\meeting_context.yaml",
+    "schema_version": "1"
+  }
+}

samples/benchmarks/meeting_context_v1/comparison.md

@@ -0,0 +1,120 @@
+# Meeting Context V1 Responsibility Attribution Comparison
+
+## Source
+
+- Baseline source artifact: `samples/benchmarks/canonicalizer_v1/canonicalized_extractions.json`
+- Baseline source extraction file recorded there: `chunk_01_extraction.json`
+- Normalized chunk: `samples/chunks/chunk_01_normalized.txt`
+- Context-aware extraction: `samples/benchmarks/meeting_context_v1/chunk_01_extraction_with_context.json`
+
+## Old False Item
+
+```json
+{
+  "item_id": "action_item_0002",
+  "category": "action_item",
+  "text": "Björn definiert andere Kriterien für Business Development Projekte (z.B. digitale Affinität, kulturelle Hürden) und integriert diese in den Filter.",
+  "evidence": "aus Marketing-Sicht, Björn, wirst du andere Kriterien haben",
+  "source_file": "chunk_01_extraction.json",
+  "source_index": 1,
+  "original_value": "Björn definiert andere Kriterien für Business Development Projekte (z.B. digitale Affinität, kulturelle Hürden) und integriert diese in den Filter. | Björn | aus Marketing-Sicht, Björn, wirst du andere Kriterien haben",
+  "responsible": "Björn",
+  "deadline": null,
+  "source_references": [
+    {
+      "source_file": "chunk_01_extraction.json",
+      "source_index": 1,
+      "evidence": "aus Marketing-Sicht, Björn, wirst du andere Kriterien haben",
+      "original_value": "Björn definiert andere Kriterien für Business Development Projekte (z.B. digitale Affinität, kulturelle Hürden) und integriert diese in den Filter. | Björn | aus Marketing-Sicht, Björn, wirst du andere Kriterien haben"
+    }
+  ],
+  "duplicate_count": 1
+}
+```
+
+## Category Counts
+
+| Category | Old | New |
+| --- | ---: | ---: |
+| facts | 2 | 13 |
+| decisions | 0 | 0 |
+| todos | 2 | 4 |
+| questions | 1 | 2 |
+| positions | 0 | 0 |
+| technical | 2 | 3 |
+
+## Old Todo / Action Items
+
+```json
+[
+  {
+    "item_id": "action_item_0001",
+    "category": "action_item",
+    "text": "Giovanna stellt die Kriterien zusammen und erstellt einen ersten Entwurf für den Auswahlkatalog, der EDD-, Marketing- und PM-Kriterien integriert.",
+    "evidence": "Also Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt",
+    "source_file": "chunk_01_extraction.json",
+    "source_index": 0,
+    "original_value": "Giovanna stellt die Kriterien zusammen und erstellt einen ersten Entwurf für den Auswahlkatalog, der EDD-, Marketing- und PM-Kriterien integriert. | Giovanna | Also Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt",
+    "responsible": "Giovanna",
+    "deadline": null,
+    "source_references": [
+      {
+        "source_file": "chunk_01_extraction.json",
+        "source_index": 0,
+        "evidence": "Also Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt",
+        "original_value": "Giovanna stellt die Kriterien zusammen und erstellt einen ersten Entwurf für den Auswahlkatalog, der EDD-, Marketing- und PM-Kriterien integriert. | Giovanna | Also Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt"
+      }
+    ],
+    "duplicate_count": 1
+  },
+  {
+    "item_id": "action_item_0002",
+    "category": "action_item",
+    "text": "Björn definiert andere Kriterien für Business Development Projekte (z.B. digitale Affinität, kulturelle Hürden) und integriert diese in den Filter.",
+    "evidence": "aus Marketing-Sicht, Björn, wirst du andere Kriterien haben",
+    "source_file": "chunk_01_extraction.json",
+    "source_index": 1,
+    "original_value": "Björn definiert andere Kriterien für Business Development Projekte (z.B. digitale Affinität, kulturelle Hürden) und integriert diese in den Filter. | Björn | aus Marketing-Sicht, Björn, wirst du andere Kriterien haben",
+    "responsible": "Björn",
+    "deadline": null,
+    "source_references": [
+      {
+        "source_file": "chunk_01_extraction.json",
+        "source_index": 1,
+        "evidence": "aus Marketing-Sicht, Björn, wirst du andere Kriterien haben",
+        "original_value": "Björn definiert andere Kriterien für Business Development Projekte (z.B. digitale Affinität, kulturelle Hürden) und integriert diese in den Filter. | Björn | aus Marketing-Sicht, Björn, wirst du andere Kriterien haben"
+      }
+    ],
+    "duplicate_count": 1
+  }
+]
+```
+
+## New Todo / Action Items
+
+```json
+[
+  "Herr Lott übernimmt die federführende Betreuung der Dachabdichtungsarbeiten. | Martin | der Herr Bentes wird das auch nicht weiter betreuen sondern der Herr Lott wird da sozusagen federführend in diese Sache einsteigen.",
+  "Herr Schmidt druckt Bestandspläne (Heizung, Lüftung, Sanitär) aus und hängt sie an Ort und Stelle auf. | Martin | Ich kümmere mich gerne darum das in entsprechender Papierform auszudrucken in Hefter zu tun und dann an Ort und Stelle zu verbringen.",
+  "BPD prüft die Möglichkeit eines Wartungsvertrags für Pumpen-Notdienst (z.B. Firma 'Pumpen Kahl'). | Gibt es Wartungsvertrag wie Sie sagen vom Pumpen Kahl rufe ich dann an 24 Stunden Notdienst und dann kommt er halt und pumpt mir den Keller aus.",
+  "BPD klärt mit der Feuerwehr die Kostenübernahme bei Wassereintritten in Tiefgaragen. | Also wir müssen es halt dann bezahlen wenn wir die Schuldigen sind."
+]
+```
+
+## Positions Involving Bj?rn
+
+Old:
+```json
+[]
+```
+
+New:
+```json
+[]
+```
+
+## Focus Checks
+
+- Bj?rn unsupported responsibility in new todos: False
+- Context provenance present: True
+- Potential information loss by coarse counts: True

samples/benchmarks/meeting_context_v1/jovana_alias_correction_v1/chunk_01_extraction_with_context.json

@@ -0,0 +1,25 @@
+{
+  "facts": [
+    "Martin | Das ist das aktuelle Projektdeckblatt, was wir in der F&E benutzen. Und zwar ist das auch eher, ich sage mal, optional, was da so drin steht. | clear | das ist das aktuelle Projektdeckblatt, was wir in der F&E benutzen",
+    "Das Ding ist ja mit einer anderen Idee entwickelt worden. Also hier erstmal Name... | clear | Das Ding ist ja mit einer anderen Idee entwickelt worden."
+  ],
+  "decisions": [],
+  "todos": [
+    "Erstellen eines ersten Entwurfs für einen Auswahlkatalog, der Kriterien aus EDD (Normen, technische Akzeptanz), Marketing und PM integriert. | dass sie die dann in so einem Auswahlkatalog berücksichtigt und dass sie da mal einen ersten Entwurf für macht",
+    "Zusammenstellen der Kriterien durch Jovana. | Jovana | sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt"
+  ],
+  "questions": [
+    "Welche spezifischen Auswahlkriterien sind für digitale Produkte relevant (z.B. kulturelle Hürden, Sprache)? | Wenn wir zum Beispiel über das Portal reden, dann reden wir zum Beispiel über digitale Affinität...",
+    "Welche spezifischen Auswahlkriterien sind für Realprodukte relevant? | ...als wenn wir über ein Realprodukt reden."
+  ],
+  "positions": [],
+  "technical": [
+    "Projektsheet Struktur | Das ist kein Entscheidungsbaum, sondern das ist letztendlich eine Dokumentation der Sachen. Lastenheft, Pflichtenheft... | clear | das ist kein Entscheidungsbaum, sondern das ist letztendlich eine Dokumentation der Sachen",
+    "Filterfunktion des Projektsheets | Wenn irgendwas dabei rauskommt... dann würde ich die Hand heben und würde sagen, lieber Mensch, der du dieses Projekt starten willst, ich glaube nicht, dass das sinnvoll ist. | clear | dann würde ich die Hand heben und würde sagen, lieber Mensch, der du dieses Projekt starten willst, ich glaube nicht, dass das sinnvoll ist"
+  ],
+  "context": {
+    "meeting_id": "2026-07-27-projektprozess",
+    "source_file": "samples\\real_live\\project_process_meeting\\meeting_context.yaml",
+    "schema_version": "1"
+  }
+}

samples/benchmarks/meeting_context_v1/jovana_alias_correction_v1/comparison.md

@@ -0,0 +1,54 @@
+# Jovana Alias Correction Evaluation
+
+## Run
+
+- Runtime seconds: 13.064
+- Prompt characters: 16510
+- Model: qwen3.5:9B
+- Thinking: false
+
+## Previous Relevant Decisions
+
+```json
+[
+  "Jovana wird die Auswahlkriterien für Business Development-Projekte zusammenstellen und diese mit den von EDD, Marketing und PM definierten Kriterien integrieren. | Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt [...] bittet aber im Prinzip darum, es wäre hilfreich, wenn wir auch die von euch EDD, Marketing, PM bereits definierten Auswahlkriterien mit integrieren könnten in den Filter."
+]
+```
+
+## Previous Relevant Todos
+
+```json
+[
+  "Zusammenstellen der Kriterien für Business Development-Projekte und Integration der bestehenden Auswahlkriterien aus EDD, Marketing und PM. | Jovana | Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt"
+]
+```
+
+## New Decisions Involving Jovana Or Bjoern
+
+```json
+[]
+```
+
+## New Todos Involving Jovana Or Bjoern
+
+```json
+[
+  "Zusammenstellen der Kriterien durch Jovana. | Jovana | sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt"
+]
+```
+
+## All New Bjoern Items
+
+```json
+[]
+```
+
+## Assessment
+
+- Bjoern unsupported assignments: []
+- Transcript spelling resolved explicitly to Jovana: True
+- Transcript spelling retained in output: False
+- Jovana proposal representation: valid todo
+- Improper strengthening of "sie w?rde sich darum bem?hen": False
+- New attribution error candidates: []
+- Overall classification: improved

samples/benchmarks/meeting_context_v1/jovana_alias_correction_v1/run_metadata.json

@@ -0,0 +1,12 @@
+{
+  "runtime_seconds": 13.064,
+  "prompt_characters": 16510,
+  "model": "qwen3.5:9B",
+  "prompt_eval_count": 4024,
+  "eval_count": 835,
+  "think": false,
+  "task_prompt_names": [
+    "decisions.md",
+    "todos.md"
+  ]
+}

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_01.txt

@@ -0,0 +1,285 @@
+Mail geschrieben, was Sie gerade so treiben.
+
+Können wir meinetwegen auch kurz mit anfangen.
+
+Das dient ja im Wesentlichen dem Austausch hier.
+
+Ich kann euch das ja rein teilen.
+
+Das ist am einfachsten.
+
+Also sie fragt, ob wir eigentlich,
+
+wenn wir Projekte angehen,
+
+und das war ja eins der Themen,
+
+wie steuern wir Projekte,
+
+wie legen wir die Filter an,
+
+welche Projekte für uns relevant sind,
+
+welche Projekte zur Ausführung kommen,
+
+ob wir uns an dem Projektsheet,
+
+was du mal gemacht hast, Martin, orientieren können oder nicht.
+
+Ich habe das nur einmal gesehen.
+
+Das erschien mir auch sehr umfangreich.
+
+Meier hat das neulich mal genutzt.
+
+Der hattest du das, glaube ich, zur Verfügung gestellt.
+
+Vielleicht kannst du uns das noch mal einmal zeigen.
+
+Also Maya hat das versucht für den Testmarkt des Portals zu nutzen und umzusetzen.
+
+Das ging auch.
+
+Es ist aber wirklich recht umfangreich, muss man schon sagen.
+
+Aber erzähl mal kurz was dazu.
+
+Ja, also das Ganze ist ja auch nicht mit dem Hintergrund gedacht gewesen,
+
+sondern das ist das aktuelle Projektdeckblatt, was wir in der F&E benutzen.
+
+Und zwar ist das auch eher, ich sage mal, optional, was da so drin steht.
+
+Das hat ganz viele Folien, die bestimmte Sachen vorgeben und wo immer das auch notwendig ist, benutzen wir die.
+
+Und die Folien, die wir nicht benutzen, die blenden wir einfach aus, die benutzen wir halt einfach nicht.
+
+dann reduziert sich das in den allermeisten Fällen.
+
+Also ich habe lange nicht für alles ein Gantt-Diagramm zum Beispiel.
+
+Das brauchst du ja nicht immer, wenn man sucht.
+
+Kannst du einmal an deinem Mikrofon wackeln oder das näher ran machen?
+
+Das klingt so ein bisschen robotermäßig.
+
+Okay.
+
+Stumm wieder aus. Besser jetzt?
+
+Ja.
+
+Ist, wie es ist.
+
+finde ich jetzt echt spontan
+
+die Präsentation finde ich spontan
+
+Achso, Maja hast du gesagt, habe ich das geschickt
+
+dann müsste ich es ja da
+
+Wie schrieb
+
+sich, wie schrieb die sich denn?
+
+M-A-I-Y
+
+Die schrieb sich nicht so wie
+
+M-A-I-J-A
+
+schreibt sie sich.
+
+Ja.
+
+Ja, M-A-I-J-A.
+
+Was habe ich gesagt?
+
+Y. Ist aber egal.
+
+Oh, nee. Bullshit. Entschuldigung.
+
+Ist völlig egal.
+
+So, teilen.
+
+Das Ding ist ja mit einer anderen Idee entwickelt worden.
+
+Also hier erstmal Name. Ich glaube, das ist unstrittig.
+
+Name, Projektname, was auch immer.
+
+Das ist eine kurze Projektidee.
+
+Das ist natürlich jetzt hier viel Dummy-Text.
+
+Teilweise sind das nur ein, zwei, drei Sätze.
+
+Was ist dann das Ziel, wenn man es formulieren kann?
+
+Also die Projektidee kann die Entwicklung eines Produkts für den Markt EGY sein.
+
+Und Ziel ist halt irgendwie ein Fließstoff mit so und so viel Gramm in der Farbe Blau
+
+und eine Betonidmatte mit so und so viel Gramm pro Quadratmeter mit einem lilanen Gewebe und einem grünen Fließstoff.
+
+Und was weiß ich niemals nicht alles.
+
+und hier haben wir mal so ein bisschen für uns so ein paar Sachen hingeschrieben,
+
+die sind aber lange nicht vollständig.
+
+Warum wollen wir das überhaupt machen?
+
+Also die Frage von der GF ist ja dann häufig, was kommt da überhaupt raus?
+
+Die 5 Millionen in 5 Jahren von 5 Leuten oder so ähnlich.
+
+Das war das da schon.
+
+Gegen wen treten wir da an?
+
+Gibt es irgendwas, worauf wir achten müssen bei der Entwicklung und so weiter?
+
+Gibt es vielleicht schon irgendwie Gebrauchsmuster und so?
+
+Das ist kein Entscheidungsbaum, sondern das ist letztendlich eine Dokumentation der Sachen. Lastenheft, Pflichtenheft, kennt ihr alles. Und dann habe ich mal versucht, hier so eine ganz grobe, wenn es geht, eine Budgetabfrage machen. Die füllen wir auch lange nicht jedes Mal aus, weil es manchmal halt auch gar nicht geht in dem Detail.
+
+intern, extern geteilten Projektzeitplan ist natürlich immer ganz sinnvoll.
+
+Und wenn man es macht als Gant.
+
+Und danach kommt eigentlich nur noch das, was wir dann bei uns mitführen,
+
+im Sinne von der Projektdokumentation.
+
+Also die Zwischenergebnisse, Arbeitsstände und so weiter, die kommen dann einfach hinten ran.
+
+Und dann baut sich daraus eine Präsentation auf, die man
+
+hinteren Teil der Produktion,
+
+Präsentation, den kann ich halt
+
+in der Regel einfach nehmen und irgendwem zeigen,
+
+der halbwegs im Thema drinsteckt
+
+und man kann dann den Projektstand danach
+
+oder die Projektentwicklung danach durchgehen.
+
+Mehr ist es nicht. Also es ist jetzt kein
+
+Filtersystem gewesen. Dafür war es auch
+
+nie gedacht.
+
+Ja.
+
+Also der Trigger hat natürlich hier vorne so ein paar Sachen.
+
+Also wenn du so willst, dann ist
+
+das hier noch so eine Art Filter.
+
+Wenn irgendwas dabei rauskommt, wenn man jetzt das Marktvolumen hinterfragt und stellt fest, das sind eigentlich nur 10.000 Quadratmeter im Jahr, dann würde ich die Hand heben und würde sagen, lieber Mensch, der du dieses Projekt starten willst, ich glaube nicht, dass das sinnvoll ist. Oder wir finden relativ früh, da sprechen jetzt irgendwie sieben Patente von drei Mitbewerbern gegen. Wollt ihr das wirklich machen?
+
+Ja, ja. Okay, nee, das ist okay. Dann ist das aber ganz klar bezogen auf F&E und PM-Projekte. Dann entspricht das im Prinzip dem Projektdeckblatt und passt auch zu dem Prozess, den wir im Prozessmanagement haben für F&E und PM-Projekte, also geübtes Verfahren eigentlich.
+
+So ist das.
+
+Jetzt hatte Jovanna ja angemerkt, dass das, also so gesehen hat Maya das jetzt eigentlich für das Projekt Testmarkt entfremdet. Funktioniert aber dafür auch. Björn, für das Thema Testmarkt ging das, glaube ich, so.
+
+Ich denke, und das ist jetzt die Anmerkung von Giovanna, das kann man natürlich oder sollte man, wenn man über Business Development Projekte spreche, also wirklich Marktentwicklungsfragen, dann muss man sicherlich da etwas andere Kriterien anlegen und auch die Liste vorne ergänzen.
+
+Woran müssen wir denken? Was müssen wir abfragen? Wer ist eingebunden?
+
+Nur das war halt bei der Entwicklung von dieser Datei ist das ja alles schon passiert.
+
+Also jetzt kommt ja schon einer mit einer konkreten Sache, die ich abzuarbeiten habe.
+
+Und deswegen setzt diese Datei eigentlich auch schon einen Schritt dahinter an und dokumentiert eigentlich nur nochmal das.
+
+Diese Marktaussagen, die müssen eigentlich ja vorher von jemand anderem gemacht werden.
+
+Das kann ich in meiner Abteilung in den selten Fällen machen. Insofern sind das Informationen, die ich eigentlich schon voraussetze und wir gesagt haben, nur wir schreiben es da rein, weil es passiert ja, da ruft die GF an, sagt, was ist eigentlich hier, was macht ihr eigentlich bei diesem und jenem und dann kann ich einfach diese Datei hochziehen und kann sagen, wir sind ausgegangen davon, dass wir ein Marktvolumen von sechs Millionen pro Jahr haben.
+
+Diese und jene Wettbewerber haben wir da.
+
+Inhaltlich hinterfrage ich das aber nicht mehr wirklich,
+
+weil das nicht meine Kompetenz ist,
+
+sondern das nehme ich erst mal als gegeben hin.
+
+Was ich hinterfrage ist,
+
+sind die angegebenen Werte, die ich da komme,
+
+dazu zu dem Aufwand, den ich hinterher abschätze?
+
+Das überlege ich mir und dann gebe ich eine entsprechende Antwort.
+
+Und dafür war das Ding gedacht.
+
+Wir können das jetzt gerne als Vorlage nehmen und da vorne eben noch Sachen hinzufügen, die diese Fragen eben klären. Aber dafür war es nie gedacht bis jetzt.
+
+Ja, okay. Also Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt, bittet aber im Prinzip darum, es wäre hilfreich, wenn wir auch die von euch EDD, Marketing, PM bereits definierten Auswahlkriterien mit integrieren könnten in den Filter.
+
+Also jetzt müssten wir im Prinzip mal sagen aus EDD-Sicht, was ist da relevant? Das sind natürlich Normen, das sind technische Akzeptanz von Dingen, das ist Absicherung, gibt es einen definierten Stand der Technik und, und, und.
+
+das deckt sich viel mit dem
+
+aus PM-Sicht, aus
+
+Marketing-Sicht, Björn, wirst du andere
+
+Kriterien haben, aber
+
+die könnten wir ja im Prinzip zusammenstellen
+
+und mal schicken, dass sie die
+
+dann in so einem Auswahlkatalog
+
+berücksichtigt und dass sie da mal einen ersten
+
+Entwurf für macht. Du hast es auch
+
+vorgeschlagen.
+
+Kriterien sind aber nie allgemein.
+
+Die sind ja immer spezifisch. Das heißt, wenn wir
+
+über ein digitales Produkt reden, sind die Kriterien ja ganz,
+
+ganz anders, als wenn wir über ein Realprodukt
+
+reden. Also jetzt als Beispiel, Johann hat ja schon mal nachgefragt und er hat mir auch schon mal
+
+Notizen zugemacht. Wenn wir zum Beispiel über das Portal reden, dann reden wir zum Beispiel über
+
+digitale Affinität zum Beispiel in dem jeweiligen Land. Dann reden wir über Verständnis, kulturelle
+
+Hürden als Beispiel. Dann reden wir halt, wie gesagt, über Sprache, auch primär wichtig. Das ist
+
+ja erstmal beim Produkt erstmal nicht ganz so relevant. Deswegen, das ist immer individuell.
+
+Das kommt ganz auf die Ausgangslage drauf an und das, was wir in Anführungsstrichen dort verkaufen wollen.
+
+Aber da gibt es keinen allgemeinen Abfrag,
+
+wird es auch niemals geben, gibt es auch nie so
+
+anders.
+
+Es ist die Frage,
+
+ob man
+
+zumindest mal ein paar Stichworte

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_01_changes.json

@@ -0,0 +1,185 @@
+{
+  "source_file": "chunk_01.txt",
+  "output_file": "chunk_01_normalized.txt",
+  "blocks_total": 143,
+  "blocks_changed": 22,
+  "policy": {
+    "removed": [
+      "isolated filler sounds such as äh, ähm, hm, mhm",
+      "immediate duplicate words",
+      "immediate duplicate phrases of two to four words",
+      "redundant whitespace"
+    ],
+    "explicitly_preserved": [
+      "negations",
+      "modal words and qualifiers",
+      "dates, times, numbers and quantities",
+      "technical statements",
+      "responsibilities",
+      "deadlines",
+      "decisions and commitments"
+    ],
+    "principle": "When uncertain, leave the text unchanged."
+  },
+  "changes": [
+    {
+      "block_number": 6,
+      "original": "Also sie fragt, ob wir eigentlich,",
+      "normalized": "Also sie fragt, ob wir eigentlich",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 7,
+      "original": "wenn wir Projekte angehen,",
+      "normalized": "wenn wir Projekte angehen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 8,
+      "original": "und das war ja eins der Themen,",
+      "normalized": "und das war ja eins der Themen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 9,
+      "original": "wie steuern wir Projekte,",
+      "normalized": "wie steuern wir Projekte",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 10,
+      "original": "wie legen wir die Filter an,",
+      "normalized": "wie legen wir die Filter an",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 11,
+      "original": "welche Projekte für uns relevant sind,",
+      "normalized": "welche Projekte für uns relevant sind",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 12,
+      "original": "welche Projekte zur Ausführung kommen,",
+      "normalized": "welche Projekte zur Ausführung kommen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 13,
+      "original": "ob wir uns an dem Projektsheet,",
+      "normalized": "ob wir uns an dem Projektsheet",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 24,
+      "original": "Ja, also das Ganze ist ja auch nicht mit dem Hintergrund gedacht gewesen,",
+      "normalized": "Ja, also das Ganze ist ja auch nicht mit dem Hintergrund gedacht gewesen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 66,
+      "original": "und hier haben wir mal so ein bisschen für uns so ein paar Sachen hingeschrieben,",
+      "normalized": "und hier haben wir mal so ein bisschen für uns so ein paar Sachen hingeschrieben",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 78,
+      "original": "Und danach kommt eigentlich nur noch das, was wir dann bei uns mitführen,",
+      "normalized": "Und danach kommt eigentlich nur noch das, was wir dann bei uns mitführen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 82,
+      "original": "hinteren Teil der Produktion,",
+      "normalized": "hinteren Teil der Produktion",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 84,
+      "original": "in der Regel einfach nehmen und irgendwem zeigen,",
+      "normalized": "in der Regel einfach nehmen und irgendwem zeigen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 96,
+      "original": "Ja, ja. Okay, nee, das ist okay. Dann ist das aber ganz klar bezogen auf F&E und PM-Projekte. Dann entspricht das im Prinzip dem Projektdeckblatt und passt auch zu dem Prozess, den wir im Prozessmanagement haben für F&E und PM-Projekte, also geübtes Verfahren eigentlich.",
+      "normalized": "Ja. Okay, nee, das ist okay. Dann ist das aber ganz klar bezogen auf F&E und PM-Projekte. Dann entspricht das im Prinzip dem Projektdeckblatt und passt auch zu dem Prozess, den wir im Prozessmanagement haben für F&E und PM-Projekte, also geübtes Verfahren eigentlich.",
+      "removed_fillers": [],
+      "duplicate_reductions": [
+        "Ja, ja"
+      ]
+    },
+    {
+      "block_number": 107,
+      "original": "Inhaltlich hinterfrage ich das aber nicht mehr wirklich,",
+      "normalized": "Inhaltlich hinterfrage ich das aber nicht mehr wirklich",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 108,
+      "original": "weil das nicht meine Kompetenz ist,",
+      "normalized": "weil das nicht meine Kompetenz ist",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 110,
+      "original": "Was ich hinterfrage ist,",
+      "normalized": "Was ich hinterfrage ist",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 111,
+      "original": "sind die angegebenen Werte, die ich da komme,",
+      "normalized": "sind die angegebenen Werte, die ich da komme",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 117,
+      "original": "Also jetzt müssten wir im Prinzip mal sagen aus EDD-Sicht, was ist da relevant? Das sind natürlich Normen, das sind technische Akzeptanz von Dingen, das ist Absicherung, gibt es einen definierten Stand der Technik und, und, und.",
+      "normalized": "Also jetzt müssten wir im Prinzip mal sagen aus EDD-Sicht, was ist da relevant? Das sind natürlich Normen, das sind technische Akzeptanz von Dingen, das ist Absicherung, gibt es einen definierten Stand der Technik und.",
+      "removed_fillers": [],
+      "duplicate_reductions": [
+        "und, und",
+        "und, und"
+      ]
+    },
+    {
+      "block_number": 130,
+      "original": "über ein digitales Produkt reden, sind die Kriterien ja ganz,",
+      "normalized": "über ein digitales Produkt reden, sind die Kriterien ja ganz",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 138,
+      "original": "Aber da gibt es keinen allgemeinen Abfrag,",
+      "normalized": "Aber da gibt es keinen allgemeinen Abfrag",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 141,
+      "original": "Es ist die Frage,",
+      "normalized": "Es ist die Frage",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    }
+  ]
+}

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_01_normalized.txt

@@ -0,0 +1,285 @@
+Mail geschrieben, was Sie gerade so treiben.
+
+Können wir meinetwegen auch kurz mit anfangen.
+
+Das dient ja im Wesentlichen dem Austausch hier.
+
+Ich kann euch das ja rein teilen.
+
+Das ist am einfachsten.
+
+Also sie fragt, ob wir eigentlich
+
+wenn wir Projekte angehen
+
+und das war ja eins der Themen
+
+wie steuern wir Projekte
+
+wie legen wir die Filter an
+
+welche Projekte für uns relevant sind
+
+welche Projekte zur Ausführung kommen
+
+ob wir uns an dem Projektsheet
+
+was du mal gemacht hast, Martin, orientieren können oder nicht.
+
+Ich habe das nur einmal gesehen.
+
+Das erschien mir auch sehr umfangreich.
+
+Meier hat das neulich mal genutzt.
+
+Der hattest du das, glaube ich, zur Verfügung gestellt.
+
+Vielleicht kannst du uns das noch mal einmal zeigen.
+
+Also Maya hat das versucht für den Testmarkt des Portals zu nutzen und umzusetzen.
+
+Das ging auch.
+
+Es ist aber wirklich recht umfangreich, muss man schon sagen.
+
+Aber erzähl mal kurz was dazu.
+
+Ja, also das Ganze ist ja auch nicht mit dem Hintergrund gedacht gewesen
+
+sondern das ist das aktuelle Projektdeckblatt, was wir in der F&E benutzen.
+
+Und zwar ist das auch eher, ich sage mal, optional, was da so drin steht.
+
+Das hat ganz viele Folien, die bestimmte Sachen vorgeben und wo immer das auch notwendig ist, benutzen wir die.
+
+Und die Folien, die wir nicht benutzen, die blenden wir einfach aus, die benutzen wir halt einfach nicht.
+
+dann reduziert sich das in den allermeisten Fällen.
+
+Also ich habe lange nicht für alles ein Gantt-Diagramm zum Beispiel.
+
+Das brauchst du ja nicht immer, wenn man sucht.
+
+Kannst du einmal an deinem Mikrofon wackeln oder das näher ran machen?
+
+Das klingt so ein bisschen robotermäßig.
+
+Okay.
+
+Stumm wieder aus. Besser jetzt?
+
+Ja.
+
+Ist, wie es ist.
+
+finde ich jetzt echt spontan
+
+die Präsentation finde ich spontan
+
+Achso, Maja hast du gesagt, habe ich das geschickt
+
+dann müsste ich es ja da
+
+Wie schrieb
+
+sich, wie schrieb die sich denn?
+
+M-A-I-Y
+
+Die schrieb sich nicht so wie
+
+M-A-I-J-A
+
+schreibt sie sich.
+
+Ja.
+
+Ja, M-A-I-J-A.
+
+Was habe ich gesagt?
+
+Y. Ist aber egal.
+
+Oh, nee. Bullshit. Entschuldigung.
+
+Ist völlig egal.
+
+So, teilen.
+
+Das Ding ist ja mit einer anderen Idee entwickelt worden.
+
+Also hier erstmal Name. Ich glaube, das ist unstrittig.
+
+Name, Projektname, was auch immer.
+
+Das ist eine kurze Projektidee.
+
+Das ist natürlich jetzt hier viel Dummy-Text.
+
+Teilweise sind das nur ein, zwei, drei Sätze.
+
+Was ist dann das Ziel, wenn man es formulieren kann?
+
+Also die Projektidee kann die Entwicklung eines Produkts für den Markt EGY sein.
+
+Und Ziel ist halt irgendwie ein Fließstoff mit so und so viel Gramm in der Farbe Blau
+
+und eine Betonidmatte mit so und so viel Gramm pro Quadratmeter mit einem lilanen Gewebe und einem grünen Fließstoff.
+
+Und was weiß ich niemals nicht alles.
+
+und hier haben wir mal so ein bisschen für uns so ein paar Sachen hingeschrieben
+
+die sind aber lange nicht vollständig.
+
+Warum wollen wir das überhaupt machen?
+
+Also die Frage von der GF ist ja dann häufig, was kommt da überhaupt raus?
+
+Die 5 Millionen in 5 Jahren von 5 Leuten oder so ähnlich.
+
+Das war das da schon.
+
+Gegen wen treten wir da an?
+
+Gibt es irgendwas, worauf wir achten müssen bei der Entwicklung und so weiter?
+
+Gibt es vielleicht schon irgendwie Gebrauchsmuster und so?
+
+Das ist kein Entscheidungsbaum, sondern das ist letztendlich eine Dokumentation der Sachen. Lastenheft, Pflichtenheft, kennt ihr alles. Und dann habe ich mal versucht, hier so eine ganz grobe, wenn es geht, eine Budgetabfrage machen. Die füllen wir auch lange nicht jedes Mal aus, weil es manchmal halt auch gar nicht geht in dem Detail.
+
+intern, extern geteilten Projektzeitplan ist natürlich immer ganz sinnvoll.
+
+Und wenn man es macht als Gant.
+
+Und danach kommt eigentlich nur noch das, was wir dann bei uns mitführen
+
+im Sinne von der Projektdokumentation.
+
+Also die Zwischenergebnisse, Arbeitsstände und so weiter, die kommen dann einfach hinten ran.
+
+Und dann baut sich daraus eine Präsentation auf, die man
+
+hinteren Teil der Produktion
+
+Präsentation, den kann ich halt
+
+in der Regel einfach nehmen und irgendwem zeigen
+
+der halbwegs im Thema drinsteckt
+
+und man kann dann den Projektstand danach
+
+oder die Projektentwicklung danach durchgehen.
+
+Mehr ist es nicht. Also es ist jetzt kein
+
+Filtersystem gewesen. Dafür war es auch
+
+nie gedacht.
+
+Ja.
+
+Also der Trigger hat natürlich hier vorne so ein paar Sachen.
+
+Also wenn du so willst, dann ist
+
+das hier noch so eine Art Filter.
+
+Wenn irgendwas dabei rauskommt, wenn man jetzt das Marktvolumen hinterfragt und stellt fest, das sind eigentlich nur 10.000 Quadratmeter im Jahr, dann würde ich die Hand heben und würde sagen, lieber Mensch, der du dieses Projekt starten willst, ich glaube nicht, dass das sinnvoll ist. Oder wir finden relativ früh, da sprechen jetzt irgendwie sieben Patente von drei Mitbewerbern gegen. Wollt ihr das wirklich machen?
+
+Ja. Okay, nee, das ist okay. Dann ist das aber ganz klar bezogen auf F&E und PM-Projekte. Dann entspricht das im Prinzip dem Projektdeckblatt und passt auch zu dem Prozess, den wir im Prozessmanagement haben für F&E und PM-Projekte, also geübtes Verfahren eigentlich.
+
+So ist das.
+
+Jetzt hatte Jovanna ja angemerkt, dass das, also so gesehen hat Maya das jetzt eigentlich für das Projekt Testmarkt entfremdet. Funktioniert aber dafür auch. Björn, für das Thema Testmarkt ging das, glaube ich, so.
+
+Ich denke, und das ist jetzt die Anmerkung von Giovanna, das kann man natürlich oder sollte man, wenn man über Business Development Projekte spreche, also wirklich Marktentwicklungsfragen, dann muss man sicherlich da etwas andere Kriterien anlegen und auch die Liste vorne ergänzen.
+
+Woran müssen wir denken? Was müssen wir abfragen? Wer ist eingebunden?
+
+Nur das war halt bei der Entwicklung von dieser Datei ist das ja alles schon passiert.
+
+Also jetzt kommt ja schon einer mit einer konkreten Sache, die ich abzuarbeiten habe.
+
+Und deswegen setzt diese Datei eigentlich auch schon einen Schritt dahinter an und dokumentiert eigentlich nur nochmal das.
+
+Diese Marktaussagen, die müssen eigentlich ja vorher von jemand anderem gemacht werden.
+
+Das kann ich in meiner Abteilung in den selten Fällen machen. Insofern sind das Informationen, die ich eigentlich schon voraussetze und wir gesagt haben, nur wir schreiben es da rein, weil es passiert ja, da ruft die GF an, sagt, was ist eigentlich hier, was macht ihr eigentlich bei diesem und jenem und dann kann ich einfach diese Datei hochziehen und kann sagen, wir sind ausgegangen davon, dass wir ein Marktvolumen von sechs Millionen pro Jahr haben.
+
+Diese und jene Wettbewerber haben wir da.
+
+Inhaltlich hinterfrage ich das aber nicht mehr wirklich
+
+weil das nicht meine Kompetenz ist
+
+sondern das nehme ich erst mal als gegeben hin.
+
+Was ich hinterfrage ist
+
+sind die angegebenen Werte, die ich da komme
+
+dazu zu dem Aufwand, den ich hinterher abschätze?
+
+Das überlege ich mir und dann gebe ich eine entsprechende Antwort.
+
+Und dafür war das Ding gedacht.
+
+Wir können das jetzt gerne als Vorlage nehmen und da vorne eben noch Sachen hinzufügen, die diese Fragen eben klären. Aber dafür war es nie gedacht bis jetzt.
+
+Ja, okay. Also Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt, bittet aber im Prinzip darum, es wäre hilfreich, wenn wir auch die von euch EDD, Marketing, PM bereits definierten Auswahlkriterien mit integrieren könnten in den Filter.
+
+Also jetzt müssten wir im Prinzip mal sagen aus EDD-Sicht, was ist da relevant? Das sind natürlich Normen, das sind technische Akzeptanz von Dingen, das ist Absicherung, gibt es einen definierten Stand der Technik und.
+
+das deckt sich viel mit dem
+
+aus PM-Sicht, aus
+
+Marketing-Sicht, Björn, wirst du andere
+
+Kriterien haben, aber
+
+die könnten wir ja im Prinzip zusammenstellen
+
+und mal schicken, dass sie die
+
+dann in so einem Auswahlkatalog
+
+berücksichtigt und dass sie da mal einen ersten
+
+Entwurf für macht. Du hast es auch
+
+vorgeschlagen.
+
+Kriterien sind aber nie allgemein.
+
+Die sind ja immer spezifisch. Das heißt, wenn wir
+
+über ein digitales Produkt reden, sind die Kriterien ja ganz
+
+ganz anders, als wenn wir über ein Realprodukt
+
+reden. Also jetzt als Beispiel, Johann hat ja schon mal nachgefragt und er hat mir auch schon mal
+
+Notizen zugemacht. Wenn wir zum Beispiel über das Portal reden, dann reden wir zum Beispiel über
+
+digitale Affinität zum Beispiel in dem jeweiligen Land. Dann reden wir über Verständnis, kulturelle
+
+Hürden als Beispiel. Dann reden wir halt, wie gesagt, über Sprache, auch primär wichtig. Das ist
+
+ja erstmal beim Produkt erstmal nicht ganz so relevant. Deswegen, das ist immer individuell.
+
+Das kommt ganz auf die Ausgangslage drauf an und das, was wir in Anführungsstrichen dort verkaufen wollen.
+
+Aber da gibt es keinen allgemeinen Abfrag
+
+wird es auch niemals geben, gibt es auch nie so
+
+anders.
+
+Es ist die Frage
+
+ob man
+
+zumindest mal ein paar Stichworte

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_02.txt

@@ -0,0 +1,205 @@
+aufschreibt, damit den Leuten klar ist, worüber
+
+sie alles nachdenken müssen
+
+oder starten, nachzudenken.
+
+Klar, aber letztendlich, wie gesagt, bei dieser
+
+Anforderung, die wir jetzt ja auch haben,
+
+beziehungsweise des Neuroportals, was Meierler ja auch geschrieben hat,
+
+wie gesagt, da sind das ja die Kriterien, die ich jetzt gerade eben so genannt habe.
+
+Die sind aber, wie gesagt, nicht relevant für ein Realprodukt.
+
+Unbedingt.
+
+Ja, klar.
+
+Oder nicht mit der Gewichtung.
+
+Das ist klar.
+
+Und es kommt ja auch immer auf die Fragestellung an.
+
+Will ich, rede ich über das Einführen von einem Produkt in einem speziellen Markt
+
+oder rede ich davon, mir einen Markt anzusehen, ob der für Nowe grundsätzlich für irgendwas, was Nowe anbietet, interessant sein könnte?
+
+Oder ob er überhaupt zugänglich ist für Nowe?
+
+Also ob ich vom Produkt aus gucke oder von der Leistung aus gucke und suche verschiedene Märkte
+
+oder ob ich mir einen Markt anschaue, ob irgendwas dazu von Nowe passt.
+
+Das sind ja auch nochmal zwei verschiedene Sichtweisen.
+
+Also genau genommen ist das ja der, ich bin jetzt gedanklich beim Ideenprozess, wir fragen ja eigentlich die ersten zwei bis drei Seiten der Präsentation bei der Idee ab.
+
+Und das wird ja auch von James und Co. dann abgefangen. Und danach kommt es in diese Liste und wird in diesem Gremium dann einmal diskutiert und dann wird ja auch zugeordnet, ist das jetzt ein PM-Projekt, ist das ein BD-Projekt, was auch immer.
+
+So, dann kommt ja dieser Projekttyp.
+
+Und dann wird ja auch, wenn es dann entschieden wird oder erstmal gesagt wird,
+
+okay, wir gucken das jetzt erstmal wen an, wir benennen Projektverantwortlichen,
+
+dann kann man ja dieser Person dann projektbezogen auch Dinge mitgeben, die abgefragt werden müssen.
+
+Aber ich bin da schon ein bisschen bei Björn.
+
+Das allgemein als Katalog zu formulieren, glaube ich, würde man, wenn man es am Schluss anwendet,
+
+dann doch wieder so speziell zugeschnitten machen.
+
+Und ich glaube, diese ersten allgemeinen Fragen, die da zum ersten Abgreifen von Informationen gemacht wurden, sind schon sehr allgemein und ziemlich gut. Und wenn man dann einfach mit ein bisschen Fingerspitzengefühl sagt, okay, manche Sachen lassen wir jetzt so jetzt trotzdem durchgehen, dass wir das hier diskutieren können und manche Sachen geben wir eben wieder zurück, das kriegen James und Co. auch hin.
+
+Das ist jetzt die Frage, was man damit erreichen will auch.
+
+Wir haben ja auch gesagt, dass wir zumindest mal am Anfang auch die initial Abgelehnten immer mit reinnehmen, sodass dann jemand von uns sagen kann, oh, das konnten die beiden nicht wissen oder da ist was falsch verstanden oder in irgendeinem Kontext. Das holen wir jetzt per Order-Mufti rein.
+
+Ja, okay, aber ist ja auch klar, so wie der jetzt im Prozessmanagement ist, der Prozess, ich nehme Henning auch mal, ich versuche das nachher mal einmal kurz zusammenzufassen,
+
+ist der ja im Wesentlichen abgestimmt auf Entwicklungsideen.
+
+Und es geht um Projekte, die entweder physische oder meinetwegen auch nicht physischer Natur sind.
+
+Da klopfen wir das ab und das geht.
+
+Aber es geht um ein konkretes Ding, um ein Produkt, was entwickelt wird.
+
+Und Jovanas Frage ist, können wir diesen Prozess, ist der jetzt einfach nur F&E intern, oder können wir den auch nutzen, um allgemeine Projekte, Geschäftsentwicklungsprojekte bei Nauer durch diesen Prozess zu jagen?
+
+und können wir innerhalb dieses Prozesses Filter einbauen,
+
+die das dann auch mit abfangen und abfragen?
+
+Oder brauchen wir einen eigenen Prozess bei Noah?
+
+Wer ist wann wo eingebunden?
+
+Das ist die Frage.
+
+Also ich glaube, wir können...
+
+Und vom Grundsatz her...
+
+Entschuldige.
+
+Ja? Nee, sprich ruhig aus.
+
+Ich glaube, im Grunde können wir einen Großteil des Prozesses nehmen,
+
+denn wir entscheiden ja ziemlich zum Anfang.
+
+Wir entscheiden ja...
+
+Der Prozess fängt ja damit an, dass es erstmal entschieden wird, passt es überhaupt ins Programm im weitesten Sinne.
+
+Passt es in die Strategie?
+
+Genau.
+
+Passt es in die Strategie?
+
+Ja, nein. Wenn nein, fliegt es raus, beziehungsweise dann muss man sich ganz genau überlegen, ob man es vielleicht doch macht über irgendeine andere Schiene.
+
+Wenn ja, dann fällt ja die Entscheidung letztendlich, in welche Abteilung es tropft.
+
+Und da, wenn du da BD, haben wir ja gesagt, nehmen wir da zu.
+
+Ja.
+
+Und dann kann BD durchaus einen anderen Ablauf nehmen in Form so eines Projektblattes, als das bei den produktartigen Sachen ist. Genauso, wenn das applicable ist, dann für Marketing auch.
+
+Also ich finde, an der Stelle trennt sich das. Der grundsätzliche Ablauf bleibt ja aber trotzdem der gleiche. Also es sind zwar andere Fragestellungen, aber es gibt ProjektleiterInnen, es gibt bestimmte Dinge, die zu machen sind, die sind auch in Dokumentationen, bestimmte Ziele sind zu erfüllen, bestimmte Kriterien zu erfüllen und so weiter und so fort.
+
+Das ist ja alles im Prinzip wieder das Gleiche. Mit anderen Formulierungen, hat andere Namen und so weiter und so fort. Aber im Prinzip ist das eigentlich wieder das Gleiche. Projektplan muss erstellt werden, wo ich es da gerade lese. Irgendwie eine Art Lastenheft wird es auch geben. Also auch für ein Business Development Projekt kann ich mir so etwas wie ein Lastenheft vorstellen. Was will ich in dem Markt erreichen? Und wie komme ich da hin?
+
+Also einer sagt, ich will 5%, ich will diese 5% des Marktes von GCLs in 6 Jahren, was weiß ich. Und irgendwer anders schreibt dann das Pflichtenheft dazu und sagt, da brauche ich 3 Leute für, also das mache ich mit 3 Leuten, da brauche ich vom Marketing Unterlagen, da brauche ich vom Produktmanagement ein modifiziertes Produkt für diesen Markt und so weiter und so fort.
+
+Das ist ja alles im Prinzip das Gleiche. Egal, ob es jetzt ein digitales Produkt ist, ein Flyer oder ein physisches Produkt. Also ich glaube, der Prozess an sich deckt das alles ab. Man muss nur unterschiedliche Dokumente verwenden auf dem Weg.
+
+ähnlich.
+
+Ich habe es noch mal gerade hier geteilt.
+
+Ich hoffe, das ist in Ordnung. Wir haben die
+
+Änderung dadurch, dass
+
+vor zwei Wochen auch kein Feedback mehr
+
+von anderer Seite herangetragen
+
+wurde,
+
+auch soweit jetzt angestoßen.
+
+Also natürlich ist sowas immer nicht in Stein gemeißelt
+
+und man kann das immer wieder anpassen.
+
+Aber ich denke, wenn
+
+wir in diesem Gremium entschieden haben,
+
+dass es
+
+passt. Bei dieser Übergabe zu der Projektleitung und hier zu dem Zeitpunkt ist ja schon klar, ist es ein BD-Projekt, ist es ein PM-Projekt, wie diese Projektleitung das dann macht, das kann ja auch variieren. Das geben wir ja auch gar nicht mehr strukturell vor.
+
+Also das ist ja auch einfach ein Kreislauf dann in dem Fall, wo einfach nur gesagt wird,
+
+okay, Projektdeckblatt und Lastenheft und so weiter muss jetzt erstmal ausgefüllt sein, damit es irgendwie losgeht.
+
+Aber wenn da andere Anforderungen an Lastenheft sind, dann sollen die das auf diese Art und Weise machen, wie sie es für richtig halten.
+
+Das ist doch hier auch gar nicht festgehalten in dem Sinne.
+
+Wenn man es formal korrekt machen würde, das sind ja Swimlane-Diagramme, die du da hast.
+
+Wenn du es formal korrekt machen würdest, dann müsstest du jetzt an der Stelle, wo jetzt gegebenenfalls Projektplanstellen steht, es aufteilen. Da müsste ein Kasten dazwischen, in welche Abteilung es sozusagen geht und in welchen Unterprozess, also eher Abteilung, glaube ich, genau.
+
+Wir haben es hier schon allgemein benannt.
+
+Das habe ich von vorher auch so übernommen.
+
+Diese Projektleitung ist überhaupt nicht abteilungszugeordnet.
+
+Diese eine Swimline.
+
+Okay, und das geht?
+
+Das war vorher auch so.
+
+Das haben wir übernommen und ich finde es eigentlich auch ganz treffend.
+
+Das heißt, das ist hier schon gar nicht mehr definiert.
+
+Ja.
+
+Und dadurch sind wir hier auch noch recht frei.
+
+Und wir können in den Kästen,
+
+Also man würde ja jetzt in diesem gegebenenfalls Projektplan erstellen, könnten wir verschiedene Dokumente erwähnen, hinterlegen. Da wäre dann der für F&E-Projekte, der für PM-Projekte, der für Marketing-Projekte und der für BD-Projekte drin.
+
+Ja, genau. Also theoretisch kann man das auch noch präzisieren. Ich habe es jetzt in den allgemeinen Prozess gar nicht, das Dokument selbst mit aufgenommen, zumindest in der Weiterleitung jetzt an die QS, beziehungsweise genau genommen, ich sitze heute Nachmittag nochmal mit Henning und Monika zusammen.
+
+Wir hatten ja schon darüber gesprochen, Martin, um das zu überführen. Die E-Mail-Adresse sind auch schon angelegt, wo die ganzen Informationen ankommen sollen. Das heißt, ich warte jetzt erstmal deren Feedback ab. So wie es aussieht, hat Henning da noch ein, zwei Punkte.
+
+Aber im Großen und Ganzen sind die meisten Kriterien
+
+und die meisten Änderungen am Prozess ja auch hier vorne gewesen.
+
+Eben das BD mit aufnehmen.
+
+Und hier würde ich es auch eben genau aus den Gründen,
+
+die Giovanna angesprochen hat, relativ offen lassen.
+
+Weil es auch, wie Björn sagt, es ist so viele verschiedene Sichtweisen.
+
+Also wir können dafür jedes Szenario ein Dokument hinterlegen,

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_02_changes.json

@@ -0,0 +1,124 @@
+{
+  "source_file": "chunk_02.txt",
+  "output_file": "chunk_02_normalized.txt",
+  "blocks_total": 103,
+  "blocks_changed": 14,
+  "policy": {
+    "removed": [
+      "isolated filler sounds such as äh, ähm, hm, mhm",
+      "immediate duplicate words",
+      "immediate duplicate phrases of two to four words",
+      "redundant whitespace"
+    ],
+    "explicitly_preserved": [
+      "negations",
+      "modal words and qualifiers",
+      "dates, times, numbers and quantities",
+      "technical statements",
+      "responsibilities",
+      "deadlines",
+      "decisions and commitments"
+    ],
+    "principle": "When uncertain, leave the text unchanged."
+  },
+  "changes": [
+    {
+      "block_number": 5,
+      "original": "Anforderung, die wir jetzt ja auch haben,",
+      "normalized": "Anforderung, die wir jetzt ja auch haben",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 6,
+      "original": "beziehungsweise des Neuroportals, was Meierler ja auch geschrieben hat,",
+      "normalized": "beziehungsweise des Neuroportals, was Meierler ja auch geschrieben hat",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 23,
+      "original": "Und dann wird ja auch, wenn es dann entschieden wird oder erstmal gesagt wird,",
+      "normalized": "Und dann wird ja auch, wenn es dann entschieden wird oder erstmal gesagt wird",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 24,
+      "original": "okay, wir gucken das jetzt erstmal wen an, wir benennen Projektverantwortlichen,",
+      "normalized": "okay, wir gucken das jetzt erstmal wen an, wir benennen Projektverantwortlichen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 27,
+      "original": "Das allgemein als Katalog zu formulieren, glaube ich, würde man, wenn man es am Schluss anwendet,",
+      "normalized": "Das allgemein als Katalog zu formulieren, glaube ich, würde man, wenn man es am Schluss anwendet",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 32,
+      "original": "Ja, okay, aber ist ja auch klar, so wie der jetzt im Prozessmanagement ist, der Prozess, ich nehme Henning auch mal, ich versuche das nachher mal einmal kurz zusammenzufassen,",
+      "normalized": "Ja, okay, aber ist ja auch klar, so wie der jetzt im Prozessmanagement ist, der Prozess, ich nehme Henning auch mal, ich versuche das nachher mal einmal kurz zusammenzufassen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 38,
+      "original": "und können wir innerhalb dieses Prozesses Filter einbauen,",
+      "normalized": "und können wir innerhalb dieses Prozesses Filter einbauen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 47,
+      "original": "Ich glaube, im Grunde können wir einen Großteil des Prozesses nehmen,",
+      "normalized": "Ich glaube, im Grunde können wir einen Großteil des Prozesses nehmen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 69,
+      "original": "wurde,",
+      "normalized": "wurde",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 74,
+      "original": "wir in diesem Gremium entschieden haben,",
+      "normalized": "wir in diesem Gremium entschieden haben",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 77,
+      "original": "Also das ist ja auch einfach ein Kreislauf dann in dem Fall, wo einfach nur gesagt wird,",
+      "normalized": "Also das ist ja auch einfach ein Kreislauf dann in dem Fall, wo einfach nur gesagt wird",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 93,
+      "original": "Und wir können in den Kästen,",
+      "normalized": "Und wir können in den Kästen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 100,
+      "original": "Und hier würde ich es auch eben genau aus den Gründen,",
+      "normalized": "Und hier würde ich es auch eben genau aus den Gründen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 103,
+      "original": "Also wir können dafür jedes Szenario ein Dokument hinterlegen,",
+      "normalized": "Also wir können dafür jedes Szenario ein Dokument hinterlegen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    }
+  ]
+}

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_02_normalized.txt

@@ -0,0 +1,205 @@
+aufschreibt, damit den Leuten klar ist, worüber
+
+sie alles nachdenken müssen
+
+oder starten, nachzudenken.
+
+Klar, aber letztendlich, wie gesagt, bei dieser
+
+Anforderung, die wir jetzt ja auch haben
+
+beziehungsweise des Neuroportals, was Meierler ja auch geschrieben hat
+
+wie gesagt, da sind das ja die Kriterien, die ich jetzt gerade eben so genannt habe.
+
+Die sind aber, wie gesagt, nicht relevant für ein Realprodukt.
+
+Unbedingt.
+
+Ja, klar.
+
+Oder nicht mit der Gewichtung.
+
+Das ist klar.
+
+Und es kommt ja auch immer auf die Fragestellung an.
+
+Will ich, rede ich über das Einführen von einem Produkt in einem speziellen Markt
+
+oder rede ich davon, mir einen Markt anzusehen, ob der für Nowe grundsätzlich für irgendwas, was Nowe anbietet, interessant sein könnte?
+
+Oder ob er überhaupt zugänglich ist für Nowe?
+
+Also ob ich vom Produkt aus gucke oder von der Leistung aus gucke und suche verschiedene Märkte
+
+oder ob ich mir einen Markt anschaue, ob irgendwas dazu von Nowe passt.
+
+Das sind ja auch nochmal zwei verschiedene Sichtweisen.
+
+Also genau genommen ist das ja der, ich bin jetzt gedanklich beim Ideenprozess, wir fragen ja eigentlich die ersten zwei bis drei Seiten der Präsentation bei der Idee ab.
+
+Und das wird ja auch von James und Co. dann abgefangen. Und danach kommt es in diese Liste und wird in diesem Gremium dann einmal diskutiert und dann wird ja auch zugeordnet, ist das jetzt ein PM-Projekt, ist das ein BD-Projekt, was auch immer.
+
+So, dann kommt ja dieser Projekttyp.
+
+Und dann wird ja auch, wenn es dann entschieden wird oder erstmal gesagt wird
+
+okay, wir gucken das jetzt erstmal wen an, wir benennen Projektverantwortlichen
+
+dann kann man ja dieser Person dann projektbezogen auch Dinge mitgeben, die abgefragt werden müssen.
+
+Aber ich bin da schon ein bisschen bei Björn.
+
+Das allgemein als Katalog zu formulieren, glaube ich, würde man, wenn man es am Schluss anwendet
+
+dann doch wieder so speziell zugeschnitten machen.
+
+Und ich glaube, diese ersten allgemeinen Fragen, die da zum ersten Abgreifen von Informationen gemacht wurden, sind schon sehr allgemein und ziemlich gut. Und wenn man dann einfach mit ein bisschen Fingerspitzengefühl sagt, okay, manche Sachen lassen wir jetzt so jetzt trotzdem durchgehen, dass wir das hier diskutieren können und manche Sachen geben wir eben wieder zurück, das kriegen James und Co. auch hin.
+
+Das ist jetzt die Frage, was man damit erreichen will auch.
+
+Wir haben ja auch gesagt, dass wir zumindest mal am Anfang auch die initial Abgelehnten immer mit reinnehmen, sodass dann jemand von uns sagen kann, oh, das konnten die beiden nicht wissen oder da ist was falsch verstanden oder in irgendeinem Kontext. Das holen wir jetzt per Order-Mufti rein.
+
+Ja, okay, aber ist ja auch klar, so wie der jetzt im Prozessmanagement ist, der Prozess, ich nehme Henning auch mal, ich versuche das nachher mal einmal kurz zusammenzufassen
+
+ist der ja im Wesentlichen abgestimmt auf Entwicklungsideen.
+
+Und es geht um Projekte, die entweder physische oder meinetwegen auch nicht physischer Natur sind.
+
+Da klopfen wir das ab und das geht.
+
+Aber es geht um ein konkretes Ding, um ein Produkt, was entwickelt wird.
+
+Und Jovanas Frage ist, können wir diesen Prozess, ist der jetzt einfach nur F&E intern, oder können wir den auch nutzen, um allgemeine Projekte, Geschäftsentwicklungsprojekte bei Nauer durch diesen Prozess zu jagen?
+
+und können wir innerhalb dieses Prozesses Filter einbauen
+
+die das dann auch mit abfangen und abfragen?
+
+Oder brauchen wir einen eigenen Prozess bei Noah?
+
+Wer ist wann wo eingebunden?
+
+Das ist die Frage.
+
+Also ich glaube, wir können...
+
+Und vom Grundsatz her...
+
+Entschuldige.
+
+Ja? Nee, sprich ruhig aus.
+
+Ich glaube, im Grunde können wir einen Großteil des Prozesses nehmen
+
+denn wir entscheiden ja ziemlich zum Anfang.
+
+Wir entscheiden ja...
+
+Der Prozess fängt ja damit an, dass es erstmal entschieden wird, passt es überhaupt ins Programm im weitesten Sinne.
+
+Passt es in die Strategie?
+
+Genau.
+
+Passt es in die Strategie?
+
+Ja, nein. Wenn nein, fliegt es raus, beziehungsweise dann muss man sich ganz genau überlegen, ob man es vielleicht doch macht über irgendeine andere Schiene.
+
+Wenn ja, dann fällt ja die Entscheidung letztendlich, in welche Abteilung es tropft.
+
+Und da, wenn du da BD, haben wir ja gesagt, nehmen wir da zu.
+
+Ja.
+
+Und dann kann BD durchaus einen anderen Ablauf nehmen in Form so eines Projektblattes, als das bei den produktartigen Sachen ist. Genauso, wenn das applicable ist, dann für Marketing auch.
+
+Also ich finde, an der Stelle trennt sich das. Der grundsätzliche Ablauf bleibt ja aber trotzdem der gleiche. Also es sind zwar andere Fragestellungen, aber es gibt ProjektleiterInnen, es gibt bestimmte Dinge, die zu machen sind, die sind auch in Dokumentationen, bestimmte Ziele sind zu erfüllen, bestimmte Kriterien zu erfüllen und so weiter und so fort.
+
+Das ist ja alles im Prinzip wieder das Gleiche. Mit anderen Formulierungen, hat andere Namen und so weiter und so fort. Aber im Prinzip ist das eigentlich wieder das Gleiche. Projektplan muss erstellt werden, wo ich es da gerade lese. Irgendwie eine Art Lastenheft wird es auch geben. Also auch für ein Business Development Projekt kann ich mir so etwas wie ein Lastenheft vorstellen. Was will ich in dem Markt erreichen? Und wie komme ich da hin?
+
+Also einer sagt, ich will 5%, ich will diese 5% des Marktes von GCLs in 6 Jahren, was weiß ich. Und irgendwer anders schreibt dann das Pflichtenheft dazu und sagt, da brauche ich 3 Leute für, also das mache ich mit 3 Leuten, da brauche ich vom Marketing Unterlagen, da brauche ich vom Produktmanagement ein modifiziertes Produkt für diesen Markt und so weiter und so fort.
+
+Das ist ja alles im Prinzip das Gleiche. Egal, ob es jetzt ein digitales Produkt ist, ein Flyer oder ein physisches Produkt. Also ich glaube, der Prozess an sich deckt das alles ab. Man muss nur unterschiedliche Dokumente verwenden auf dem Weg.
+
+ähnlich.
+
+Ich habe es noch mal gerade hier geteilt.
+
+Ich hoffe, das ist in Ordnung. Wir haben die
+
+Änderung dadurch, dass
+
+vor zwei Wochen auch kein Feedback mehr
+
+von anderer Seite herangetragen
+
+wurde
+
+auch soweit jetzt angestoßen.
+
+Also natürlich ist sowas immer nicht in Stein gemeißelt
+
+und man kann das immer wieder anpassen.
+
+Aber ich denke, wenn
+
+wir in diesem Gremium entschieden haben
+
+dass es
+
+passt. Bei dieser Übergabe zu der Projektleitung und hier zu dem Zeitpunkt ist ja schon klar, ist es ein BD-Projekt, ist es ein PM-Projekt, wie diese Projektleitung das dann macht, das kann ja auch variieren. Das geben wir ja auch gar nicht mehr strukturell vor.
+
+Also das ist ja auch einfach ein Kreislauf dann in dem Fall, wo einfach nur gesagt wird
+
+okay, Projektdeckblatt und Lastenheft und so weiter muss jetzt erstmal ausgefüllt sein, damit es irgendwie losgeht.
+
+Aber wenn da andere Anforderungen an Lastenheft sind, dann sollen die das auf diese Art und Weise machen, wie sie es für richtig halten.
+
+Das ist doch hier auch gar nicht festgehalten in dem Sinne.
+
+Wenn man es formal korrekt machen würde, das sind ja Swimlane-Diagramme, die du da hast.
+
+Wenn du es formal korrekt machen würdest, dann müsstest du jetzt an der Stelle, wo jetzt gegebenenfalls Projektplanstellen steht, es aufteilen. Da müsste ein Kasten dazwischen, in welche Abteilung es sozusagen geht und in welchen Unterprozess, also eher Abteilung, glaube ich, genau.
+
+Wir haben es hier schon allgemein benannt.
+
+Das habe ich von vorher auch so übernommen.
+
+Diese Projektleitung ist überhaupt nicht abteilungszugeordnet.
+
+Diese eine Swimline.
+
+Okay, und das geht?
+
+Das war vorher auch so.
+
+Das haben wir übernommen und ich finde es eigentlich auch ganz treffend.
+
+Das heißt, das ist hier schon gar nicht mehr definiert.
+
+Ja.
+
+Und dadurch sind wir hier auch noch recht frei.
+
+Und wir können in den Kästen
+
+Also man würde ja jetzt in diesem gegebenenfalls Projektplan erstellen, könnten wir verschiedene Dokumente erwähnen, hinterlegen. Da wäre dann der für F&E-Projekte, der für PM-Projekte, der für Marketing-Projekte und der für BD-Projekte drin.
+
+Ja, genau. Also theoretisch kann man das auch noch präzisieren. Ich habe es jetzt in den allgemeinen Prozess gar nicht, das Dokument selbst mit aufgenommen, zumindest in der Weiterleitung jetzt an die QS, beziehungsweise genau genommen, ich sitze heute Nachmittag nochmal mit Henning und Monika zusammen.
+
+Wir hatten ja schon darüber gesprochen, Martin, um das zu überführen. Die E-Mail-Adresse sind auch schon angelegt, wo die ganzen Informationen ankommen sollen. Das heißt, ich warte jetzt erstmal deren Feedback ab. So wie es aussieht, hat Henning da noch ein, zwei Punkte.
+
+Aber im Großen und Ganzen sind die meisten Kriterien
+
+und die meisten Änderungen am Prozess ja auch hier vorne gewesen.
+
+Eben das BD mit aufnehmen.
+
+Und hier würde ich es auch eben genau aus den Gründen
+
+die Giovanna angesprochen hat, relativ offen lassen.
+
+Weil es auch, wie Björn sagt, es ist so viele verschiedene Sichtweisen.
+
+Also wir können dafür jedes Szenario ein Dokument hinterlegen

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_03.txt

@@ -0,0 +1,169 @@
+aber dann würde ich die Frage in Raum,
+
+werfen, ob uns das wirklich weiterhilft dann in dem Fall. Oder ob das jetzt Arbeit ist, wo man sagen kann, okay, wir sitzen hier die nächsten Monate eh zusammen, alle zwei Wochen und hören uns diese unterschiedlichen Art und Weisen von Projekten an und wie sie abgearbeitet werden und nehmen das dann vielleicht nochmal im Einfluss um einen halben Jahr, wenn wir mehr wissen, da nochmal Änderungen dran vorzunehmen, wenn wir merken, okay, hier passt was nicht, da passt was nicht.
+
+Je nachdem, wie ihr das seht. Das ist jetzt nur so ein Gedankengang.
+
+Man kann der Tatsache, dass ich so ein Dokumentar entnehmen, dass ich da Wert drauf lege. Aber das grenzt sich ja dann nach den Abteilungen auf. Das muss dann jeder selber entscheiden.
+
+Ich kann nur aus der Erfahrung, das vielleicht einfach mal so hier, ob er erzählt vom Krieg, aus der Erfahrung kann ich sagen, diese Variante mit das in einer PowerPoint zu machen, mit ein paar Fragen vorne oder mit ein paar Stichpunkten vorneweg, das können und ein paar vorgegebenen Folien,
+
+hat sich im letzten Jahr als wirklich sehr gut funktionierend und im Arbeitsalltag wertvoll erwiesen,
+
+weil man damit zum einen so ein bisschen klarstellt, worum geht es hier eigentlich
+
+und was habe ich sozusagen als Grundlagen festgelegt.
+
+Und das Zweite ist dadurch, es ist die Hürde, das zu pflegen, ist relativ gering,
+
+weil man einfach immer hinten, wenn man was gemacht hat, eine Folie anhängt oder zwei oder drei.
+
+Und man hat dann sozusagen fortlaufend eine Chronologie bzw. ein aktuelles Dokument, was man im Fall der Fälle einfach vorziehen kann.
+
+Wenn du in so einer Runde sitzt und dann sagt man, was ist eigentlich der Stand vom Projekt XY, dann machst du dieses Ding auf.
+
+Alle können nochmal gucken, was die Ausgangsbedingungen waren und alle sehen, was der aktuelle Stand gerade ist.
+
+Und das kann man natürlich mit mehr und weniger Aufwand betreiben, je nachdem, wie das Projekt halt so was das hergibt.
+
+Es gibt sicherlich Projekte bei uns, wo nur drei Folien hinten dran hängen und es gibt Projekte, wo 30 hinten dran hängen.
+
+Das Dokument selbst ist auch weiterhin drin. Ich meinte jetzt nur, dass man wirklich sagt, okay, macht man davon eine BD-spezifische, eine PM-spezifische Version oder wie und so weiter und sagt man einfach, okay, wir behalten diesen Rahmen und machen dann eben ein, zwei Folien dazu oder ein, zwei Folien weg. Also ich denke, das ist einfach die einfachere, schnellere.
+
+Das entscheidet letztendlich jeder, also das würde ich jeder Abteilung oder jeder Bearbeitungsschiene überlassen, wie die das machen. Man sieht ja schon, Giovanna hat da ganz andere Ansprüche als ich und Björn hat vielleicht andere und der möchte überhaupt gar nicht mit PowerPoint arbeiten, weil er irgendein Tool hat, wo das so drin läuft und Softwareentwicklung funktioniert nochmal ganz anders.
+
+Das war ja auch Mentierer, ja.
+
+Vielleicht nur so kurz, so mein Gefühl über die ganze Diskussion,
+
+die wir jetzt momentan hier haben, ist schon wieder so eine ganz starke interne Sicht
+
+und wie das Projekt hier intern zu laufen ist.
+
+Was mir so ein bisschen zählt, und ich glaube, das, was Giovanna ja auch am Anfang
+
+ja auch schon mal ein paar Mal irgendwie angesprochen hat, ist,
+
+bevor es überhaupt ein Projekt gibt, bevor F&E überhaupt drüber nachdenkt,
+
+bevor das irgendwie, was ich bei Lars oder seiner Truppe da irgendwo landet,
+
+müssen wir im Vorfeld ja ganz andere Kriterien erstmal abhändeln.
+
+Und das war so ein bisschen dieser Grundgedanke, wo wir überhaupt gucken, gibt es da überhaupt einen Markt? Gibt es dort irgendwelche anderen Zulassungen, technische Hörungen? Wie sieht die Wettbewerbssituation aus? Wie sehen politische, wirtschaftliche Risiken aus? All sowas. Weil ich sag mal, davor brauchte ich alle noch gar nicht arbeiten. Das sag ich mal ganz doof. Solange die Sachen nicht geklärt sind, brauchen wir noch gar nicht loslegen. Also nicht bei dir, Martin, noch gar nichts auf dem Tisch.
+
+So ist es jetzt aufgebaut.
+
+Ja, nein, wenn nein, fordern die die wieder ein.
+
+Und dann kommt die von der Ideenliste, von dem Ideenpool überhaupt erst in diese Projektliste.
+
+Und diese Projektliste wird bei uns erst diskutiert.
+
+Das heißt, dieses vorher Abfragen von Informationen, das findet statt und das findet auch nicht bei uns statt.
+
+Kannst du die andere aufhören, aber die habe ich jetzt gar nicht vor Augen, wenn du meinst.
+
+Also die Frage, die sich dabei stellt, ist natürlich, ja, du meintest recht.
+
+Das ist prinzipiell, ist das da abgefragt, also Filterkriterien.
+
+Und da kann man ja jetzt eine lange Liste machen.
+
+Strategiekonformität, Nutzen, Wettbewerbssituation, Hürden, jeder Art und, und, und.
+
+Und das kann eben auch unterschiedlich sein für Entwicklung eines physischen Produktes,
+
+eines digitalen Produktes, eines Marktes, eines Absatzsegments, eines Anwendungsfalls.
+
+Die Frage wird allerdings sein, das ist glaube ich das, was dann auch Jörn und Giovanna vielleicht in Frage stellen würden, ist das in den Händen von David und James vom Grundsatz her, ist das in der F&E-Abteilung irgendwie richtig aufgehängt?
+
+Kurzer Einspruch an der Stelle.
+
+Nur als Frage, ne?
+
+Ich will das entkräften sozusagen. Wir brauchten, irgendjemand muss das ja initial annehmen. Also irgendjemand muss einmal drauf gucken, was ist es. Eine legitime Option ist, die wird kommen, wenn die Person, egal wer das ist, der das bekommt, nicht entscheiden kann, wie das weitergeht, muss er sich Hilfe suchen.
+
+Und genauso gut können wir auch sagen, wenn dort in der, ganz am Anfang, wenn da rauskommt, das ist ganz klar ein Marketingprojekt. Also das ist ganz klar erkennbar als Marketing. Dann nennt Björn jemanden, an dem das direkt weitergeht für eben genau diese Bewertung.
+
+oder wenn es ein Business Development Projekt ist, ganz klar, dann geht es, keine Ahnung, bei Giovanna irgendwo rein.
+
+Ich meine, sie selbst hat ja vermutlich Kenntnis davon, es kommt ja aus ihrer Abteilung oder es kommt halt wirklich von ganz außen von Dritten,
+
+dann würde man sie auch sowieso zur Kenntnis geben. Also, irgendjemand in Person muss ja diesen Vorfilter machen,
+
+Erst mal die Informationen anreichern und nicht mehr sollen die machen. Die kriegen sozusagen eine überschaubare Liste an Minimalanforderungen, die so eine Idee haben muss, um überhaupt bearbeitet werden zu können. Und die Aufgabe der beiden, und da haben wir jetzt einfach einen Würfel geschmissen, wer das macht, ist dann nochmal anzurufen und zu sagen, hier, Raik, du hast hier zwar eine Idee geschrieben, aber ich brauche nochmal dieses, jenes und welches, damit wir überhaupt weitermachen können.
+
+Und ob das dann direkt abbiegt ins Marketing, direkt abbiegt ins BDE, direkt abbiegt in EDD und dann da nochmal unterbar, aber das ist schlicht nicht, also das gehört dann zum Prozess. Das passiert ja dann auch.
+
+Und man kann sicherlich, und das sollten wir tun, diese ersten Abfragen, da sollte aus jeder Abteilung, sag ich mal wirklich die Basisabfrage, die auch jemand, der im Zweifelsfall in diesem Spezialgebiet nicht fähig ist oder nicht ausgebildet ist, zumindest abfragen kann.
+
+Also wenn es irgendwie nach einem BD-Projekt riecht, dann muss es sozusagen wie an einer Hotline es einen Fork geben. Okay, dann frage ich noch ab, typische drei bis vier typische BD-Sachen. Wenn es ein F&E ist, frage ich drei bis vier typische F&E-Sachen ab und so weiter und so fort.
+
+Das sehe ich da drin.
+
+Also den Prozess.
+
+Von meinem Verständnis her.
+
+Also nur von einer, wie gesagt,
+
+wenn ich das höre, BD-Projekt,
+
+Marketing-Projekt oder sonstiges, gibt es ja eigentlich gar nicht.
+
+Wir sind ja nur diejenigen, die
+
+an diesem Projekt zuarbeiten
+
+oder was machen.
+
+Und letztendlich die Entscheidung,
+
+und das ist ja glaube ich das, wo sich bei mir
+
+vielleicht auch nur eine Überschrift
+
+stößt, letztendlich ist es ja alles,
+
+irgendwie ist es ja kein F&E-Projekt,
+
+sondern es ist an und für sich von der Begrifflichkeit her,
+
+geht es ja mehr Richtung Business Development als im Bereich F&E,
+
+weil dort, ich sage mal, auch jetzt wieder nur in Überschrift gesagt,
+
+da natürlich Techniker darüber entscheiden.
+
+Das ist ja an deren Aufgabe.
+
+Und dementsprechend sehe ich die Aufgabe mehr im kaufmännischen Bereich,
+
+das im Vorfeld alles zu machen,
+
+dann später die Umsetzung oder wie es gemacht wird.
+
+Dann kommt dann irgendwann der Techniker mit dabei und so weiter.
+
+Also nur vom Verständnis her.
+
+Nochmal, wir brauchen irgendjemanden,
+
+die E-Mail-Adresse liest und das überhaupt macht.
+
+Und du weißt vorher noch nicht, die andere Alternative wäre,
+
+wir hätten sozusagen eine E-Mail-Adresse für jedes Fachgebiet einer Idee.
+
+Dann könntest du das weglassen.
+
+Die entscheiden überhaupt gar nicht, also die entscheiden nur die ganz krassen Fälle.
+
+Da kommt eine E-Mail rein mit einer Idee, die heißt, keine Ahnung,
+
+wir wollen demnächst Putzlappen machen.
+
+Da können die auch schon sagen, aus verschiedenen Gründen,
+
+das werden wir nicht machen. So, Punkt.

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_03_changes.json

@@ -0,0 +1,220 @@
+{
+  "source_file": "chunk_03.txt",
+  "output_file": "chunk_03_normalized.txt",
+  "blocks_total": 85,
+  "blocks_changed": 27,
+  "policy": {
+    "removed": [
+      "isolated filler sounds such as äh, ähm, hm, mhm",
+      "immediate duplicate words",
+      "immediate duplicate phrases of two to four words",
+      "redundant whitespace"
+    ],
+    "explicitly_preserved": [
+      "negations",
+      "modal words and qualifiers",
+      "dates, times, numbers and quantities",
+      "technical statements",
+      "responsibilities",
+      "deadlines",
+      "decisions and commitments"
+    ],
+    "principle": "When uncertain, leave the text unchanged."
+  },
+  "changes": [
+    {
+      "block_number": 1,
+      "original": "aber dann würde ich die Frage in Raum,",
+      "normalized": "aber dann würde ich die Frage in Raum",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 5,
+      "original": "Ich kann nur aus der Erfahrung, das vielleicht einfach mal so hier, ob er erzählt vom Krieg, aus der Erfahrung kann ich sagen, diese Variante mit das in einer PowerPoint zu machen, mit ein paar Fragen vorne oder mit ein paar Stichpunkten vorneweg, das können und ein paar vorgegebenen Folien,",
+      "normalized": "Ich kann nur aus der Erfahrung, das vielleicht einfach mal so hier, ob er erzählt vom Krieg, aus der Erfahrung kann ich sagen, diese Variante mit das in einer PowerPoint zu machen, mit ein paar Fragen vorne oder mit ein paar Stichpunkten vorneweg, das können und ein paar vorgegebenen Folien",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 6,
+      "original": "hat sich im letzten Jahr als wirklich sehr gut funktionierend und im Arbeitsalltag wertvoll erwiesen,",
+      "normalized": "hat sich im letzten Jahr als wirklich sehr gut funktionierend und im Arbeitsalltag wertvoll erwiesen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 9,
+      "original": "Und das Zweite ist dadurch, es ist die Hürde, das zu pflegen, ist relativ gering,",
+      "normalized": "Und das Zweite ist dadurch, es ist die Hürde, das zu pflegen, ist relativ gering",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 19,
+      "original": "Vielleicht nur so kurz, so mein Gefühl über die ganze Diskussion,",
+      "normalized": "Vielleicht nur so kurz, so mein Gefühl über die ganze Diskussion",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 23,
+      "original": "ja auch schon mal ein paar Mal irgendwie angesprochen hat, ist,",
+      "normalized": "ja auch schon mal ein paar Mal irgendwie angesprochen hat, ist",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 24,
+      "original": "bevor es überhaupt ein Projekt gibt, bevor F&E überhaupt drüber nachdenkt,",
+      "normalized": "bevor es überhaupt ein Projekt gibt, bevor F&E überhaupt drüber nachdenkt",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 25,
+      "original": "bevor das irgendwie, was ich bei Lars oder seiner Truppe da irgendwo landet,",
+      "normalized": "bevor das irgendwie, was ich bei Lars oder seiner Truppe da irgendwo landet",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 29,
+      "original": "Ja, nein, wenn nein, fordern die die wieder ein.",
+      "normalized": "Ja, nein, wenn nein, fordern die wieder ein.",
+      "removed_fillers": [],
+      "duplicate_reductions": [
+        "die die"
+      ]
+    },
+    {
+      "block_number": 37,
+      "original": "Strategiekonformität, Nutzen, Wettbewerbssituation, Hürden, jeder Art und, und, und.",
+      "normalized": "Strategiekonformität, Nutzen, Wettbewerbssituation, Hürden, jeder Art und.",
+      "removed_fillers": [],
+      "duplicate_reductions": [
+        "und, und",
+        "und, und"
+      ]
+    },
+    {
+      "block_number": 38,
+      "original": "Und das kann eben auch unterschiedlich sein für Entwicklung eines physischen Produktes,",
+      "normalized": "Und das kann eben auch unterschiedlich sein für Entwicklung eines physischen Produktes",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 46,
+      "original": "Ich meine, sie selbst hat ja vermutlich Kenntnis davon, es kommt ja aus ihrer Abteilung oder es kommt halt wirklich von ganz außen von Dritten,",
+      "normalized": "Ich meine, sie selbst hat ja vermutlich Kenntnis davon, es kommt ja aus ihrer Abteilung oder es kommt halt wirklich von ganz außen von Dritten",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 47,
+      "original": "dann würde man sie auch sowieso zur Kenntnis geben. Also, irgendjemand in Person muss ja diesen Vorfilter machen,",
+      "normalized": "dann würde man sie auch sowieso zur Kenntnis geben. Also, irgendjemand in Person muss ja diesen Vorfilter machen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 55,
+      "original": "Also nur von einer, wie gesagt,",
+      "normalized": "Also nur von einer, wie gesagt",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 56,
+      "original": "wenn ich das höre, BD-Projekt,",
+      "normalized": "wenn ich das höre, BD-Projekt",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 61,
+      "original": "Und letztendlich die Entscheidung,",
+      "normalized": "Und letztendlich die Entscheidung",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 64,
+      "original": "stößt, letztendlich ist es ja alles,",
+      "normalized": "stößt, letztendlich ist es ja alles",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 65,
+      "original": "irgendwie ist es ja kein F&E-Projekt,",
+      "normalized": "irgendwie ist es ja kein F&E-Projekt",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 66,
+      "original": "sondern es ist an und für sich von der Begrifflichkeit her,",
+      "normalized": "sondern es ist an und für sich von der Begrifflichkeit her",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 67,
+      "original": "geht es ja mehr Richtung Business Development als im Bereich F&E,",
+      "normalized": "geht es ja mehr Richtung Business Development als im Bereich F&E",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 68,
+      "original": "weil dort, ich sage mal, auch jetzt wieder nur in Überschrift gesagt,",
+      "normalized": "weil dort, ich sage mal, auch jetzt wieder nur in Überschrift gesagt",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 71,
+      "original": "Und dementsprechend sehe ich die Aufgabe mehr im kaufmännischen Bereich,",
+      "normalized": "Und dementsprechend sehe ich die Aufgabe mehr im kaufmännischen Bereich",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 72,
+      "original": "das im Vorfeld alles zu machen,",
+      "normalized": "das im Vorfeld alles zu machen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 76,
+      "original": "Nochmal, wir brauchen irgendjemanden,",
+      "normalized": "Nochmal, wir brauchen irgendjemanden",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 78,
+      "original": "Und du weißt vorher noch nicht, die andere Alternative wäre,",
+      "normalized": "Und du weißt vorher noch nicht, die andere Alternative wäre",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 82,
+      "original": "Da kommt eine E-Mail rein mit einer Idee, die heißt, keine Ahnung,",
+      "normalized": "Da kommt eine E-Mail rein mit einer Idee, die heißt, keine Ahnung",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 84,
+      "original": "Da können die auch schon sagen, aus verschiedenen Gründen,",
+      "normalized": "Da können die auch schon sagen, aus verschiedenen Gründen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    }
+  ]
+}

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_03_normalized.txt

@@ -0,0 +1,169 @@
+aber dann würde ich die Frage in Raum
+
+werfen, ob uns das wirklich weiterhilft dann in dem Fall. Oder ob das jetzt Arbeit ist, wo man sagen kann, okay, wir sitzen hier die nächsten Monate eh zusammen, alle zwei Wochen und hören uns diese unterschiedlichen Art und Weisen von Projekten an und wie sie abgearbeitet werden und nehmen das dann vielleicht nochmal im Einfluss um einen halben Jahr, wenn wir mehr wissen, da nochmal Änderungen dran vorzunehmen, wenn wir merken, okay, hier passt was nicht, da passt was nicht.
+
+Je nachdem, wie ihr das seht. Das ist jetzt nur so ein Gedankengang.
+
+Man kann der Tatsache, dass ich so ein Dokumentar entnehmen, dass ich da Wert drauf lege. Aber das grenzt sich ja dann nach den Abteilungen auf. Das muss dann jeder selber entscheiden.
+
+Ich kann nur aus der Erfahrung, das vielleicht einfach mal so hier, ob er erzählt vom Krieg, aus der Erfahrung kann ich sagen, diese Variante mit das in einer PowerPoint zu machen, mit ein paar Fragen vorne oder mit ein paar Stichpunkten vorneweg, das können und ein paar vorgegebenen Folien
+
+hat sich im letzten Jahr als wirklich sehr gut funktionierend und im Arbeitsalltag wertvoll erwiesen
+
+weil man damit zum einen so ein bisschen klarstellt, worum geht es hier eigentlich
+
+und was habe ich sozusagen als Grundlagen festgelegt.
+
+Und das Zweite ist dadurch, es ist die Hürde, das zu pflegen, ist relativ gering
+
+weil man einfach immer hinten, wenn man was gemacht hat, eine Folie anhängt oder zwei oder drei.
+
+Und man hat dann sozusagen fortlaufend eine Chronologie bzw. ein aktuelles Dokument, was man im Fall der Fälle einfach vorziehen kann.
+
+Wenn du in so einer Runde sitzt und dann sagt man, was ist eigentlich der Stand vom Projekt XY, dann machst du dieses Ding auf.
+
+Alle können nochmal gucken, was die Ausgangsbedingungen waren und alle sehen, was der aktuelle Stand gerade ist.
+
+Und das kann man natürlich mit mehr und weniger Aufwand betreiben, je nachdem, wie das Projekt halt so was das hergibt.
+
+Es gibt sicherlich Projekte bei uns, wo nur drei Folien hinten dran hängen und es gibt Projekte, wo 30 hinten dran hängen.
+
+Das Dokument selbst ist auch weiterhin drin. Ich meinte jetzt nur, dass man wirklich sagt, okay, macht man davon eine BD-spezifische, eine PM-spezifische Version oder wie und so weiter und sagt man einfach, okay, wir behalten diesen Rahmen und machen dann eben ein, zwei Folien dazu oder ein, zwei Folien weg. Also ich denke, das ist einfach die einfachere, schnellere.
+
+Das entscheidet letztendlich jeder, also das würde ich jeder Abteilung oder jeder Bearbeitungsschiene überlassen, wie die das machen. Man sieht ja schon, Giovanna hat da ganz andere Ansprüche als ich und Björn hat vielleicht andere und der möchte überhaupt gar nicht mit PowerPoint arbeiten, weil er irgendein Tool hat, wo das so drin läuft und Softwareentwicklung funktioniert nochmal ganz anders.
+
+Das war ja auch Mentierer, ja.
+
+Vielleicht nur so kurz, so mein Gefühl über die ganze Diskussion
+
+die wir jetzt momentan hier haben, ist schon wieder so eine ganz starke interne Sicht
+
+und wie das Projekt hier intern zu laufen ist.
+
+Was mir so ein bisschen zählt, und ich glaube, das, was Giovanna ja auch am Anfang
+
+ja auch schon mal ein paar Mal irgendwie angesprochen hat, ist
+
+bevor es überhaupt ein Projekt gibt, bevor F&E überhaupt drüber nachdenkt
+
+bevor das irgendwie, was ich bei Lars oder seiner Truppe da irgendwo landet
+
+müssen wir im Vorfeld ja ganz andere Kriterien erstmal abhändeln.
+
+Und das war so ein bisschen dieser Grundgedanke, wo wir überhaupt gucken, gibt es da überhaupt einen Markt? Gibt es dort irgendwelche anderen Zulassungen, technische Hörungen? Wie sieht die Wettbewerbssituation aus? Wie sehen politische, wirtschaftliche Risiken aus? All sowas. Weil ich sag mal, davor brauchte ich alle noch gar nicht arbeiten. Das sag ich mal ganz doof. Solange die Sachen nicht geklärt sind, brauchen wir noch gar nicht loslegen. Also nicht bei dir, Martin, noch gar nichts auf dem Tisch.
+
+So ist es jetzt aufgebaut.
+
+Ja, nein, wenn nein, fordern die wieder ein.
+
+Und dann kommt die von der Ideenliste, von dem Ideenpool überhaupt erst in diese Projektliste.
+
+Und diese Projektliste wird bei uns erst diskutiert.
+
+Das heißt, dieses vorher Abfragen von Informationen, das findet statt und das findet auch nicht bei uns statt.
+
+Kannst du die andere aufhören, aber die habe ich jetzt gar nicht vor Augen, wenn du meinst.
+
+Also die Frage, die sich dabei stellt, ist natürlich, ja, du meintest recht.
+
+Das ist prinzipiell, ist das da abgefragt, also Filterkriterien.
+
+Und da kann man ja jetzt eine lange Liste machen.
+
+Strategiekonformität, Nutzen, Wettbewerbssituation, Hürden, jeder Art und.
+
+Und das kann eben auch unterschiedlich sein für Entwicklung eines physischen Produktes
+
+eines digitalen Produktes, eines Marktes, eines Absatzsegments, eines Anwendungsfalls.
+
+Die Frage wird allerdings sein, das ist glaube ich das, was dann auch Jörn und Giovanna vielleicht in Frage stellen würden, ist das in den Händen von David und James vom Grundsatz her, ist das in der F&E-Abteilung irgendwie richtig aufgehängt?
+
+Kurzer Einspruch an der Stelle.
+
+Nur als Frage, ne?
+
+Ich will das entkräften sozusagen. Wir brauchten, irgendjemand muss das ja initial annehmen. Also irgendjemand muss einmal drauf gucken, was ist es. Eine legitime Option ist, die wird kommen, wenn die Person, egal wer das ist, der das bekommt, nicht entscheiden kann, wie das weitergeht, muss er sich Hilfe suchen.
+
+Und genauso gut können wir auch sagen, wenn dort in der, ganz am Anfang, wenn da rauskommt, das ist ganz klar ein Marketingprojekt. Also das ist ganz klar erkennbar als Marketing. Dann nennt Björn jemanden, an dem das direkt weitergeht für eben genau diese Bewertung.
+
+oder wenn es ein Business Development Projekt ist, ganz klar, dann geht es, keine Ahnung, bei Giovanna irgendwo rein.
+
+Ich meine, sie selbst hat ja vermutlich Kenntnis davon, es kommt ja aus ihrer Abteilung oder es kommt halt wirklich von ganz außen von Dritten
+
+dann würde man sie auch sowieso zur Kenntnis geben. Also, irgendjemand in Person muss ja diesen Vorfilter machen
+
+Erst mal die Informationen anreichern und nicht mehr sollen die machen. Die kriegen sozusagen eine überschaubare Liste an Minimalanforderungen, die so eine Idee haben muss, um überhaupt bearbeitet werden zu können. Und die Aufgabe der beiden, und da haben wir jetzt einfach einen Würfel geschmissen, wer das macht, ist dann nochmal anzurufen und zu sagen, hier, Raik, du hast hier zwar eine Idee geschrieben, aber ich brauche nochmal dieses, jenes und welches, damit wir überhaupt weitermachen können.
+
+Und ob das dann direkt abbiegt ins Marketing, direkt abbiegt ins BDE, direkt abbiegt in EDD und dann da nochmal unterbar, aber das ist schlicht nicht, also das gehört dann zum Prozess. Das passiert ja dann auch.
+
+Und man kann sicherlich, und das sollten wir tun, diese ersten Abfragen, da sollte aus jeder Abteilung, sag ich mal wirklich die Basisabfrage, die auch jemand, der im Zweifelsfall in diesem Spezialgebiet nicht fähig ist oder nicht ausgebildet ist, zumindest abfragen kann.
+
+Also wenn es irgendwie nach einem BD-Projekt riecht, dann muss es sozusagen wie an einer Hotline es einen Fork geben. Okay, dann frage ich noch ab, typische drei bis vier typische BD-Sachen. Wenn es ein F&E ist, frage ich drei bis vier typische F&E-Sachen ab und so weiter und so fort.
+
+Das sehe ich da drin.
+
+Also den Prozess.
+
+Von meinem Verständnis her.
+
+Also nur von einer, wie gesagt
+
+wenn ich das höre, BD-Projekt
+
+Marketing-Projekt oder sonstiges, gibt es ja eigentlich gar nicht.
+
+Wir sind ja nur diejenigen, die
+
+an diesem Projekt zuarbeiten
+
+oder was machen.
+
+Und letztendlich die Entscheidung
+
+und das ist ja glaube ich das, wo sich bei mir
+
+vielleicht auch nur eine Überschrift
+
+stößt, letztendlich ist es ja alles
+
+irgendwie ist es ja kein F&E-Projekt
+
+sondern es ist an und für sich von der Begrifflichkeit her
+
+geht es ja mehr Richtung Business Development als im Bereich F&E
+
+weil dort, ich sage mal, auch jetzt wieder nur in Überschrift gesagt
+
+da natürlich Techniker darüber entscheiden.
+
+Das ist ja an deren Aufgabe.
+
+Und dementsprechend sehe ich die Aufgabe mehr im kaufmännischen Bereich
+
+das im Vorfeld alles zu machen
+
+dann später die Umsetzung oder wie es gemacht wird.
+
+Dann kommt dann irgendwann der Techniker mit dabei und so weiter.
+
+Also nur vom Verständnis her.
+
+Nochmal, wir brauchen irgendjemanden
+
+die E-Mail-Adresse liest und das überhaupt macht.
+
+Und du weißt vorher noch nicht, die andere Alternative wäre
+
+wir hätten sozusagen eine E-Mail-Adresse für jedes Fachgebiet einer Idee.
+
+Dann könntest du das weglassen.
+
+Die entscheiden überhaupt gar nicht, also die entscheiden nur die ganz krassen Fälle.
+
+Da kommt eine E-Mail rein mit einer Idee, die heißt, keine Ahnung
+
+wir wollen demnächst Putzlappen machen.
+
+Da können die auch schon sagen, aus verschiedenen Gründen
+
+das werden wir nicht machen. So, Punkt.

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_04.txt

@@ -0,0 +1,197 @@
+abgelehnt. Fertig.
+
+Kommt nochmal zur Wiedervorlage.
+
+Doch, das ist unsere aktuelle
+
+Unternehmensstrategie. So was machen wir nicht.
+
+Ja, aber die Entscheidung würde ich auch nicht darlegen,
+
+sondern die würde ich halt viel weiter
+
+oben hinlegen in Richtung Business Department, weil wir nicht wissen,
+
+ob wir vielleicht auch noch machen wollen.
+
+Mir geht es einfach nicht
+
+vor der Durchsicht.
+
+Lasst mich doch bitte mal ausreden.
+
+Mir geht es ja nicht darum,
+
+ich stelle ja nur mit der Frage, ob die
+
+E-Mail-Adresse, das muss jemand bearbeiten,
+
+aber ob die bei F&E liegen muss,
+
+Oder halt dann lieber Richtung Business Development gehen müsste.
+
+Das würde ich dann gerne fragen.
+
+Ja, aber letztendlich ist es so, also nochmal kurz zu dem Punkt, dass es in der F&E liegt.
+
+Der Prozess ist ein F&E-Prozess gewesen, einfach historisch.
+
+Und wir haben ja gesagt, wir wollen Verantwortlichkeiten festlegen.
+
+Das heißt, die Prozessverantwortlichkeit hatten wir mit Martin besprochen.
+
+Das war ja das Gespräch von vier Wochen oder so, dass das da liegen bleibt.
+
+Aber dass es danach eben in dieses Gremium extra mit allen zusammen sollen.
+
+Das heißt, auch die Dinge, die dort abgelehnt werden, werden einmal dann hier durchgesprochen werden und dann kann jeder seine Seite darlegen. Also es liegt in dem Sinne von der Bewertung in keiner Abteilung, sondern in diesem Gemeinschaftsgremium der Schnittstellen. BD, Marketing, F&E, Produktmanagement.
+
+Und vielleicht auch, wenn wir jetzt das Wording nochmal gerade ziehen. Abgelehnt und zugelassen ist ja auch das falsche Wort an der Stelle. Es ist lediglich eine Vorsortierung. Also die Person, wo die Idee reinkommt und es wird so sein, wenn überhaupt was kommt, da wird von einer Produktidee bis zum Verbesserungsvorschlag einer Anlage über Business Development Dinge reinkommen.
+
+Und im Zweifelsfall wäre es immer an der verkehrten Stelle. Insofern musst du einfach ziemlich bald, also aus meiner Sicht muss irgendeiner ein Mindestmaß an Informationen anreichern, denn sonst kommt das bei uns an. Und dann kommen genau die Fragen. Wie groß ist eigentlich der Markt? Gibt es da eigentlich was, was offensichtlich dagegen spricht und so weiter und so fort? Ja, und insofern kamen wir dazu, wie es jetzt ist.
+
+Ich kann es hier ja auch nochmal kurz zeigen.
+
+Also, weil man muss ja wirklich bedenken, es kann sein von, wir brauchen eine neue Forke für den Gabelstapler oder einen neuen Aufsatz für den Trecker bis hin zu ein neues Produkt.
+
+Das muss ja alles abgefangen werden.
+
+Das heißt, wir haben erstmal festgelegt, eine neue Idee muss mindestens folgende Punkte beantworten.
+
+Wenn es per Mail kommt, erstmal ein Titel, eine Projektidee und ein Projektziel.
+
+So ein paar Sätze.
+
+Und dann optional, wenn vorhanden, weil ein Marktpotenzial für neue Gabelstapler oder so wird es auch nicht geben, konkrete Aufzählung der zugrunde liegenden Annahmen, zum Beispiel erwartbares Marktvolumen, bekannte Marktteilnehmer, ein, zwei Richtlinien, Gesetze, Vorschriften, die Patentpunkt oder geplante Verwertung der Ergebnisse beispielsweise.
+
+So, und dann kommt diese Mail eben erstmal rein und die muss sich eben einer anschauen. Und die schauen jetzt erstmal im ersten Schritt, A, sind die Informationen alle vorhanden und können dann auch zum Beispiel bei den Optionalen einfach mal sagen, okay, das ist jetzt aber eine Idee, da solltet ihr diese zwei, drei Punkte vielleicht doch beantworten können.
+
+Das werden die dann tun.
+
+Und dann wird erstmal geprüft, ist diese Idee auf Team- oder Abteilungsebene abzuarbeiten.
+
+Also wenn es jetzt einfach nur ist, wir möchten, dass hier jeden Mittwoch vor der und der Anlage XY einmal durchgefegt wird,
+
+weil ich ansonsten mit dem XY nicht machen kann, weiß ich jetzt nicht.
+
+Mir fällt gerade ad hoc kein gutes Beispiel ein.
+
+Dann können die einfach schon mal direkt sagen, okay, das kann ich jetzt an den Fertigungsleiter schicken und dann können die das dort umsetzen.
+
+Und dann kommt das auch bei uns gar nicht auf den Tisch mit der Bitte um die Bearbeitung.
+
+Und dann haben wir diese Abfrage, und das ist jetzt dieser springende Punkt, ist die Idee abteilungsübergreifend, strategisch relevant oder ist ein Budget notwendig?
+
+Und wenn da dann ja ist, dann muss es erst kategorisiert, priorisiert und in die Projektliste überführt werden.
+
+Und dann haben wir so gewisse Kriterien, um diese Ideen eben zuzuordnen, was man da dann machen kann.
+
+So, das ist der Gedanke.
+
+Also ob das jetzt am Schluss eine andere...
+
+Ja, also eigentlich denke ich, passen alle unsere Anmerkungen, die wir bis jetzt hatten, gut da rein.
+
+Zumindest von meiner Meinung. Das ist ja auch immer so ein bisschen persönlich.
+
+Es ist auch so, ich bestehe nicht darauf, dass das bei mir in der Abteilung gemacht wird.
+
+Es war sozusagen, wo ist auch Personal verfügbar, die das überhaupt machen können.
+
+Also Giovanna hat da jetzt nicht gerade hier geschrien mit ihren MitarbeiterInnen.
+
+Ich bin auch dankbar, dass das nicht hier gemacht wird, weil es kann halt wirklich von A bis Z sein und deine Jungs sind halt in alle Bereiche gut vernetzt auch. Das darf man ja auch nicht vergessen.
+
+Und vielleicht muss man es auch nochmal so ein bisschen formulieren. Es sind natürlich nicht Business Development, wobei Business Development besteht darauf, dass es eigene Projekte sind, aber es wird immer, das zeigt ja auch die Erfahrung von meinen Entwicklungsprojekten, da sind ja immer andere Abteilungen involviert.
+
+Also insofern gibt es dann welche, die ein bisschen mehr in die Richtung kippen, ein bisschen mehr in die kippen und das auch über den Projektverlauf noch sich ändert.
+
+Was mir halt wichtig ist, unabhängig wie das Projektmanagement danach, nach der Liste aussieht, dass es halt einen Reporting-Zyklus gibt. Dass man hier halt abgedatet wird und dass das, und deswegen ist dein Dokument eben auch gut, in irgendeiner Form da abgelehnt wird.
+
+So, und dann sollte man sich einfach darauf einigen,
+
+dass diese zwei, drei Folien immer gemacht werden.
+
+Und wenn man was nicht hat, dann hat man was nicht.
+
+Und wenn man mehr braucht, dann macht man das halt mit hinten dran.
+
+Aber es muss halt dokumentiert sein, weil darum ging es ja letztendlich.
+
+Das war die Idee dahinter, dass diese Projektinformationen
+
+allen zur Verfügung liegen, schnittstellenübergreifend.
+
+Deswegen haben wir das überhaupt erst angefasst.
+
+Lars haben wir jetzt irgendwie verloren.
+
+Lars haben wir verloren.
+
+Nein, die Verbindung ist ja in einem Büro oder zu Hause.
+
+Da ist ein Büro.
+
+Das hat mir aufgefallen,
+
+in den letzten Tagen zum Teil die Verbindung,
+
+die hast du auch bei Lars gesehen,
+
+die Sprache kommt erst hinterher.
+
+Die Verbindung ist manchmal so grottenschlecht.
+
+Und jetzt haben wir über ein Handy.
+
+Ja, ich muss über das Handy reingehen.
+
+Mein Rechner schmiert gerade total ab.
+
+Ich hatte natürlich alles schwarz,
+
+komplett beide Bildschirme, dann nur noch euch.
+
+Ich fahre jetzt einfach
+
+einmal rauf und runter und so lange
+
+bin ich hier so dabei.
+
+Reparatur und hervorstart.
+
+Ja, genau.
+
+Das hilft.
+
+Aber momentan
+
+ist das Netzwerk bei Gemeinden gröntelangsam.
+
+Wenn ich jetzt auf dem
+
+Internet-Datei runterlade, die 17 MB
+
+ist, das ist wie zu
+
+ISDN-Zeiten.
+
+Im internen Netzwerk.
+
+Ja, ich habe auch mein Gefühl.
+
+Ja gut, ich habe von daher eben eure Diskussion nicht vollständig mitgekriegt.
+
+Also im Wesentlichen, die personelle Entscheidung, dass das jetzt bei mir in der F&E gelandet ist, war einfach nur eine Verfügbarkeitsentscheidung von Personen, die halbwegs in der Lage sind, das abzuarbeiten.
+
+Ich bestehe da keinesfalls drauf. Wenn das irgendjemand anders übernehmen will, diese Vorsortierung und das Abfragen der Minimaldaten, gerne. Also überhaupt gar kein Problem.
+
+Ich bin nur, also Malte und ich kann man glaube ich sagen, wir sind der Meinung, es ist fast egal, wer das macht. An dieser Stelle, also an dieser wirklich allerersten Stelle, wo irgendwas reinkommt, die Erfahrung sagt einfach, da kommt in aller Regel nicht ein vollständiger Satz an Informationen rein, mit dem sich hochbezahlte Leute dann schon entscheidend befassen können, sondern da fehlen immer Sachen.
+
+Und dieses Mindestmaß muss von irgendjemandem einfach aufgefüllt werden nach Möglichkeit. Und wenn die noch einen Kategorisierungsvorschlag machen, umso besser. Und ob der dann bestehen bleibt oder nicht, das sehen wir dann bei uns.
+
+Also grundsätzlich, das hatte ich vorhin, ich würde ja das versuchen ein bisschen zusammenzufassen, was wir hier gerade so besprochen haben, habe ich in die Mail vorhin eben schon reingeschrieben, könnte das ja auch zum Beispiel im Sekretariat der Geschäftsführung angesiedelt sein oder irgendwo anders im kaufmännischen Bereich.
+
+Es spielt tatsächlich keine entscheidende Rolle, weil am Ende des Tages muss sowieso nach sehr kurzer Zeit entschieden werden, in welche Fachabteilung gehört das, welche Kompetenzen müssen hinzugezogen werden, eingebunden werden und diskutiert werden.
+
+Und es kann sein, dass F und E dann daran überhaupt nicht beteiligt ist.

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_04_changes.json

@@ -0,0 +1,121 @@
+{
+  "source_file": "chunk_04.txt",
+  "output_file": "chunk_04_normalized.txt",
+  "blocks_total": 99,
+  "blocks_changed": 13,
+  "policy": {
+    "removed": [
+      "isolated filler sounds such as äh, ähm, hm, mhm",
+      "immediate duplicate words",
+      "immediate duplicate phrases of two to four words",
+      "redundant whitespace"
+    ],
+    "explicitly_preserved": [
+      "negations",
+      "modal words and qualifiers",
+      "dates, times, numbers and quantities",
+      "technical statements",
+      "responsibilities",
+      "deadlines",
+      "decisions and commitments"
+    ],
+    "principle": "When uncertain, leave the text unchanged."
+  },
+  "changes": [
+    {
+      "block_number": 5,
+      "original": "Ja, aber die Entscheidung würde ich auch nicht darlegen,",
+      "normalized": "Ja, aber die Entscheidung würde ich auch nicht darlegen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 7,
+      "original": "oben hinlegen in Richtung Business Department, weil wir nicht wissen,",
+      "normalized": "oben hinlegen in Richtung Business Department, weil wir nicht wissen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 12,
+      "original": "Mir geht es ja nicht darum,",
+      "normalized": "Mir geht es ja nicht darum",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 14,
+      "original": "E-Mail-Adresse, das muss jemand bearbeiten,",
+      "normalized": "E-Mail-Adresse, das muss jemand bearbeiten",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 15,
+      "original": "aber ob die bei F&E liegen muss,",
+      "normalized": "aber ob die bei F&E liegen muss",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 24,
+      "original": "Das heißt, auch die Dinge, die dort abgelehnt werden, werden einmal dann hier durchgesprochen werden und dann kann jeder seine Seite darlegen. Also es liegt in dem Sinne von der Bewertung in keiner Abteilung, sondern in diesem Gemeinschaftsgremium der Schnittstellen. BD, Marketing, F&E, Produktmanagement.",
+      "normalized": "Das heißt, auch die Dinge, die dort abgelehnt werden einmal dann hier durchgesprochen werden und dann kann jeder seine Seite darlegen. Also es liegt in dem Sinne von der Bewertung in keiner Abteilung, sondern in diesem Gemeinschaftsgremium der Schnittstellen. BD, Marketing, F&E, Produktmanagement.",
+      "removed_fillers": [],
+      "duplicate_reductions": [
+        "werden, werden"
+      ]
+    },
+    {
+      "block_number": 26,
+      "original": "Und im Zweifelsfall wäre es immer an der verkehrten Stelle. Insofern musst du einfach ziemlich bald, also aus meiner Sicht muss irgendeiner ein Mindestmaß an Informationen anreichern, denn sonst kommt das bei uns an. Und dann kommen genau die Fragen. Wie groß ist eigentlich der Markt? Gibt es da eigentlich was, was offensichtlich dagegen spricht und so weiter und so fort? Ja, und insofern kamen wir dazu, wie es jetzt ist.",
+      "normalized": "Und im Zweifelsfall wäre es immer an der verkehrten Stelle. Insofern musst du einfach ziemlich bald, also aus meiner Sicht muss irgendeiner ein Mindestmaß an Informationen anreichern, denn sonst kommt das bei uns an. Und dann kommen genau die Fragen. Wie groß ist eigentlich der Markt? Gibt es da eigentlich was offensichtlich dagegen spricht und so weiter und so fort? Ja, und insofern kamen wir dazu, wie es jetzt ist.",
+      "removed_fillers": [],
+      "duplicate_reductions": [
+        "was, was"
+      ]
+    },
+    {
+      "block_number": 37,
+      "original": "Also wenn es jetzt einfach nur ist, wir möchten, dass hier jeden Mittwoch vor der und der Anlage XY einmal durchgefegt wird,",
+      "normalized": "Also wenn es jetzt einfach nur ist, wir möchten, dass hier jeden Mittwoch vor der und der Anlage XY einmal durchgefegt wird",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 56,
+      "original": "So, und dann sollte man sich einfach darauf einigen,",
+      "normalized": "So, und dann sollte man sich einfach darauf einigen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 68,
+      "original": "Das hat mir aufgefallen,",
+      "normalized": "Das hat mir aufgefallen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 69,
+      "original": "in den letzten Tagen zum Teil die Verbindung,",
+      "normalized": "in den letzten Tagen zum Teil die Verbindung",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 70,
+      "original": "die hast du auch bei Lars gesehen,",
+      "normalized": "die hast du auch bei Lars gesehen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 76,
+      "original": "Ich hatte natürlich alles schwarz,",
+      "normalized": "Ich hatte natürlich alles schwarz",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    }
+  ]
+}

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_04_normalized.txt

@@ -0,0 +1,197 @@
+abgelehnt. Fertig.
+
+Kommt nochmal zur Wiedervorlage.
+
+Doch, das ist unsere aktuelle
+
+Unternehmensstrategie. So was machen wir nicht.
+
+Ja, aber die Entscheidung würde ich auch nicht darlegen
+
+sondern die würde ich halt viel weiter
+
+oben hinlegen in Richtung Business Department, weil wir nicht wissen
+
+ob wir vielleicht auch noch machen wollen.
+
+Mir geht es einfach nicht
+
+vor der Durchsicht.
+
+Lasst mich doch bitte mal ausreden.
+
+Mir geht es ja nicht darum
+
+ich stelle ja nur mit der Frage, ob die
+
+E-Mail-Adresse, das muss jemand bearbeiten
+
+aber ob die bei F&E liegen muss
+
+Oder halt dann lieber Richtung Business Development gehen müsste.
+
+Das würde ich dann gerne fragen.
+
+Ja, aber letztendlich ist es so, also nochmal kurz zu dem Punkt, dass es in der F&E liegt.
+
+Der Prozess ist ein F&E-Prozess gewesen, einfach historisch.
+
+Und wir haben ja gesagt, wir wollen Verantwortlichkeiten festlegen.
+
+Das heißt, die Prozessverantwortlichkeit hatten wir mit Martin besprochen.
+
+Das war ja das Gespräch von vier Wochen oder so, dass das da liegen bleibt.
+
+Aber dass es danach eben in dieses Gremium extra mit allen zusammen sollen.
+
+Das heißt, auch die Dinge, die dort abgelehnt werden einmal dann hier durchgesprochen werden und dann kann jeder seine Seite darlegen. Also es liegt in dem Sinne von der Bewertung in keiner Abteilung, sondern in diesem Gemeinschaftsgremium der Schnittstellen. BD, Marketing, F&E, Produktmanagement.
+
+Und vielleicht auch, wenn wir jetzt das Wording nochmal gerade ziehen. Abgelehnt und zugelassen ist ja auch das falsche Wort an der Stelle. Es ist lediglich eine Vorsortierung. Also die Person, wo die Idee reinkommt und es wird so sein, wenn überhaupt was kommt, da wird von einer Produktidee bis zum Verbesserungsvorschlag einer Anlage über Business Development Dinge reinkommen.
+
+Und im Zweifelsfall wäre es immer an der verkehrten Stelle. Insofern musst du einfach ziemlich bald, also aus meiner Sicht muss irgendeiner ein Mindestmaß an Informationen anreichern, denn sonst kommt das bei uns an. Und dann kommen genau die Fragen. Wie groß ist eigentlich der Markt? Gibt es da eigentlich was offensichtlich dagegen spricht und so weiter und so fort? Ja, und insofern kamen wir dazu, wie es jetzt ist.
+
+Ich kann es hier ja auch nochmal kurz zeigen.
+
+Also, weil man muss ja wirklich bedenken, es kann sein von, wir brauchen eine neue Forke für den Gabelstapler oder einen neuen Aufsatz für den Trecker bis hin zu ein neues Produkt.
+
+Das muss ja alles abgefangen werden.
+
+Das heißt, wir haben erstmal festgelegt, eine neue Idee muss mindestens folgende Punkte beantworten.
+
+Wenn es per Mail kommt, erstmal ein Titel, eine Projektidee und ein Projektziel.
+
+So ein paar Sätze.
+
+Und dann optional, wenn vorhanden, weil ein Marktpotenzial für neue Gabelstapler oder so wird es auch nicht geben, konkrete Aufzählung der zugrunde liegenden Annahmen, zum Beispiel erwartbares Marktvolumen, bekannte Marktteilnehmer, ein, zwei Richtlinien, Gesetze, Vorschriften, die Patentpunkt oder geplante Verwertung der Ergebnisse beispielsweise.
+
+So, und dann kommt diese Mail eben erstmal rein und die muss sich eben einer anschauen. Und die schauen jetzt erstmal im ersten Schritt, A, sind die Informationen alle vorhanden und können dann auch zum Beispiel bei den Optionalen einfach mal sagen, okay, das ist jetzt aber eine Idee, da solltet ihr diese zwei, drei Punkte vielleicht doch beantworten können.
+
+Das werden die dann tun.
+
+Und dann wird erstmal geprüft, ist diese Idee auf Team- oder Abteilungsebene abzuarbeiten.
+
+Also wenn es jetzt einfach nur ist, wir möchten, dass hier jeden Mittwoch vor der und der Anlage XY einmal durchgefegt wird
+
+weil ich ansonsten mit dem XY nicht machen kann, weiß ich jetzt nicht.
+
+Mir fällt gerade ad hoc kein gutes Beispiel ein.
+
+Dann können die einfach schon mal direkt sagen, okay, das kann ich jetzt an den Fertigungsleiter schicken und dann können die das dort umsetzen.
+
+Und dann kommt das auch bei uns gar nicht auf den Tisch mit der Bitte um die Bearbeitung.
+
+Und dann haben wir diese Abfrage, und das ist jetzt dieser springende Punkt, ist die Idee abteilungsübergreifend, strategisch relevant oder ist ein Budget notwendig?
+
+Und wenn da dann ja ist, dann muss es erst kategorisiert, priorisiert und in die Projektliste überführt werden.
+
+Und dann haben wir so gewisse Kriterien, um diese Ideen eben zuzuordnen, was man da dann machen kann.
+
+So, das ist der Gedanke.
+
+Also ob das jetzt am Schluss eine andere...
+
+Ja, also eigentlich denke ich, passen alle unsere Anmerkungen, die wir bis jetzt hatten, gut da rein.
+
+Zumindest von meiner Meinung. Das ist ja auch immer so ein bisschen persönlich.
+
+Es ist auch so, ich bestehe nicht darauf, dass das bei mir in der Abteilung gemacht wird.
+
+Es war sozusagen, wo ist auch Personal verfügbar, die das überhaupt machen können.
+
+Also Giovanna hat da jetzt nicht gerade hier geschrien mit ihren MitarbeiterInnen.
+
+Ich bin auch dankbar, dass das nicht hier gemacht wird, weil es kann halt wirklich von A bis Z sein und deine Jungs sind halt in alle Bereiche gut vernetzt auch. Das darf man ja auch nicht vergessen.
+
+Und vielleicht muss man es auch nochmal so ein bisschen formulieren. Es sind natürlich nicht Business Development, wobei Business Development besteht darauf, dass es eigene Projekte sind, aber es wird immer, das zeigt ja auch die Erfahrung von meinen Entwicklungsprojekten, da sind ja immer andere Abteilungen involviert.
+
+Also insofern gibt es dann welche, die ein bisschen mehr in die Richtung kippen, ein bisschen mehr in die kippen und das auch über den Projektverlauf noch sich ändert.
+
+Was mir halt wichtig ist, unabhängig wie das Projektmanagement danach, nach der Liste aussieht, dass es halt einen Reporting-Zyklus gibt. Dass man hier halt abgedatet wird und dass das, und deswegen ist dein Dokument eben auch gut, in irgendeiner Form da abgelehnt wird.
+
+So, und dann sollte man sich einfach darauf einigen
+
+dass diese zwei, drei Folien immer gemacht werden.
+
+Und wenn man was nicht hat, dann hat man was nicht.
+
+Und wenn man mehr braucht, dann macht man das halt mit hinten dran.
+
+Aber es muss halt dokumentiert sein, weil darum ging es ja letztendlich.
+
+Das war die Idee dahinter, dass diese Projektinformationen
+
+allen zur Verfügung liegen, schnittstellenübergreifend.
+
+Deswegen haben wir das überhaupt erst angefasst.
+
+Lars haben wir jetzt irgendwie verloren.
+
+Lars haben wir verloren.
+
+Nein, die Verbindung ist ja in einem Büro oder zu Hause.
+
+Da ist ein Büro.
+
+Das hat mir aufgefallen
+
+in den letzten Tagen zum Teil die Verbindung
+
+die hast du auch bei Lars gesehen
+
+die Sprache kommt erst hinterher.
+
+Die Verbindung ist manchmal so grottenschlecht.
+
+Und jetzt haben wir über ein Handy.
+
+Ja, ich muss über das Handy reingehen.
+
+Mein Rechner schmiert gerade total ab.
+
+Ich hatte natürlich alles schwarz
+
+komplett beide Bildschirme, dann nur noch euch.
+
+Ich fahre jetzt einfach
+
+einmal rauf und runter und so lange
+
+bin ich hier so dabei.
+
+Reparatur und hervorstart.
+
+Ja, genau.
+
+Das hilft.
+
+Aber momentan
+
+ist das Netzwerk bei Gemeinden gröntelangsam.
+
+Wenn ich jetzt auf dem
+
+Internet-Datei runterlade, die 17 MB
+
+ist, das ist wie zu
+
+ISDN-Zeiten.
+
+Im internen Netzwerk.
+
+Ja, ich habe auch mein Gefühl.
+
+Ja gut, ich habe von daher eben eure Diskussion nicht vollständig mitgekriegt.
+
+Also im Wesentlichen, die personelle Entscheidung, dass das jetzt bei mir in der F&E gelandet ist, war einfach nur eine Verfügbarkeitsentscheidung von Personen, die halbwegs in der Lage sind, das abzuarbeiten.
+
+Ich bestehe da keinesfalls drauf. Wenn das irgendjemand anders übernehmen will, diese Vorsortierung und das Abfragen der Minimaldaten, gerne. Also überhaupt gar kein Problem.
+
+Ich bin nur, also Malte und ich kann man glaube ich sagen, wir sind der Meinung, es ist fast egal, wer das macht. An dieser Stelle, also an dieser wirklich allerersten Stelle, wo irgendwas reinkommt, die Erfahrung sagt einfach, da kommt in aller Regel nicht ein vollständiger Satz an Informationen rein, mit dem sich hochbezahlte Leute dann schon entscheidend befassen können, sondern da fehlen immer Sachen.
+
+Und dieses Mindestmaß muss von irgendjemandem einfach aufgefüllt werden nach Möglichkeit. Und wenn die noch einen Kategorisierungsvorschlag machen, umso besser. Und ob der dann bestehen bleibt oder nicht, das sehen wir dann bei uns.
+
+Also grundsätzlich, das hatte ich vorhin, ich würde ja das versuchen ein bisschen zusammenzufassen, was wir hier gerade so besprochen haben, habe ich in die Mail vorhin eben schon reingeschrieben, könnte das ja auch zum Beispiel im Sekretariat der Geschäftsführung angesiedelt sein oder irgendwo anders im kaufmännischen Bereich.
+
+Es spielt tatsächlich keine entscheidende Rolle, weil am Ende des Tages muss sowieso nach sehr kurzer Zeit entschieden werden, in welche Fachabteilung gehört das, welche Kompetenzen müssen hinzugezogen werden, eingebunden werden und diskutiert werden.
+
+Und es kann sein, dass F und E dann daran überhaupt nicht beteiligt ist.

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_05.txt

@@ -0,0 +1,295 @@
+Genau.
+
+Sondern dass, Björn, du das zum Beispiel mit PM diskutierst oder Business Development mit dir oder wie auch immer.
+
+Und die Jungs das dann einfach zu euch rüberspielen und sagen, kümmert euch drum.
+
+Aber füllt bitte, seht zu, dass ihr das hier entlang dieses Katalogs ausarbeitet und dann auch zur Entscheidung bringt.
+
+entweder und uns aber auch eine Rückmeldung gibt,
+
+weil wir bündeln das hier zentral, damit wir auch wissen,
+
+welche Projekte im Unternehmen laufen und welche nicht laufen.
+
+Genau. Und ich kann dir sagen aus Erfahrung,
+
+das Sekretariat der Geschäftsführung ist da,
+
+sage ich mal, also Sekretariate sind da sehr abweisend,
+
+was das angeht, weil die sagen dann sofort,
+
+ja, ich habe ja überhaupt gar keine Ahnung davon
+
+und ich habe so viel anderes zu tun.
+
+Insofern ist es einfach eine pragmatische Lösung,
+
+das in einer der Fachabteilungen zu machen.
+
+Und wenn die Personen eine latente Ahnung von vielen haben,
+
+ist es jetzt auch nicht schädlich.
+
+Und es ist genauso, wie du sagtest, vorbereiten.
+
+Und du brauchst auch einen, der es einfach formal nachhält.
+
+Nachdem das in eine Abteilung gegangen ist, ist da was passiert.
+
+Nach vier Wochen mal fragen, ist der Stand, wird es bearbeitet?
+
+Eine Liste führen. Irgendwer muss eine Liste führen.
+
+Und wo drinsteht, wer sich um was kümmert.
+
+damit auch Sachen, die zweimal reinkommen aus verschiedenen Ecken, einfach erkannt werden
+
+und nicht durch irgendeine Kleinigkeit mal nach rechts und mal nach links abbiegen
+
+und am Ende doch das Gleiche sind.
+
+Ja, aber jetzt lass uns das doch mal weiterspielen.
+
+Jetzt steht Björn oder PM eigentlich egal in der Diskussion mit Business Development
+
+und dem Vertrieb über die Relevanz irgendeines speziellen Marktes.
+
+Ein wildes Beispiel, wollen wir Papatikus-Ankart zusammen mit Wikimarkt Green in Turkmenistan pushen.
+
+Das ist ja im Prinzip ein Projekt, wo wir nach der Diskussion beim Strategie-Meeting gesagt haben,
+
+naja, da müssten wir jetzt eigentlich unsere Filter anlegen, wollen wir uns damit beschäftigen.
+
+wäre denn jetzt tatsächlich dieser Prozess,
+
+das über James oder über die F&E zu spielen,
+
+der richtige Weg?
+
+Und das ist aber ja genau das Ziel.
+
+Wir wollen ja einen Prozess etablieren,
+
+in dem die Filter sicher abgefragt werden.
+
+Das ist eben nicht, heißt Business Development und PM entscheiden,
+
+wahnsinnig wichtig, finden wir mega cool,
+
+wollen wir unbedingt machen.
+
+Björn rauft sich die Haare, weil er sagt, wo ist denn die Marktanalyse?
+
+Und die Geschäftsführung ist hin und her gerissen und entscheidet mal,
+
+der rechte Raum entscheidet so, der linke Raum in so oder nach Tagesform.
+
+Das ist ja genau das, was wir wollen.
+
+Wir wollen irgendwo, dass das strukturiert passiert.
+
+Und genau da ist wieder egal, wer das, also in Person, wer das macht,
+
+sondern diese Filter müssen wir einmal definieren.
+
+und die hat ja die GF ein paar definiert und die können sicherlich, also grobe Filter, nicht bis ins Kleinste.
+
+Die müssen, das ist das, was ich sage, die müssen definiert werden und dann ist das wie einer, da warst du glaube ich schon raus,
+
+das ist wie einer Telefonhotline, wenn du anrufst, der fragt dich oder die fragt dich, was für ein Problem haben sie
+
+und dann biegt das in so einem Entscheidungsbaum ab.
+
+Und die Aufgabe von den Personen, die das machen, in dem Fall jetzt aktuell James und David, wäre dann eben genau zu fragen,
+
+gibt es schon eine Marktanalyse?
+
+Ist das ein Bauchgefühl?
+
+Habe ich das aus irgendwelchen Veröffentlichungen?
+
+Also gibt es da schon irgendwas?
+
+Und das einfach aufzusummieren, damit die Fachabteilung,
+
+an die das dann geht, schon mal eine gewisse Entscheidungsgrundlage hat.
+
+Und dafür brauche ich mich überhaupt gar nicht in den Markt auskennen,
+
+sondern ich frage ja den, der die Idee reingibt.
+
+Und die kommt ja nicht zwangsläufig aus der Fachabteilung,
+
+sondern der Prozess ist ja letztendlich, irgendein Vertriebler sagt, ich muss die Platypus Anker mit Sekumat in Dings verkaufen.
+
+Das ist ja mehr so der Ablauf, der dahinter steht.
+
+Wenn Business Development sowas selber in Frage stellt oder sich selber überlegt,
+
+dann sollten die sich die Gedanken vorher schon gemacht haben.
+
+Die kennen ja ihre eigenen Ansprüche, aber auch die kann man natürlich aufschreiben.
+
+Das wäre dann eine Verfeinerung. Bin ich sehr dafür.
+
+Also je mehr die Person, die das vorentscheiden muss, vorher schon Filterkriterien hat, die er einfach abarbeiten kann und einfach sagen kann, lieber Lars, habe ich verstanden, technisch habe ich verstanden, weißt du denn schon, wie groß der Markt da so ist?
+
+Ja, zwei Millionen Euro.
+
+Und wenn er dann schon sieht, die normale Anforderung ist fünf Millionen Euro,
+
+dann kann er schon mal ein Fragezeichen dran machen.
+
+Oder du zuckst mit dem Schulter und sagst, weiß ich nicht,
+
+dann kommt da auch ein Vermerk dran, also die anderen durch.
+
+Und dann müssen wir uns halt überlegen,
+
+sind wir so davon überzeugt, dass wir die Marktstudie anschieben,
+
+die ja dann auch Zeit und Geld kostet.
+
+und Ressourcen im weitesten Sinne.
+
+So ganz lösen wird man es am Anfang nicht.
+
+Aber du kannst über diesen Prozess, finde ich,
+
+mit jemandem, der am Eingang steht, so ein Gatekeeper,
+
+der einfach formal ein paar Sachen abarbeitet
+
+und Informationen zusammenträgt,
+
+den Entscheidungsprozess hinterher qualitativ besser machen.
+
+Von dem, was ich verstehe, ist das, was Lars jetzt anspricht,
+
+auch eigentlich die Bewertung, die bei uns im Gremium dann ansteht.
+
+Also wir haben ja einmal den Punkt,
+
+dass es von der Ideenliste in die Projektliste kommt und dann wird ja hier darüber diskutiert, machen ja nein, mit welcher Prio etc. pp.
+
+Wer macht es? Und diese Filter sind zu 100% in dem Prozess auch überhaupt nicht abgebildet.
+
+Das steht hier noch nicht so drin. Hier steht nicht drin, er muss in fünf Jahren fünf Millionen machen.
+
+Das wird nämlich nicht für alle Ideen passen.
+
+Es passt nämlich nicht dafür, wenn ein Mitarbeiter sagt, okay, wir sollten Maschine XY bei dem und dem Auftrag vielleicht ein bisschen langsamer fahren oder sowas. Das passt ja gar nicht zu diesem allgemeinen Konzept. Wie wir das hier dann manchmal noch bewerten, das kann ja auch variieren oder mal eine Wette abgeschlossen werden oder so.
+
+und von meinem Empfinden,
+
+wenn Giovanna jetzt
+
+irgendwas hat, so wie das
+
+Beispiel, was du jetzt gerade eben hattest,
+
+es spricht ja auch nichts dagegen,
+
+dass das dann noch, zumindest
+
+meiner Meinung nach, dass das separat
+
+in diesen Meetings dann in diese Liste
+
+ohne die E-Mail
+
+mit aufgenommen wird, wenn wir hier
+
+zusammensitzen und da alle drüber sprechen. Wichtig ist
+
+ja nur, dass es in der Projektliste dann am Schluss
+
+landet, aber weil
+
+der Ideenpool ist ja ein allgemeines
+
+Sammelsorium für
+
+Die Ideen. Und dafür ist der Prozess auch da. In allen Bereichen. Wenn wir jetzt noch irgendwas haben, was aus einem Meeting entsteht oder sowas, das muss dann ja nur trotzdem in die Liste. Das kann ja trotzdem passieren, wenn die Fragen beantwortet sind.
+
+Dafür musst du aber eigentlich auch oben nochmal rein und sagen,
+
+habe ich denn die Mindestanforderungen, die ich, also wiederum die Kategorisierung,
+
+ist es BD, EDD, PM, was auch immer und diese, die haben irgendwie drei bis fünf wirklich Sachen,
+
+die am besten vorneweg beantwortet werden.
+
+Aber das Schlimmste ist, dass einer kommt und sagt, ich habe einfach, der nur ein Stichwort reinwirft.
+
+Ja, das kann ja nicht passieren.
+
+Das kann ja auch, also
+
+so verstehe ich das jetzt. Das kann aktuell nicht
+
+passieren. Raik kann jetzt nicht, und das ist
+
+ja auch was, was wir dann durchsetzen werden müssen.
+
+Wenn Raik hier jemanden anruft, ist
+
+immer einfach ein gutes Beispiel,
+
+müssen wir ihm sagen, bitte trag
+
+das in den Pool ein,
+
+dann wird er wen anders anrufen und da muss eben
+
+die gleiche Antwort kommen.
+
+So. Und wenn
+
+er es dann anfährt, dann wird sich jemand anderes
+
+darum kümmern, dass er die klassischen
+
+Fragen beantwortet und wenn wir das alles zusammengetragen
+
+haben, dann werden wir mit fünf Leuten hier
+
+zusammensitzen und gemeinsam
+
+entscheiden, okay, welche Prio hat das? Ist das
+
+sinnvoll? Ist es ein F-Projekt? Ist es ein
+
+E-Projekt? Ist es ein BD-Projekt? Ein Pernprojekt?
+
+Wer sollte sich darum kümmern
+
+und wer kriegt den Hut auf? Weil das war
+
+ja die, also
+
+dieses Zusammentragen von Ideen
+
+und jemanden einen Hut für das Projekt
+
+aufsetzen, das war das Kern des Problems,
+
+weswegen wir gesagt haben, wir wollen uns damit neu
+
+aufeinandersetzen. Dieser Prozess ist ja nur
+
+Teil der Lösung.
+
+Das war die Problemstellung, weswegen Herr Peter eingeladen hat.
+
+Jetzt korrigiert mich, wenn ich falsch liege.
+
+Aber diese Projektbearbeitung schneller zu machen, Leuten Hut aufzusetzen, das zu zentralisieren
+
+und nicht an drei Stellen im Unternehmen die gleichen Sachen zu bearbeiten, ohne dass einer davon weiß.
+
+Ich kann das unterstützen.
+
+Die meisten Projekte scheitern daran, dass kein Kontext drumherum ist, sondern dann wird irgendein Stichwort reingeworfen, dann soll sich jemand drum kümmern und dann ist auch schon ziemlich schnell Ende, weil eben dann, ja, es wird zwar gesagt Lauf, aber nicht in welche Richtung letztendlich.

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_05_changes.json

@@ -0,0 +1,324 @@
+{
+  "source_file": "chunk_05.txt",
+  "output_file": "chunk_05_normalized.txt",
+  "blocks_total": 148,
+  "blocks_changed": 42,
+  "policy": {
+    "removed": [
+      "isolated filler sounds such as äh, ähm, hm, mhm",
+      "immediate duplicate words",
+      "immediate duplicate phrases of two to four words",
+      "redundant whitespace"
+    ],
+    "explicitly_preserved": [
+      "negations",
+      "modal words and qualifiers",
+      "dates, times, numbers and quantities",
+      "technical statements",
+      "responsibilities",
+      "deadlines",
+      "decisions and commitments"
+    ],
+    "principle": "When uncertain, leave the text unchanged."
+  },
+  "changes": [
+    {
+      "block_number": 5,
+      "original": "entweder und uns aber auch eine Rückmeldung gibt,",
+      "normalized": "entweder und uns aber auch eine Rückmeldung gibt",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 6,
+      "original": "weil wir bündeln das hier zentral, damit wir auch wissen,",
+      "normalized": "weil wir bündeln das hier zentral, damit wir auch wissen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 8,
+      "original": "Genau. Und ich kann dir sagen aus Erfahrung,",
+      "normalized": "Genau. Und ich kann dir sagen aus Erfahrung",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 9,
+      "original": "das Sekretariat der Geschäftsführung ist da,",
+      "normalized": "das Sekretariat der Geschäftsführung ist da",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 10,
+      "original": "sage ich mal, also Sekretariate sind da sehr abweisend,",
+      "normalized": "sage ich mal, also Sekretariate sind da sehr abweisend",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 11,
+      "original": "was das angeht, weil die sagen dann sofort,",
+      "normalized": "was das angeht, weil die sagen dann sofort",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 14,
+      "original": "Insofern ist es einfach eine pragmatische Lösung,",
+      "normalized": "Insofern ist es einfach eine pragmatische Lösung",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 16,
+      "original": "Und wenn die Personen eine latente Ahnung von vielen haben,",
+      "normalized": "Und wenn die Personen eine latente Ahnung von vielen haben",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 20,
+      "original": "Nachdem das in eine Abteilung gegangen ist, ist da was passiert.",
+      "normalized": "Nachdem das in eine Abteilung gegangen ist da was passiert.",
+      "removed_fillers": [],
+      "duplicate_reductions": [
+        "ist, ist"
+      ]
+    },
+    {
+      "block_number": 31,
+      "original": "Das ist ja im Prinzip ein Projekt, wo wir nach der Diskussion beim Strategie-Meeting gesagt haben,",
+      "normalized": "Das ist ja im Prinzip ein Projekt, wo wir nach der Diskussion beim Strategie-Meeting gesagt haben",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 33,
+      "original": "wäre denn jetzt tatsächlich dieser Prozess,",
+      "normalized": "wäre denn jetzt tatsächlich dieser Prozess",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 34,
+      "original": "das über James oder über die F&E zu spielen,",
+      "normalized": "das über James oder über die F&E zu spielen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 37,
+      "original": "Wir wollen ja einen Prozess etablieren,",
+      "normalized": "Wir wollen ja einen Prozess etablieren",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 39,
+      "original": "Das ist eben nicht, heißt Business Development und PM entscheiden,",
+      "normalized": "Das ist eben nicht, heißt Business Development und PM entscheiden",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 40,
+      "original": "wahnsinnig wichtig, finden wir mega cool,",
+      "normalized": "wahnsinnig wichtig, finden wir mega cool",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 43,
+      "original": "Und die Geschäftsführung ist hin und her gerissen und entscheidet mal,",
+      "normalized": "Und die Geschäftsführung ist hin und her gerissen und entscheidet mal",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 47,
+      "original": "Und genau da ist wieder egal, wer das, also in Person, wer das macht,",
+      "normalized": "Und genau da ist wieder egal, wer das, also in Person, wer das macht",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 50,
+      "original": "Die müssen, das ist das, was ich sage, die müssen definiert werden und dann ist das wie einer, da warst du glaube ich schon raus,",
+      "normalized": "Die müssen, das ist das, was ich sage, die müssen definiert werden und dann ist das wie einer, da warst du glaube ich schon raus",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 53,
+      "original": "Und die Aufgabe von den Personen, die das machen, in dem Fall jetzt aktuell James und David, wäre dann eben genau zu fragen,",
+      "normalized": "Und die Aufgabe von den Personen, die das machen, in dem Fall jetzt aktuell James und David, wäre dann eben genau zu fragen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 58,
+      "original": "Und das einfach aufzusummieren, damit die Fachabteilung,",
+      "normalized": "Und das einfach aufzusummieren, damit die Fachabteilung",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 60,
+      "original": "Und dafür brauche ich mich überhaupt gar nicht in den Markt auskennen,",
+      "normalized": "Und dafür brauche ich mich überhaupt gar nicht in den Markt auskennen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 62,
+      "original": "Und die kommt ja nicht zwangsläufig aus der Fachabteilung,",
+      "normalized": "Und die kommt ja nicht zwangsläufig aus der Fachabteilung",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 65,
+      "original": "Wenn Business Development sowas selber in Frage stellt oder sich selber überlegt,",
+      "normalized": "Wenn Business Development sowas selber in Frage stellt oder sich selber überlegt",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 71,
+      "original": "Und wenn er dann schon sieht, die normale Anforderung ist fünf Millionen Euro,",
+      "normalized": "Und wenn er dann schon sieht, die normale Anforderung ist fünf Millionen Euro",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 73,
+      "original": "Oder du zuckst mit dem Schulter und sagst, weiß ich nicht,",
+      "normalized": "Oder du zuckst mit dem Schulter und sagst, weiß ich nicht",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 75,
+      "original": "Und dann müssen wir uns halt überlegen,",
+      "normalized": "Und dann müssen wir uns halt überlegen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 76,
+      "original": "sind wir so davon überzeugt, dass wir die Marktstudie anschieben,",
+      "normalized": "sind wir so davon überzeugt, dass wir die Marktstudie anschieben",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 80,
+      "original": "Aber du kannst über diesen Prozess, finde ich,",
+      "normalized": "Aber du kannst über diesen Prozess, finde ich",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 81,
+      "original": "mit jemandem, der am Eingang steht, so ein Gatekeeper,",
+      "normalized": "mit jemandem, der am Eingang steht, so ein Gatekeeper",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 83,
+      "original": "und Informationen zusammenträgt,",
+      "normalized": "und Informationen zusammenträgt",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 85,
+      "original": "Von dem, was ich verstehe, ist das, was Lars jetzt anspricht,",
+      "normalized": "Von dem, was ich verstehe, ist das, was Lars jetzt anspricht",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 87,
+      "original": "Also wir haben ja einmal den Punkt,",
+      "normalized": "Also wir haben ja einmal den Punkt",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 93,
+      "original": "und von meinem Empfinden,",
+      "normalized": "und von meinem Empfinden",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 96,
+      "original": "Beispiel, was du jetzt gerade eben hattest,",
+      "normalized": "Beispiel, was du jetzt gerade eben hattest",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 97,
+      "original": "es spricht ja auch nichts dagegen,",
+      "normalized": "es spricht ja auch nichts dagegen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 109,
+      "original": "Dafür musst du aber eigentlich auch oben nochmal rein und sagen,",
+      "normalized": "Dafür musst du aber eigentlich auch oben nochmal rein und sagen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 110,
+      "original": "habe ich denn die Mindestanforderungen, die ich, also wiederum die Kategorisierung,",
+      "normalized": "habe ich denn die Mindestanforderungen, die ich, also wiederum die Kategorisierung",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 111,
+      "original": "ist es BD, EDD, PM, was auch immer und diese, die haben irgendwie drei bis fünf wirklich Sachen,",
+      "normalized": "ist es BD, EDD, PM, was auch immer und diese, die haben irgendwie drei bis fünf wirklich Sachen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 118,
+      "original": "ja auch was, was wir dann durchsetzen werden müssen.",
+      "normalized": "ja auch was wir dann durchsetzen werden müssen.",
+      "removed_fillers": [],
+      "duplicate_reductions": [
+        "was, was"
+      ]
+    },
+    {
+      "block_number": 120,
+      "original": "immer einfach ein gutes Beispiel,",
+      "normalized": "immer einfach ein gutes Beispiel",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 122,
+      "original": "das in den Pool ein,",
+      "normalized": "das in den Pool ein",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 139,
+      "original": "aufsetzen, das war das Kern des Problems,",
+      "normalized": "aufsetzen, das war das Kern des Problems",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    }
+  ]
+}

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_05_normalized.txt

@@ -0,0 +1,295 @@
+Genau.
+
+Sondern dass, Björn, du das zum Beispiel mit PM diskutierst oder Business Development mit dir oder wie auch immer.
+
+Und die Jungs das dann einfach zu euch rüberspielen und sagen, kümmert euch drum.
+
+Aber füllt bitte, seht zu, dass ihr das hier entlang dieses Katalogs ausarbeitet und dann auch zur Entscheidung bringt.
+
+entweder und uns aber auch eine Rückmeldung gibt
+
+weil wir bündeln das hier zentral, damit wir auch wissen
+
+welche Projekte im Unternehmen laufen und welche nicht laufen.
+
+Genau. Und ich kann dir sagen aus Erfahrung
+
+das Sekretariat der Geschäftsführung ist da
+
+sage ich mal, also Sekretariate sind da sehr abweisend
+
+was das angeht, weil die sagen dann sofort
+
+ja, ich habe ja überhaupt gar keine Ahnung davon
+
+und ich habe so viel anderes zu tun.
+
+Insofern ist es einfach eine pragmatische Lösung
+
+das in einer der Fachabteilungen zu machen.
+
+Und wenn die Personen eine latente Ahnung von vielen haben
+
+ist es jetzt auch nicht schädlich.
+
+Und es ist genauso, wie du sagtest, vorbereiten.
+
+Und du brauchst auch einen, der es einfach formal nachhält.
+
+Nachdem das in eine Abteilung gegangen ist da was passiert.
+
+Nach vier Wochen mal fragen, ist der Stand, wird es bearbeitet?
+
+Eine Liste führen. Irgendwer muss eine Liste führen.
+
+Und wo drinsteht, wer sich um was kümmert.
+
+damit auch Sachen, die zweimal reinkommen aus verschiedenen Ecken, einfach erkannt werden
+
+und nicht durch irgendeine Kleinigkeit mal nach rechts und mal nach links abbiegen
+
+und am Ende doch das Gleiche sind.
+
+Ja, aber jetzt lass uns das doch mal weiterspielen.
+
+Jetzt steht Björn oder PM eigentlich egal in der Diskussion mit Business Development
+
+und dem Vertrieb über die Relevanz irgendeines speziellen Marktes.
+
+Ein wildes Beispiel, wollen wir Papatikus-Ankart zusammen mit Wikimarkt Green in Turkmenistan pushen.
+
+Das ist ja im Prinzip ein Projekt, wo wir nach der Diskussion beim Strategie-Meeting gesagt haben
+
+naja, da müssten wir jetzt eigentlich unsere Filter anlegen, wollen wir uns damit beschäftigen.
+
+wäre denn jetzt tatsächlich dieser Prozess
+
+das über James oder über die F&E zu spielen
+
+der richtige Weg?
+
+Und das ist aber ja genau das Ziel.
+
+Wir wollen ja einen Prozess etablieren
+
+in dem die Filter sicher abgefragt werden.
+
+Das ist eben nicht, heißt Business Development und PM entscheiden
+
+wahnsinnig wichtig, finden wir mega cool
+
+wollen wir unbedingt machen.
+
+Björn rauft sich die Haare, weil er sagt, wo ist denn die Marktanalyse?
+
+Und die Geschäftsführung ist hin und her gerissen und entscheidet mal
+
+der rechte Raum entscheidet so, der linke Raum in so oder nach Tagesform.
+
+Das ist ja genau das, was wir wollen.
+
+Wir wollen irgendwo, dass das strukturiert passiert.
+
+Und genau da ist wieder egal, wer das, also in Person, wer das macht
+
+sondern diese Filter müssen wir einmal definieren.
+
+und die hat ja die GF ein paar definiert und die können sicherlich, also grobe Filter, nicht bis ins Kleinste.
+
+Die müssen, das ist das, was ich sage, die müssen definiert werden und dann ist das wie einer, da warst du glaube ich schon raus
+
+das ist wie einer Telefonhotline, wenn du anrufst, der fragt dich oder die fragt dich, was für ein Problem haben sie
+
+und dann biegt das in so einem Entscheidungsbaum ab.
+
+Und die Aufgabe von den Personen, die das machen, in dem Fall jetzt aktuell James und David, wäre dann eben genau zu fragen
+
+gibt es schon eine Marktanalyse?
+
+Ist das ein Bauchgefühl?
+
+Habe ich das aus irgendwelchen Veröffentlichungen?
+
+Also gibt es da schon irgendwas?
+
+Und das einfach aufzusummieren, damit die Fachabteilung
+
+an die das dann geht, schon mal eine gewisse Entscheidungsgrundlage hat.
+
+Und dafür brauche ich mich überhaupt gar nicht in den Markt auskennen
+
+sondern ich frage ja den, der die Idee reingibt.
+
+Und die kommt ja nicht zwangsläufig aus der Fachabteilung
+
+sondern der Prozess ist ja letztendlich, irgendein Vertriebler sagt, ich muss die Platypus Anker mit Sekumat in Dings verkaufen.
+
+Das ist ja mehr so der Ablauf, der dahinter steht.
+
+Wenn Business Development sowas selber in Frage stellt oder sich selber überlegt
+
+dann sollten die sich die Gedanken vorher schon gemacht haben.
+
+Die kennen ja ihre eigenen Ansprüche, aber auch die kann man natürlich aufschreiben.
+
+Das wäre dann eine Verfeinerung. Bin ich sehr dafür.
+
+Also je mehr die Person, die das vorentscheiden muss, vorher schon Filterkriterien hat, die er einfach abarbeiten kann und einfach sagen kann, lieber Lars, habe ich verstanden, technisch habe ich verstanden, weißt du denn schon, wie groß der Markt da so ist?
+
+Ja, zwei Millionen Euro.
+
+Und wenn er dann schon sieht, die normale Anforderung ist fünf Millionen Euro
+
+dann kann er schon mal ein Fragezeichen dran machen.
+
+Oder du zuckst mit dem Schulter und sagst, weiß ich nicht
+
+dann kommt da auch ein Vermerk dran, also die anderen durch.
+
+Und dann müssen wir uns halt überlegen
+
+sind wir so davon überzeugt, dass wir die Marktstudie anschieben
+
+die ja dann auch Zeit und Geld kostet.
+
+und Ressourcen im weitesten Sinne.
+
+So ganz lösen wird man es am Anfang nicht.
+
+Aber du kannst über diesen Prozess, finde ich
+
+mit jemandem, der am Eingang steht, so ein Gatekeeper
+
+der einfach formal ein paar Sachen abarbeitet
+
+und Informationen zusammenträgt
+
+den Entscheidungsprozess hinterher qualitativ besser machen.
+
+Von dem, was ich verstehe, ist das, was Lars jetzt anspricht
+
+auch eigentlich die Bewertung, die bei uns im Gremium dann ansteht.
+
+Also wir haben ja einmal den Punkt
+
+dass es von der Ideenliste in die Projektliste kommt und dann wird ja hier darüber diskutiert, machen ja nein, mit welcher Prio etc. pp.
+
+Wer macht es? Und diese Filter sind zu 100% in dem Prozess auch überhaupt nicht abgebildet.
+
+Das steht hier noch nicht so drin. Hier steht nicht drin, er muss in fünf Jahren fünf Millionen machen.
+
+Das wird nämlich nicht für alle Ideen passen.
+
+Es passt nämlich nicht dafür, wenn ein Mitarbeiter sagt, okay, wir sollten Maschine XY bei dem und dem Auftrag vielleicht ein bisschen langsamer fahren oder sowas. Das passt ja gar nicht zu diesem allgemeinen Konzept. Wie wir das hier dann manchmal noch bewerten, das kann ja auch variieren oder mal eine Wette abgeschlossen werden oder so.
+
+und von meinem Empfinden
+
+wenn Giovanna jetzt
+
+irgendwas hat, so wie das
+
+Beispiel, was du jetzt gerade eben hattest
+
+es spricht ja auch nichts dagegen
+
+dass das dann noch, zumindest
+
+meiner Meinung nach, dass das separat
+
+in diesen Meetings dann in diese Liste
+
+ohne die E-Mail
+
+mit aufgenommen wird, wenn wir hier
+
+zusammensitzen und da alle drüber sprechen. Wichtig ist
+
+ja nur, dass es in der Projektliste dann am Schluss
+
+landet, aber weil
+
+der Ideenpool ist ja ein allgemeines
+
+Sammelsorium für
+
+Die Ideen. Und dafür ist der Prozess auch da. In allen Bereichen. Wenn wir jetzt noch irgendwas haben, was aus einem Meeting entsteht oder sowas, das muss dann ja nur trotzdem in die Liste. Das kann ja trotzdem passieren, wenn die Fragen beantwortet sind.
+
+Dafür musst du aber eigentlich auch oben nochmal rein und sagen
+
+habe ich denn die Mindestanforderungen, die ich, also wiederum die Kategorisierung
+
+ist es BD, EDD, PM, was auch immer und diese, die haben irgendwie drei bis fünf wirklich Sachen
+
+die am besten vorneweg beantwortet werden.
+
+Aber das Schlimmste ist, dass einer kommt und sagt, ich habe einfach, der nur ein Stichwort reinwirft.
+
+Ja, das kann ja nicht passieren.
+
+Das kann ja auch, also
+
+so verstehe ich das jetzt. Das kann aktuell nicht
+
+passieren. Raik kann jetzt nicht, und das ist
+
+ja auch was wir dann durchsetzen werden müssen.
+
+Wenn Raik hier jemanden anruft, ist
+
+immer einfach ein gutes Beispiel
+
+müssen wir ihm sagen, bitte trag
+
+das in den Pool ein
+
+dann wird er wen anders anrufen und da muss eben
+
+die gleiche Antwort kommen.
+
+So. Und wenn
+
+er es dann anfährt, dann wird sich jemand anderes
+
+darum kümmern, dass er die klassischen
+
+Fragen beantwortet und wenn wir das alles zusammengetragen
+
+haben, dann werden wir mit fünf Leuten hier
+
+zusammensitzen und gemeinsam
+
+entscheiden, okay, welche Prio hat das? Ist das
+
+sinnvoll? Ist es ein F-Projekt? Ist es ein
+
+E-Projekt? Ist es ein BD-Projekt? Ein Pernprojekt?
+
+Wer sollte sich darum kümmern
+
+und wer kriegt den Hut auf? Weil das war
+
+ja die, also
+
+dieses Zusammentragen von Ideen
+
+und jemanden einen Hut für das Projekt
+
+aufsetzen, das war das Kern des Problems
+
+weswegen wir gesagt haben, wir wollen uns damit neu
+
+aufeinandersetzen. Dieser Prozess ist ja nur
+
+Teil der Lösung.
+
+Das war die Problemstellung, weswegen Herr Peter eingeladen hat.
+
+Jetzt korrigiert mich, wenn ich falsch liege.
+
+Aber diese Projektbearbeitung schneller zu machen, Leuten Hut aufzusetzen, das zu zentralisieren
+
+und nicht an drei Stellen im Unternehmen die gleichen Sachen zu bearbeiten, ohne dass einer davon weiß.
+
+Ich kann das unterstützen.
+
+Die meisten Projekte scheitern daran, dass kein Kontext drumherum ist, sondern dann wird irgendein Stichwort reingeworfen, dann soll sich jemand drum kümmern und dann ist auch schon ziemlich schnell Ende, weil eben dann, ja, es wird zwar gesagt Lauf, aber nicht in welche Richtung letztendlich.

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_06.txt

@@ -0,0 +1,183 @@
+Okay, ich hoffe, ich habe die Punktale.
+
+Ich habe ein bisschen mit.
+
+Und ich denke, ob dann noch Punkte fehlen, die wir abfragen müssen,
+
+das wird auch einfach die Zeit zeigen.
+
+Das würde ich jetzt nicht im Vorhinein versuchen, alles zu planen.
+
+Ich denke, wir werden relativ schnell nach zwei, drei, vier Terminen
+
+und nach 10, 15 Projekten merken, wo was fehlt und was nicht.
+
+Und das dann zu ergänzen, ohne dass das im WeFlow ist,
+
+sondern einfach, weil wir die Datei, die hinterlegt ist, anpassen,
+
+spricht von meinem Verständnis nichts gegen.
+
+Und das macht das flexibler.
+
+Und wir dürfen die, also die Sachen, die wir intern machen,
+
+die sind da noch ein bisschen anders,
+
+weil wir einen anderen Anspruch haben und auch eine andere Motivation.
+
+Aber die Sachen, die so von weiter außen kommen,
+
+die haben keine Lust, 20 Seiten zu füllen
+
+und irgendwie stundenlang zu recherchieren.
+
+Da wird es immer dabei bleiben, dass die irgendwie anrufen und was absetzen
+
+oder in eine fünfzeilige E-Mail schicken mit irgendeinem Vorschlag im weitesten Sinne.
+
+Und da wird es auch immer so sein, dass dann einer quasi das für diese Person ausfüllt und anreichert.
+
+Sonst geht auch zu viel verloren.
+
+Also wenn ein Raik anruft und du schickst den, na Raik ist ein schlechtes Beispiel,
+
+Aber wenn dann einer der durchschnittliche Vertriebler anruft und versucht, bei irgendwem das loszulassen, dann ist die Antwort nicht, schreib das ordentlich auf, wie hast du die Vorlage, das wird nämlich in den seltensten Fällen passieren, sondern dann ist eigentlich die Antwort, ruf mal bei James an, der geht mit dir die fünf Fragen durch und schweißt das dann ein.
+
+Ja, oder auch wenn Herr Peter eine Idee hat und bei mir, also ich sage jetzt mal, wenn Greenline bei mir anrufen würde, würde ich ja niemals sagen, ja nee, so, aber nicht, Sportsfreund. Das wird ja einfach nicht passieren, sondern dann würde ich das ausfüllen und in den Ideenpool einfließen. Aber wichtig ist halt, dass wir dafür sorgen, dass das konsequent so gemacht wird, weil ansonsten fahren wir wieder zweigleisig und lösen das Problem letztendlich nicht. Das heißt, die Durchsetzung, die Umsetzung ist das Entscheidende am Schluss.
+
+Ja, ich habe mal, wie gesagt, ein bisschen versucht mitzuschreiben, die verschiedenen Argumente.
+
+Jörn, lass uns mal hier zusammen drauf gucken, ob wir das so stehen lassen können.
+
+Also wir prüfen gerade, ob der bestehende Prozess an die allgemeineren Projekte angepasst und adaptiert werden könnte.
+
+Vom Grundsatz her sehen wir das als gegeben, da die Grundsätze eines Projektablaufs und das ist, glaube ich, dass Grundsätze Projektauslauf auch für strategische und Business Development Projekte gelten. Einige grundlegende Schritte sind ohne Anspruch auf Vollständigkeit.
+
+Filterkriterien, Festlegung relevante und einzubindende Abteilung, Definition Lastenhaft, Prüfkriterien, Entscheidungskriterien, Abschätzung Budget, Projektverantwortung, Projektablauf, Milestones, Projektfreigabe, Rückstellung und Ablehnung erwirken, Festlegung Priorität in Abstimmung im Gremium und mit GF.
+
+Das ist am Ende des Tages ja das, was wir wollen.
+
+Das ist unsere Aufgabe, dafür zu sorgen,
+
+dass wir nicht an tausend Stellen im Unternehmen irgendwas lostreten,
+
+wo hinterher keiner mehr weiß, wo sind eigentlich die losen Enden
+
+und mit welcher Priorität soll ich an welchem Ende zuppeln.
+
+Dass der initiale Aufhänger in der F&E liegt,
+
+ist eine rein organisatorische Festlegung,
+
+um gebündelt alle Projektideen zu erfassen.
+
+Die Ausarbeitung, Abstimmung und Entscheidung
+
+erfolgt grundsätzlich unter Einbindung der Kompetenz,
+
+grundsätzlich unter Einbindung der Fachbereiche.
+
+F&E übte ja eine rein verwaltende Tätigkeit mit dem Zusammentragen weniger Grundlagen aus, sonst nichts.
+
+Grundsätzlich könnte diese Stelle auch direkt im Sekretariat GF, Business Development oder sonst wo im kaufmännischen Bereich liegen.
+
+Da aber die schlichte Mehrzahl der Projekte physischer und struktureller Ideen vermutlich sein wird, sehen wir diese benannte Aufräumstelle als gut gewählt.
+
+Das können wir aber auch nach einer gewissen Zeit hinterfragen und gegebenenfalls ändern.
+
+Wir sehen da keine zwingende Notwendigkeit, das im FE zu belassen, wenn wir eine besser geeignete Stelle finden sollten.
+
+Ziel ist die Koordination und Beschleunigung und Strukturierung und Kontextualisierung aller relevanter, größerer Projekte im Unternehmen,
+
+um die Losen zu begrenzen und Kapazitäten zu effizient nutzen.
+
+So, das ist unser Auftrag.
+
+Ein Projekt wandert also direkt wieder in Business Development, Marketing, PM, EDD oder Logistik,
+
+wenn die Projekte dorthin gehören. Die Zwischenstufe Projekt dient also nur Sicherstellung, dass die Felder angewendet werden und es einen Überblick über die Gesamtheit der Projekte gibt mit Einstellungsdruck der Relevanz.
+
+Wir sollten also den bestehenden Rahmen nutzen und erweitern auf unsere Bedürfnisse, anpassen, aber immer im Rahmen nau als Mittelständler und uns keine komplexen Zusatzprozesse schaffen.
+
+Aufgehegabe wäre also die Definition von Filterkriterien für die
+
+verschiedenen Fälle, hier oben,
+
+die wir
+
+für relevant sehen, die wir für relevant halten
+
+und vermutlich regelmäßig auftauchen,
+
+nicht für irgendwelche Edge Cases. Hier oben, das kann man jetzt noch farblich hinterlegen.
+
+Das ist nämlich hier.
+
+Fasst das die Diskussion im Moment erstmal zusammen?
+
+Ist das auch unsere gemeinsame Meinung?
+
+Ja.
+
+Ja, da stehe ich voll zu.
+
+Ich war eben ein bisschen verunsichert,
+
+als Malte sagte,
+
+von wegen der Anschaffung von irgendwelchen Gabenstapler-Sachen,
+
+weil das sehe ich halt überhaupt gar nicht.
+
+Ja, pass auf, das war nur ein Beispiel.
+
+Wir wollen diese, es gibt bei uns im Haus, wir haben jetzt, wir würden eine Chance,
+
+also das haben Malte und ich uns in die Augen geholt, wir würden jetzt hier gerne eine Chance ergreifen,
+
+um auch Dinge abzufangen, die eher in den Bereich betriebliche Verbesserungsvorschläge fallen.
+
+Also wenn sowas da reinkommt, das wäre dann zum Beispiel der Gabelstapler oder so,
+
+der würde halt ganz am Anfang wieder ausgeschleust.
+
+Der kommt da rein und dann wird festgestellt, da geht es um, sag ich mal, einen betrieblichen Verbesserungsvorschlag.
+
+Team-Ebene oder so, ja.
+
+Das geht dann sofort in den Prozess Verbesserungsvorschlag oder das geht direkt in, keine Ahnung, direkt in die Produktion. Das machen die einfach fertig.
+
+Also es gibt so Projektideen. Da kommt einer, ein besseres Beispiel ist vielleicht, da kommt einer rein und sagt, ich brauche eine Bento Fix, die 300 Gramm schwerer ist als eine NSP 49.
+
+Das ist nichts, wofür dieser Prozess notwendig ist, weil er sagt, im uruguayischen Markt, die wollen halt 5200 Gramm pro Quadratmeter haben. Das würde man sofort wieder ausschleusen und würde sagen, alles klar, geht in die Produktion und in die QS, Datenblatt wird erstellt, Antwort ist, stellen soll einen Artikelantrag.
+
+Das sind eher die treffenderen Beispiele. Und alles, was darüber hinausgeht, das läuft dann halt ein weiter.
+
+Aber das gehört eben zur Realität. Das waren in der Vergangenheit eher die Mehrzahl der Sachen, die da kommen. Die Mehrzahl der Sachen, die da kommen, sind irgendwelche Varianten von irgendwas und die willst du gleich wieder ausschleusen.
+
+Gut verstanden.
+
+Oder was auch noch ein typisches Beispiel ist, was wir immer getrennt haben, da kommt irgendwer an und will ein Prüfzeugnis nach irgendeiner obskuren Norm für irgendeinen Markt haben.
+
+Das hat in der Entwicklung nichts zu tun, nichts zu suchen. Das geht dann entweder über Prüfkosten oder wenn es von allgemeiner Natur ist, geht es vielleicht noch über PM.
+
+Wenn ich irgendwelche Prüfungen machen muss, um nachzuweisen, dass eine Bento-Fix auch im Gartenbau anwendbar ist, dann geht es in der Regel über PM.
+
+Das ist ja keine Entwicklung, auch wenn es Versuche sind, die dahinter stehen. Es ist halt einfach nur, um einen bestimmten Markt zu bedienen. Da kam das her.
+
+Okay, dann könnten wir prinzipiell
+
+sagen, okay, wenn wir jetzt
+
+Aufgaben verteilen wollen, könnten wir sagen,
+
+dann lasst uns doch mal für diese verschiedenen Sachen Filterkriterien
+
+definieren. Was ist zu berücksichtigen?
+
+Wenn wir über Neues, über neue Anwendungen oder Produkte oder andersrum, wenn wir für über Anwendungen und Produkte reden oder für über Marketingaktionen, für bestehende Märkte und Marktsegmente oder für neue Märkte und neue Marktsegmente.
+
+Ja, genau das wollte ich, das konnte ich vielleicht vorhin nicht rüberbringen, genau das meine ich. Also diese Dinger, die müssen dann jetzt für die verschiedenen Dinge, da müssen eine Handvoll an relativ, im ersten Schritt relativ leicht zu hinterfragenden oder zu erfragenden Filterkriterien hin.
+
+Und vielleicht gibt es auch so ganz allgemeine, die oben drüber stehen. Wenn ich jetzt mal nur mal als Beispiel diese 5 Millionen in 5 Jahren, das ist ja eine sehr allgemeine Anforderung, die kann ja ganz oben drüber stehen. Ob die jetzt, also ob die in ihrer Wortwahl relevant ist oder nicht, sei mal dahingestellt, aber sowas kann da drüber sein.

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_06_changes.json

@@ -0,0 +1,196 @@
+{
+  "source_file": "chunk_06.txt",
+  "output_file": "chunk_06_normalized.txt",
+  "blocks_total": 92,
+  "blocks_changed": 24,
+  "policy": {
+    "removed": [
+      "isolated filler sounds such as äh, ähm, hm, mhm",
+      "immediate duplicate words",
+      "immediate duplicate phrases of two to four words",
+      "redundant whitespace"
+    ],
+    "explicitly_preserved": [
+      "negations",
+      "modal words and qualifiers",
+      "dates, times, numbers and quantities",
+      "technical statements",
+      "responsibilities",
+      "deadlines",
+      "decisions and commitments"
+    ],
+    "principle": "When uncertain, leave the text unchanged."
+  },
+  "changes": [
+    {
+      "block_number": 3,
+      "original": "Und ich denke, ob dann noch Punkte fehlen, die wir abfragen müssen,",
+      "normalized": "Und ich denke, ob dann noch Punkte fehlen, die wir abfragen müssen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 8,
+      "original": "Und das dann zu ergänzen, ohne dass das im WeFlow ist,",
+      "normalized": "Und das dann zu ergänzen, ohne dass das im WeFlow ist",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 9,
+      "original": "sondern einfach, weil wir die Datei, die hinterlegt ist, anpassen,",
+      "normalized": "sondern einfach, weil wir die Datei, die hinterlegt ist, anpassen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 12,
+      "original": "Und wir dürfen die, also die Sachen, die wir intern machen,",
+      "normalized": "Und wir dürfen die, also die Sachen, die wir intern machen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 13,
+      "original": "die sind da noch ein bisschen anders,",
+      "normalized": "die sind da noch ein bisschen anders",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 15,
+      "original": "Aber die Sachen, die so von weiter außen kommen,",
+      "normalized": "Aber die Sachen, die so von weiter außen kommen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 22,
+      "original": "Also wenn ein Raik anruft und du schickst den, na Raik ist ein schlechtes Beispiel,",
+      "normalized": "Also wenn ein Raik anruft und du schickst den, na Raik ist ein schlechtes Beispiel",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 24,
+      "original": "Ja, oder auch wenn Herr Peter eine Idee hat und bei mir, also ich sage jetzt mal, wenn Greenline bei mir anrufen würde, würde ich ja niemals sagen, ja nee, so, aber nicht, Sportsfreund. Das wird ja einfach nicht passieren, sondern dann würde ich das ausfüllen und in den Ideenpool einfließen. Aber wichtig ist halt, dass wir dafür sorgen, dass das konsequent so gemacht wird, weil ansonsten fahren wir wieder zweigleisig und lösen das Problem letztendlich nicht. Das heißt, die Durchsetzung, die Umsetzung ist das Entscheidende am Schluss.",
+      "normalized": "Ja, oder auch wenn Herr Peter eine Idee hat und bei mir, also ich sage jetzt mal, wenn Greenline bei mir anrufen würde ich ja niemals sagen, ja nee, so, aber nicht, Sportsfreund. Das wird ja einfach nicht passieren, sondern dann würde ich das ausfüllen und in den Ideenpool einfließen. Aber wichtig ist halt, dass wir dafür sorgen, dass das konsequent so gemacht wird, weil ansonsten fahren wir wieder zweigleisig und lösen das Problem letztendlich nicht. Das heißt, die Durchsetzung, die Umsetzung ist das Entscheidende am Schluss.",
+      "removed_fillers": [],
+      "duplicate_reductions": [
+        "würde, würde"
+      ]
+    },
+    {
+      "block_number": 31,
+      "original": "Das ist unsere Aufgabe, dafür zu sorgen,",
+      "normalized": "Das ist unsere Aufgabe, dafür zu sorgen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 32,
+      "original": "dass wir nicht an tausend Stellen im Unternehmen irgendwas lostreten,",
+      "normalized": "dass wir nicht an tausend Stellen im Unternehmen irgendwas lostreten",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 35,
+      "original": "Dass der initiale Aufhänger in der F&E liegt,",
+      "normalized": "Dass der initiale Aufhänger in der F&E liegt",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 36,
+      "original": "ist eine rein organisatorische Festlegung,",
+      "normalized": "ist eine rein organisatorische Festlegung",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 39,
+      "original": "erfolgt grundsätzlich unter Einbindung der Kompetenz,",
+      "normalized": "erfolgt grundsätzlich unter Einbindung der Kompetenz",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 46,
+      "original": "Ziel ist die Koordination und Beschleunigung und Strukturierung und Kontextualisierung aller relevanter, größerer Projekte im Unternehmen,",
+      "normalized": "Ziel ist die Koordination und Beschleunigung und Strukturierung und Kontextualisierung aller relevanter, größerer Projekte im Unternehmen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 49,
+      "original": "Ein Projekt wandert also direkt wieder in Business Development, Marketing, PM, EDD oder Logistik,",
+      "normalized": "Ein Projekt wandert also direkt wieder in Business Development, Marketing, PM, EDD oder Logistik",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 53,
+      "original": "verschiedenen Fälle, hier oben,",
+      "normalized": "verschiedenen Fälle, hier oben",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 56,
+      "original": "und vermutlich regelmäßig auftauchen,",
+      "normalized": "und vermutlich regelmäßig auftauchen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 63,
+      "original": "Ich war eben ein bisschen verunsichert,",
+      "normalized": "Ich war eben ein bisschen verunsichert",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 64,
+      "original": "als Malte sagte,",
+      "normalized": "als Malte sagte",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 65,
+      "original": "von wegen der Anschaffung von irgendwelchen Gabenstapler-Sachen,",
+      "normalized": "von wegen der Anschaffung von irgendwelchen Gabenstapler-Sachen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 68,
+      "original": "Wir wollen diese, es gibt bei uns im Haus, wir haben jetzt, wir würden eine Chance,",
+      "normalized": "Wir wollen diese, es gibt bei uns im Haus, wir haben jetzt, wir würden eine Chance",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 69,
+      "original": "also das haben Malte und ich uns in die Augen geholt, wir würden jetzt hier gerne eine Chance ergreifen,",
+      "normalized": "also das haben Malte und ich uns in die Augen geholt, wir würden jetzt hier gerne eine Chance ergreifen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 71,
+      "original": "Also wenn sowas da reinkommt, das wäre dann zum Beispiel der Gabelstapler oder so,",
+      "normalized": "Also wenn sowas da reinkommt, das wäre dann zum Beispiel der Gabelstapler oder so",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 87,
+      "original": "Aufgaben verteilen wollen, könnten wir sagen,",
+      "normalized": "Aufgaben verteilen wollen, könnten wir sagen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    }
+  ]
+}

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_06_normalized.txt

@@ -0,0 +1,183 @@
+Okay, ich hoffe, ich habe die Punktale.
+
+Ich habe ein bisschen mit.
+
+Und ich denke, ob dann noch Punkte fehlen, die wir abfragen müssen
+
+das wird auch einfach die Zeit zeigen.
+
+Das würde ich jetzt nicht im Vorhinein versuchen, alles zu planen.
+
+Ich denke, wir werden relativ schnell nach zwei, drei, vier Terminen
+
+und nach 10, 15 Projekten merken, wo was fehlt und was nicht.
+
+Und das dann zu ergänzen, ohne dass das im WeFlow ist
+
+sondern einfach, weil wir die Datei, die hinterlegt ist, anpassen
+
+spricht von meinem Verständnis nichts gegen.
+
+Und das macht das flexibler.
+
+Und wir dürfen die, also die Sachen, die wir intern machen
+
+die sind da noch ein bisschen anders
+
+weil wir einen anderen Anspruch haben und auch eine andere Motivation.
+
+Aber die Sachen, die so von weiter außen kommen
+
+die haben keine Lust, 20 Seiten zu füllen
+
+und irgendwie stundenlang zu recherchieren.
+
+Da wird es immer dabei bleiben, dass die irgendwie anrufen und was absetzen
+
+oder in eine fünfzeilige E-Mail schicken mit irgendeinem Vorschlag im weitesten Sinne.
+
+Und da wird es auch immer so sein, dass dann einer quasi das für diese Person ausfüllt und anreichert.
+
+Sonst geht auch zu viel verloren.
+
+Also wenn ein Raik anruft und du schickst den, na Raik ist ein schlechtes Beispiel
+
+Aber wenn dann einer der durchschnittliche Vertriebler anruft und versucht, bei irgendwem das loszulassen, dann ist die Antwort nicht, schreib das ordentlich auf, wie hast du die Vorlage, das wird nämlich in den seltensten Fällen passieren, sondern dann ist eigentlich die Antwort, ruf mal bei James an, der geht mit dir die fünf Fragen durch und schweißt das dann ein.
+
+Ja, oder auch wenn Herr Peter eine Idee hat und bei mir, also ich sage jetzt mal, wenn Greenline bei mir anrufen würde ich ja niemals sagen, ja nee, so, aber nicht, Sportsfreund. Das wird ja einfach nicht passieren, sondern dann würde ich das ausfüllen und in den Ideenpool einfließen. Aber wichtig ist halt, dass wir dafür sorgen, dass das konsequent so gemacht wird, weil ansonsten fahren wir wieder zweigleisig und lösen das Problem letztendlich nicht. Das heißt, die Durchsetzung, die Umsetzung ist das Entscheidende am Schluss.
+
+Ja, ich habe mal, wie gesagt, ein bisschen versucht mitzuschreiben, die verschiedenen Argumente.
+
+Jörn, lass uns mal hier zusammen drauf gucken, ob wir das so stehen lassen können.
+
+Also wir prüfen gerade, ob der bestehende Prozess an die allgemeineren Projekte angepasst und adaptiert werden könnte.
+
+Vom Grundsatz her sehen wir das als gegeben, da die Grundsätze eines Projektablaufs und das ist, glaube ich, dass Grundsätze Projektauslauf auch für strategische und Business Development Projekte gelten. Einige grundlegende Schritte sind ohne Anspruch auf Vollständigkeit.
+
+Filterkriterien, Festlegung relevante und einzubindende Abteilung, Definition Lastenhaft, Prüfkriterien, Entscheidungskriterien, Abschätzung Budget, Projektverantwortung, Projektablauf, Milestones, Projektfreigabe, Rückstellung und Ablehnung erwirken, Festlegung Priorität in Abstimmung im Gremium und mit GF.
+
+Das ist am Ende des Tages ja das, was wir wollen.
+
+Das ist unsere Aufgabe, dafür zu sorgen
+
+dass wir nicht an tausend Stellen im Unternehmen irgendwas lostreten
+
+wo hinterher keiner mehr weiß, wo sind eigentlich die losen Enden
+
+und mit welcher Priorität soll ich an welchem Ende zuppeln.
+
+Dass der initiale Aufhänger in der F&E liegt
+
+ist eine rein organisatorische Festlegung
+
+um gebündelt alle Projektideen zu erfassen.
+
+Die Ausarbeitung, Abstimmung und Entscheidung
+
+erfolgt grundsätzlich unter Einbindung der Kompetenz
+
+grundsätzlich unter Einbindung der Fachbereiche.
+
+F&E übte ja eine rein verwaltende Tätigkeit mit dem Zusammentragen weniger Grundlagen aus, sonst nichts.
+
+Grundsätzlich könnte diese Stelle auch direkt im Sekretariat GF, Business Development oder sonst wo im kaufmännischen Bereich liegen.
+
+Da aber die schlichte Mehrzahl der Projekte physischer und struktureller Ideen vermutlich sein wird, sehen wir diese benannte Aufräumstelle als gut gewählt.
+
+Das können wir aber auch nach einer gewissen Zeit hinterfragen und gegebenenfalls ändern.
+
+Wir sehen da keine zwingende Notwendigkeit, das im FE zu belassen, wenn wir eine besser geeignete Stelle finden sollten.
+
+Ziel ist die Koordination und Beschleunigung und Strukturierung und Kontextualisierung aller relevanter, größerer Projekte im Unternehmen
+
+um die Losen zu begrenzen und Kapazitäten zu effizient nutzen.
+
+So, das ist unser Auftrag.
+
+Ein Projekt wandert also direkt wieder in Business Development, Marketing, PM, EDD oder Logistik
+
+wenn die Projekte dorthin gehören. Die Zwischenstufe Projekt dient also nur Sicherstellung, dass die Felder angewendet werden und es einen Überblick über die Gesamtheit der Projekte gibt mit Einstellungsdruck der Relevanz.
+
+Wir sollten also den bestehenden Rahmen nutzen und erweitern auf unsere Bedürfnisse, anpassen, aber immer im Rahmen nau als Mittelständler und uns keine komplexen Zusatzprozesse schaffen.
+
+Aufgehegabe wäre also die Definition von Filterkriterien für die
+
+verschiedenen Fälle, hier oben
+
+die wir
+
+für relevant sehen, die wir für relevant halten
+
+und vermutlich regelmäßig auftauchen
+
+nicht für irgendwelche Edge Cases. Hier oben, das kann man jetzt noch farblich hinterlegen.
+
+Das ist nämlich hier.
+
+Fasst das die Diskussion im Moment erstmal zusammen?
+
+Ist das auch unsere gemeinsame Meinung?
+
+Ja.
+
+Ja, da stehe ich voll zu.
+
+Ich war eben ein bisschen verunsichert
+
+als Malte sagte
+
+von wegen der Anschaffung von irgendwelchen Gabenstapler-Sachen
+
+weil das sehe ich halt überhaupt gar nicht.
+
+Ja, pass auf, das war nur ein Beispiel.
+
+Wir wollen diese, es gibt bei uns im Haus, wir haben jetzt, wir würden eine Chance
+
+also das haben Malte und ich uns in die Augen geholt, wir würden jetzt hier gerne eine Chance ergreifen
+
+um auch Dinge abzufangen, die eher in den Bereich betriebliche Verbesserungsvorschläge fallen.
+
+Also wenn sowas da reinkommt, das wäre dann zum Beispiel der Gabelstapler oder so
+
+der würde halt ganz am Anfang wieder ausgeschleust.
+
+Der kommt da rein und dann wird festgestellt, da geht es um, sag ich mal, einen betrieblichen Verbesserungsvorschlag.
+
+Team-Ebene oder so, ja.
+
+Das geht dann sofort in den Prozess Verbesserungsvorschlag oder das geht direkt in, keine Ahnung, direkt in die Produktion. Das machen die einfach fertig.
+
+Also es gibt so Projektideen. Da kommt einer, ein besseres Beispiel ist vielleicht, da kommt einer rein und sagt, ich brauche eine Bento Fix, die 300 Gramm schwerer ist als eine NSP 49.
+
+Das ist nichts, wofür dieser Prozess notwendig ist, weil er sagt, im uruguayischen Markt, die wollen halt 5200 Gramm pro Quadratmeter haben. Das würde man sofort wieder ausschleusen und würde sagen, alles klar, geht in die Produktion und in die QS, Datenblatt wird erstellt, Antwort ist, stellen soll einen Artikelantrag.
+
+Das sind eher die treffenderen Beispiele. Und alles, was darüber hinausgeht, das läuft dann halt ein weiter.
+
+Aber das gehört eben zur Realität. Das waren in der Vergangenheit eher die Mehrzahl der Sachen, die da kommen. Die Mehrzahl der Sachen, die da kommen, sind irgendwelche Varianten von irgendwas und die willst du gleich wieder ausschleusen.
+
+Gut verstanden.
+
+Oder was auch noch ein typisches Beispiel ist, was wir immer getrennt haben, da kommt irgendwer an und will ein Prüfzeugnis nach irgendeiner obskuren Norm für irgendeinen Markt haben.
+
+Das hat in der Entwicklung nichts zu tun, nichts zu suchen. Das geht dann entweder über Prüfkosten oder wenn es von allgemeiner Natur ist, geht es vielleicht noch über PM.
+
+Wenn ich irgendwelche Prüfungen machen muss, um nachzuweisen, dass eine Bento-Fix auch im Gartenbau anwendbar ist, dann geht es in der Regel über PM.
+
+Das ist ja keine Entwicklung, auch wenn es Versuche sind, die dahinter stehen. Es ist halt einfach nur, um einen bestimmten Markt zu bedienen. Da kam das her.
+
+Okay, dann könnten wir prinzipiell
+
+sagen, okay, wenn wir jetzt
+
+Aufgaben verteilen wollen, könnten wir sagen
+
+dann lasst uns doch mal für diese verschiedenen Sachen Filterkriterien
+
+definieren. Was ist zu berücksichtigen?
+
+Wenn wir über Neues, über neue Anwendungen oder Produkte oder andersrum, wenn wir für über Anwendungen und Produkte reden oder für über Marketingaktionen, für bestehende Märkte und Marktsegmente oder für neue Märkte und neue Marktsegmente.
+
+Ja, genau das wollte ich, das konnte ich vielleicht vorhin nicht rüberbringen, genau das meine ich. Also diese Dinger, die müssen dann jetzt für die verschiedenen Dinge, da müssen eine Handvoll an relativ, im ersten Schritt relativ leicht zu hinterfragenden oder zu erfragenden Filterkriterien hin.
+
+Und vielleicht gibt es auch so ganz allgemeine, die oben drüber stehen. Wenn ich jetzt mal nur mal als Beispiel diese 5 Millionen in 5 Jahren, das ist ja eine sehr allgemeine Anforderung, die kann ja ganz oben drüber stehen. Ob die jetzt, also ob die in ihrer Wortwahl relevant ist oder nicht, sei mal dahingestellt, aber sowas kann da drüber sein.

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_07.txt

@@ -0,0 +1,323 @@
+Ich würde nur bitten, wenn das noch dazu gehört, dass das James und David machen, dann bitte keine unendlich lange Liste, sondern wirklich, keine Ahnung, drei bis fünf, vielleicht sechs Sachen, die auch in einem angemessenen Rahmen zwischen dem Ideengeber und denen, die das zu hinterfragen haben, beantwortbar sind.
+
+Also ich...
+
+Und das können wir ja danach belieben zu dem Projekt ergänzen. Ich muss gestehen, ich sehe keine Notwendigkeit, das davor zu packen. Wir verkomplizieren den Ablauf, meiner Meinung nach.
+
+Also das könnte man auch einfach in dem Gremium sagen, okay, das ist jetzt Projekt XY, hier sollten wir uns vielleicht nochmal 1, 2, 3 angucken. Das ist ein BD-Projekt. David Cashman sagt, Giovanna soll dafür verantwortlich sein. Bitte, bevor wir da jetzt tief einsteigen, prüft doch erstmal das, das, das, um da tiefer einzusteigen.
+
+Völlig einverstanden. Also ich denke, es gibt Kriterien, die sind sehr allgemein. Bis jetzt gibt es die generelle Ansage, wir machen keine Teppiche für Autos, weil wir das einfach nicht machen. Punkt.
+
+So was kann im Grunde oben schon als Filterkriterium ganz oben drüber sein, nämlich bei diesem Lateral und so weiter und so fort.
+
+Passt nicht zur Strategie. Ist mal festgelegt worden, kommt von oben.
+
+Die Sachen können wir vorher abfragen. Aber du hast natürlich völlig recht.
+
+Keiner von uns hat eine Kompetenz hinreichend, um dann auf der Mikroebene in einer anderen Abteilung zu entscheiden, ob das Projekt sinnvoll ist oder nicht.
+
+Das muss in der entsprechenden Abteilung passieren.
+
+Auf der anderen Seite fällt mir gerade ein,
+
+die müssen das ja auch jeweils der GF für das Budget am Ende klar machen.
+
+Also das erledigt sich dann auch von selbst.
+
+Ja, es ist schwierig. Es ist schwierig zu entscheiden und es ist für mich noch nicht klar, an welcher Stelle geht ein Projekt in diesen Topf und an welcher Stelle nicht.
+
+an welcher Stelle entscheidet Björn einfach,
+
+ich mache das jetzt so und Produktmanagement entscheidet,
+
+ich will dieses Produkt und Business Development entscheidet,
+
+wir kümmern uns um diesen Markt
+
+und Logistik entscheidet, ich will das hier optimiert haben
+
+oder Produktion.
+
+Das ist mir noch nicht klar.
+
+letztendlich ist das eigentlich
+
+Geschäftsführungsaufgabe, den Überblick
+
+über die Projekte im Haus zu behalten.
+
+Wir können eigentlich jetzt nur
+
+unterstützen, indem wir sozusagen für
+
+einige Produkte oder
+
+für einige Projekte den Topf
+
+erweitern, den F&E-Topf,
+
+weil der war ja mal genau dafür da
+
+und genau diesen Job erfüllt er auch,
+
+dass es seitdem einen
+
+Überblick gibt, an was wird
+
+eigentlich alles gearbeitet im Bereich
+
+F&E und PM.
+
+Deswegen ist der Topf ja auch nach wie vor gemeinsam geführt, was ich immer noch für richtig und auch gut halte und nicht zerstückelt, dass der in diesem Fall bei dir zusammenläuft.
+
+Aber das haben wir halt nur für diese beiden Abteilungen, weil sich das historisch so entwickelt hat. Das haben wir eben für die ganzen anderen Projekte nicht.
+
+Aber vielleicht nochmal kurz als Reaktion darauf. Wir fragen ja ab, ist die Idee abteilungsübergreifend strategisch relevant oder ist ein Budget notwendig? Und wenn das nicht zutrifft, dann geht das ja eh einfach zurück auf Team- oder Abteilungsebene.
+
+dann schafft es gar nicht
+
+den Schritt von Ideenpool
+
+zu Projektliste
+
+und diese Projektliste
+
+die besprechen wir, so hatten wir es festgehalten
+
+in diesem Meeting
+
+das heißt da sind eh alle am Tisch
+
+das heißt es entscheidet niemand selbst
+
+sondern das Gremium
+
+in dem Fall
+
+also natürlich wird man natürlich sagen
+
+wenn Giovanna jetzt sagt ich hab hier die und die Idee
+
+wir wollen das und das machen
+
+dann kann sie das ja trotzdem machen
+
+Aber sie muss ja am Schluss dann trotzdem durch die klassischen Kriterien für ein Projekt durch und kriegt dein Budget oder nicht, wie Martin schon sagte.
+
+Das ist auch ein bisschen, es geht nicht stringent von oben nach unten, weil du mit dem Ansteigen an Wissen wirst du Sachen möglicherweise nochmal anders beurteilen.
+
+Also was als erstes als gute Idee anfängt und in einer der Fachabteilungen landet und die reichert dann die Informationen an, da kann ja dann ein Stoppschild auftauchen.
+
+eigentlich brauchst du an der Stelle
+
+ein zweites Review
+
+also wenn die Daten
+
+so weit angereichert sind, dass man sagt
+
+mehr kriege ich jetzt hier wirklich nicht zusammen
+
+dann braucht es eigentlich ein zweites Review
+
+was sagt, erfülle ich mindestens
+
+meine Umsatzerwartung oder
+
+greife ich damit
+
+ein geschäftliches Risiko an, das waren ja
+
+die Dinge, die wir mal festgelegt haben
+
+also erreiche ich einen gewissen Umsatz
+
+ist es
+
+sozusagen
+
+auch wenn das mich nur Geld kostet, aber ich muss irgendwelche außenstehenden Regularien erfüllen
+
+oder ist es etwas, was ich aus Überzeugung tun will oder was auch immer.
+
+Dieses zweite Review musst du eigentlich dann nochmal machen.
+
+Das kannst du ja nicht von oben machen, wenn du sagst,
+
+ich will nur eine begrenzte Anzahl Informationen initial abfragen.
+
+Aber das ist ganz normales Projektmanagement. Das machen wir ja. Wir versuchen am Anfang, also das mache ich bei mir in der Abteilung, am Anfang versuche ich bestmöglich zu erraten mit auf Basis der mir zur Verfügung stehenden Daten, ob dieses Projekt eine Erfolgschanze hat im weitesten Sinne.
+
+Und wenn ich dann nach vier Wochen investierter Arbeit feststelle, das geht in eine Richtung, die habe ich vorher nicht gesehen, dann ist an der Stelle eben Projektabbruch oder mehr Ressourcen investieren oder sagen, auf die Schulter klopfen war genau die richtige Entscheidung.
+
+Aber das ist ja dann Projektmanagement in dem eigentlichen Projekt und das muss dann wieder jeder selbst beurteilen. Ich kann ja nicht beurteilen, ob Jörns Marketingstrategie erfolgreich läuft oder nicht oder die richtigen Leute adressiert.
+
+ist mir noch nicht klar, ob das eindeutig ist
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+Okay, andere Variante wäre, wir versuchen wirklich eine Handvoll Kriterien, ganz harte Kriterien,
+
+wie eben diese Strategiekonformität und so weiter, wirklich ganz nach oben zu setzen.
+
+Da werden wir immer sagen, lass es uns erst mal genau angucken und dann gucken wir, ob das passt oder ob das nicht passt.
+
+Das ist ohnehin nicht trennscharf.
+
+Das ist ja auch nur eine To-Do-Liste hier.
+
+für neue Marktsegmente
+
+ist natürlich auch, muss BM eingebunden sein, das müssen sie alle machen
+
+das heißt nicht, dass die jetzt hier alleine
+
+für irgendwas zuständig sind, sondern wer kümmert sich jetzt mal
+
+darum, ein paar Prüfsteine zu definieren
+
+so habe ich das jetzt eigentlich gelesen, Björn, eigentlich müsste man
+
+weil das kann ja wieder nicht irgendwer machen
+
+irgendwer muss ja mal anfangen mit der Arbeit
+
+Das ist jetzt nur
+
+Guido
+
+stellvertretend
+
+für alle
+
+einzubindenden
+
+Fachbereiche, damit das
+
+keiner falsch versteht.
+
+Dann eindeutiger?
+
+Weil irgendwer
+
+muss ja mal anfangen und dann müssen wir
+
+die Sachen dann ja sowieso
+
+diskutieren.
+
+Finde ich unfassbar schwierig.
+
+Wenn eine kleine Produktmodifikation
+
+hier durchläuft und kaum was kostet
+
+und kaum was, also
+
+es gibt, mir fallen direkt einfach viele Punkte
+
+ein, wo ich denke,
+
+das sind wieder, wie hattest du es
+
+vorhin genannt, Edge Cases oder
+
+wird man Ausnahmen machen und so weiter.
+
+Ich denke, es macht nur Sinn,
+
+sowas wirklich auszuformulieren,
+
+wenn man es auch anwenden kann.
+
+Ich tue mich da gedanklich einfach gerade schwer.
+
+Ja, natürlich, ja.
+
+Ja, also wenn wir für das gesamte Unternehmen, den Anspruch hätten hier für das gesamte Unternehmen,
+
+ein Projektmanagement zu betreiben, dann bräuchten wir die Fachabteilungen nicht.
+
+Das kann nicht Sinn der Sache sein, dann wären es reine Fachabteilungen,
+
+aber die Abteilungen würden ja überhaupt kein Projektmanagement mehr machen
+
+oder nicht mehr eigenverantwortlich entscheiden können, dass sie sich darum kümmern,
+
+eine Anlage zu optimieren oder dass wir einen neuen Bemessungsansatz erarbeiten
+
+oder einen alten optimieren.
+
+Das kann nichts in der Sache sein.
+
+Es muss um die großen Strategiethemen gehen.
+
+Ja, die haben wir auch drin, ja.
+
+Naja, es ist Strategie von Konform haben wir drin.
+
+Und sind verschiedene Abteilungen eingebunden
+
+oder es ist erstmal abteilungsintern.
+
+gehört es zum Aufgaben
+
+oder gehört es
+
+zur Kernaufgabe?
+
+Ich weiß es noch nicht.
+
+Jetzt können wir natürlich sagen, ja natürlich gehört es zu unserer
+
+vordefinierten Kernaufgabe, auch ein neues Produkt zu entwickeln.
+
+und das machen wir zusammen mit F&E und fertig.
+
+Und Business Development und Marketing brauchen wir dafür sowieso nicht.
+
+Jetzt sagt Marketing, aber ihr habt ja aber vorher dran gedacht,
+
+ich habe da doch Fragen zu.
+
+Und Business Development sagt, wo ist denn euer Markt?
+
+Den gibt es doch gar nicht, habt ihr das abgeklopft?
+
+Das wird wirklich schwer.
+
+Für welche Projekte wollen wir dieses übergeordnete Projektmanagement,
+
+diesen Zusatz gern machen?
+
+und für welche wollen wir das nicht.
+
+Aber glaubst du nicht, dass wenn wir in einer Runde sitzen
+
+und die zusammengetragenen Informationen lesen,

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_07_changes.json

@@ -0,0 +1,155 @@
+{
+  "source_file": "chunk_07.txt",
+  "output_file": "chunk_07_normalized.txt",
+  "blocks_total": 162,
+  "blocks_changed": 18,
+  "policy": {
+    "removed": [
+      "isolated filler sounds such as äh, ähm, hm, mhm",
+      "immediate duplicate words",
+      "immediate duplicate phrases of two to four words",
+      "redundant whitespace"
+    ],
+    "explicitly_preserved": [
+      "negations",
+      "modal words and qualifiers",
+      "dates, times, numbers and quantities",
+      "technical statements",
+      "responsibilities",
+      "deadlines",
+      "decisions and commitments"
+    ],
+    "principle": "When uncertain, leave the text unchanged."
+  },
+  "changes": [
+    {
+      "block_number": 4,
+      "original": "Also das könnte man auch einfach in dem Gremium sagen, okay, das ist jetzt Projekt XY, hier sollten wir uns vielleicht nochmal 1, 2, 3 angucken. Das ist ein BD-Projekt. David Cashman sagt, Giovanna soll dafür verantwortlich sein. Bitte, bevor wir da jetzt tief einsteigen, prüft doch erstmal das, das, das, um da tiefer einzusteigen.",
+      "normalized": "Also das könnte man auch einfach in dem Gremium sagen, okay, das ist jetzt Projekt XY, hier sollten wir uns vielleicht nochmal 1, 2, 3 angucken. Das ist ein BD-Projekt. David Cashman sagt, Giovanna soll dafür verantwortlich sein. Bitte, bevor wir da jetzt tief einsteigen, prüft doch erstmal das, um da tiefer einzusteigen.",
+      "removed_fillers": [],
+      "duplicate_reductions": [
+        "das, das",
+        "das, das"
+      ]
+    },
+    {
+      "block_number": 11,
+      "original": "Auf der anderen Seite fällt mir gerade ein,",
+      "normalized": "Auf der anderen Seite fällt mir gerade ein",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 15,
+      "original": "an welcher Stelle entscheidet Björn einfach,",
+      "normalized": "an welcher Stelle entscheidet Björn einfach",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 16,
+      "original": "ich mache das jetzt so und Produktmanagement entscheidet,",
+      "normalized": "ich mache das jetzt so und Produktmanagement entscheidet",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 17,
+      "original": "ich will dieses Produkt und Business Development entscheidet,",
+      "normalized": "ich will dieses Produkt und Business Development entscheidet",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 29,
+      "original": "erweitern, den F&E-Topf,",
+      "normalized": "erweitern, den F&E-Topf",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 31,
+      "original": "und genau diesen Job erfüllt er auch,",
+      "normalized": "und genau diesen Job erfüllt er auch",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 73,
+      "original": "Das kannst du ja nicht von oben machen, wenn du sagst,",
+      "normalized": "Das kannst du ja nicht von oben machen, wenn du sagst",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 93,
+      "original": "Okay, andere Variante wäre, wir versuchen wirklich eine Handvoll Kriterien, ganz harte Kriterien,",
+      "normalized": "Okay, andere Variante wäre, wir versuchen wirklich eine Handvoll Kriterien, ganz harte Kriterien",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 123,
+      "original": "ein, wo ich denke,",
+      "normalized": "ein, wo ich denke",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 127,
+      "original": "Ich denke, es macht nur Sinn,",
+      "normalized": "Ich denke, es macht nur Sinn",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 128,
+      "original": "sowas wirklich auszuformulieren,",
+      "normalized": "sowas wirklich auszuformulieren",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 132,
+      "original": "Ja, also wenn wir für das gesamte Unternehmen, den Anspruch hätten hier für das gesamte Unternehmen,",
+      "normalized": "Ja, also wenn wir für das gesamte Unternehmen, den Anspruch hätten hier für das gesamte Unternehmen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 134,
+      "original": "Das kann nicht Sinn der Sache sein, dann wären es reine Fachabteilungen,",
+      "normalized": "Das kann nicht Sinn der Sache sein, dann wären es reine Fachabteilungen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 136,
+      "original": "oder nicht mehr eigenverantwortlich entscheiden können, dass sie sich darum kümmern,",
+      "normalized": "oder nicht mehr eigenverantwortlich entscheiden können, dass sie sich darum kümmern",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 153,
+      "original": "Jetzt sagt Marketing, aber ihr habt ja aber vorher dran gedacht,",
+      "normalized": "Jetzt sagt Marketing, aber ihr habt ja aber vorher dran gedacht",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 158,
+      "original": "Für welche Projekte wollen wir dieses übergeordnete Projektmanagement,",
+      "normalized": "Für welche Projekte wollen wir dieses übergeordnete Projektmanagement",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 162,
+      "original": "und die zusammengetragenen Informationen lesen,",
+      "normalized": "und die zusammengetragenen Informationen lesen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    }
+  ]
+}

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_07_normalized.txt

@@ -0,0 +1,323 @@
+Ich würde nur bitten, wenn das noch dazu gehört, dass das James und David machen, dann bitte keine unendlich lange Liste, sondern wirklich, keine Ahnung, drei bis fünf, vielleicht sechs Sachen, die auch in einem angemessenen Rahmen zwischen dem Ideengeber und denen, die das zu hinterfragen haben, beantwortbar sind.
+
+Also ich...
+
+Und das können wir ja danach belieben zu dem Projekt ergänzen. Ich muss gestehen, ich sehe keine Notwendigkeit, das davor zu packen. Wir verkomplizieren den Ablauf, meiner Meinung nach.
+
+Also das könnte man auch einfach in dem Gremium sagen, okay, das ist jetzt Projekt XY, hier sollten wir uns vielleicht nochmal 1, 2, 3 angucken. Das ist ein BD-Projekt. David Cashman sagt, Giovanna soll dafür verantwortlich sein. Bitte, bevor wir da jetzt tief einsteigen, prüft doch erstmal das, um da tiefer einzusteigen.
+
+Völlig einverstanden. Also ich denke, es gibt Kriterien, die sind sehr allgemein. Bis jetzt gibt es die generelle Ansage, wir machen keine Teppiche für Autos, weil wir das einfach nicht machen. Punkt.
+
+So was kann im Grunde oben schon als Filterkriterium ganz oben drüber sein, nämlich bei diesem Lateral und so weiter und so fort.
+
+Passt nicht zur Strategie. Ist mal festgelegt worden, kommt von oben.
+
+Die Sachen können wir vorher abfragen. Aber du hast natürlich völlig recht.
+
+Keiner von uns hat eine Kompetenz hinreichend, um dann auf der Mikroebene in einer anderen Abteilung zu entscheiden, ob das Projekt sinnvoll ist oder nicht.
+
+Das muss in der entsprechenden Abteilung passieren.
+
+Auf der anderen Seite fällt mir gerade ein
+
+die müssen das ja auch jeweils der GF für das Budget am Ende klar machen.
+
+Also das erledigt sich dann auch von selbst.
+
+Ja, es ist schwierig. Es ist schwierig zu entscheiden und es ist für mich noch nicht klar, an welcher Stelle geht ein Projekt in diesen Topf und an welcher Stelle nicht.
+
+an welcher Stelle entscheidet Björn einfach
+
+ich mache das jetzt so und Produktmanagement entscheidet
+
+ich will dieses Produkt und Business Development entscheidet
+
+wir kümmern uns um diesen Markt
+
+und Logistik entscheidet, ich will das hier optimiert haben
+
+oder Produktion.
+
+Das ist mir noch nicht klar.
+
+letztendlich ist das eigentlich
+
+Geschäftsführungsaufgabe, den Überblick
+
+über die Projekte im Haus zu behalten.
+
+Wir können eigentlich jetzt nur
+
+unterstützen, indem wir sozusagen für
+
+einige Produkte oder
+
+für einige Projekte den Topf
+
+erweitern, den F&E-Topf
+
+weil der war ja mal genau dafür da
+
+und genau diesen Job erfüllt er auch
+
+dass es seitdem einen
+
+Überblick gibt, an was wird
+
+eigentlich alles gearbeitet im Bereich
+
+F&E und PM.
+
+Deswegen ist der Topf ja auch nach wie vor gemeinsam geführt, was ich immer noch für richtig und auch gut halte und nicht zerstückelt, dass der in diesem Fall bei dir zusammenläuft.
+
+Aber das haben wir halt nur für diese beiden Abteilungen, weil sich das historisch so entwickelt hat. Das haben wir eben für die ganzen anderen Projekte nicht.
+
+Aber vielleicht nochmal kurz als Reaktion darauf. Wir fragen ja ab, ist die Idee abteilungsübergreifend strategisch relevant oder ist ein Budget notwendig? Und wenn das nicht zutrifft, dann geht das ja eh einfach zurück auf Team- oder Abteilungsebene.
+
+dann schafft es gar nicht
+
+den Schritt von Ideenpool
+
+zu Projektliste
+
+und diese Projektliste
+
+die besprechen wir, so hatten wir es festgehalten
+
+in diesem Meeting
+
+das heißt da sind eh alle am Tisch
+
+das heißt es entscheidet niemand selbst
+
+sondern das Gremium
+
+in dem Fall
+
+also natürlich wird man natürlich sagen
+
+wenn Giovanna jetzt sagt ich hab hier die und die Idee
+
+wir wollen das und das machen
+
+dann kann sie das ja trotzdem machen
+
+Aber sie muss ja am Schluss dann trotzdem durch die klassischen Kriterien für ein Projekt durch und kriegt dein Budget oder nicht, wie Martin schon sagte.
+
+Das ist auch ein bisschen, es geht nicht stringent von oben nach unten, weil du mit dem Ansteigen an Wissen wirst du Sachen möglicherweise nochmal anders beurteilen.
+
+Also was als erstes als gute Idee anfängt und in einer der Fachabteilungen landet und die reichert dann die Informationen an, da kann ja dann ein Stoppschild auftauchen.
+
+eigentlich brauchst du an der Stelle
+
+ein zweites Review
+
+also wenn die Daten
+
+so weit angereichert sind, dass man sagt
+
+mehr kriege ich jetzt hier wirklich nicht zusammen
+
+dann braucht es eigentlich ein zweites Review
+
+was sagt, erfülle ich mindestens
+
+meine Umsatzerwartung oder
+
+greife ich damit
+
+ein geschäftliches Risiko an, das waren ja
+
+die Dinge, die wir mal festgelegt haben
+
+also erreiche ich einen gewissen Umsatz
+
+ist es
+
+sozusagen
+
+auch wenn das mich nur Geld kostet, aber ich muss irgendwelche außenstehenden Regularien erfüllen
+
+oder ist es etwas, was ich aus Überzeugung tun will oder was auch immer.
+
+Dieses zweite Review musst du eigentlich dann nochmal machen.
+
+Das kannst du ja nicht von oben machen, wenn du sagst
+
+ich will nur eine begrenzte Anzahl Informationen initial abfragen.
+
+Aber das ist ganz normales Projektmanagement. Das machen wir ja. Wir versuchen am Anfang, also das mache ich bei mir in der Abteilung, am Anfang versuche ich bestmöglich zu erraten mit auf Basis der mir zur Verfügung stehenden Daten, ob dieses Projekt eine Erfolgschanze hat im weitesten Sinne.
+
+Und wenn ich dann nach vier Wochen investierter Arbeit feststelle, das geht in eine Richtung, die habe ich vorher nicht gesehen, dann ist an der Stelle eben Projektabbruch oder mehr Ressourcen investieren oder sagen, auf die Schulter klopfen war genau die richtige Entscheidung.
+
+Aber das ist ja dann Projektmanagement in dem eigentlichen Projekt und das muss dann wieder jeder selbst beurteilen. Ich kann ja nicht beurteilen, ob Jörns Marketingstrategie erfolgreich läuft oder nicht oder die richtigen Leute adressiert.
+
+ist mir noch nicht klar, ob das eindeutig ist
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+...
+
+Okay, andere Variante wäre, wir versuchen wirklich eine Handvoll Kriterien, ganz harte Kriterien
+
+wie eben diese Strategiekonformität und so weiter, wirklich ganz nach oben zu setzen.
+
+Da werden wir immer sagen, lass es uns erst mal genau angucken und dann gucken wir, ob das passt oder ob das nicht passt.
+
+Das ist ohnehin nicht trennscharf.
+
+Das ist ja auch nur eine To-Do-Liste hier.
+
+für neue Marktsegmente
+
+ist natürlich auch, muss BM eingebunden sein, das müssen sie alle machen
+
+das heißt nicht, dass die jetzt hier alleine
+
+für irgendwas zuständig sind, sondern wer kümmert sich jetzt mal
+
+darum, ein paar Prüfsteine zu definieren
+
+so habe ich das jetzt eigentlich gelesen, Björn, eigentlich müsste man
+
+weil das kann ja wieder nicht irgendwer machen
+
+irgendwer muss ja mal anfangen mit der Arbeit
+
+Das ist jetzt nur
+
+Guido
+
+stellvertretend
+
+für alle
+
+einzubindenden
+
+Fachbereiche, damit das
+
+keiner falsch versteht.
+
+Dann eindeutiger?
+
+Weil irgendwer
+
+muss ja mal anfangen und dann müssen wir
+
+die Sachen dann ja sowieso
+
+diskutieren.
+
+Finde ich unfassbar schwierig.
+
+Wenn eine kleine Produktmodifikation
+
+hier durchläuft und kaum was kostet
+
+und kaum was, also
+
+es gibt, mir fallen direkt einfach viele Punkte
+
+ein, wo ich denke
+
+das sind wieder, wie hattest du es
+
+vorhin genannt, Edge Cases oder
+
+wird man Ausnahmen machen und so weiter.
+
+Ich denke, es macht nur Sinn
+
+sowas wirklich auszuformulieren
+
+wenn man es auch anwenden kann.
+
+Ich tue mich da gedanklich einfach gerade schwer.
+
+Ja, natürlich, ja.
+
+Ja, also wenn wir für das gesamte Unternehmen, den Anspruch hätten hier für das gesamte Unternehmen
+
+ein Projektmanagement zu betreiben, dann bräuchten wir die Fachabteilungen nicht.
+
+Das kann nicht Sinn der Sache sein, dann wären es reine Fachabteilungen
+
+aber die Abteilungen würden ja überhaupt kein Projektmanagement mehr machen
+
+oder nicht mehr eigenverantwortlich entscheiden können, dass sie sich darum kümmern
+
+eine Anlage zu optimieren oder dass wir einen neuen Bemessungsansatz erarbeiten
+
+oder einen alten optimieren.
+
+Das kann nichts in der Sache sein.
+
+Es muss um die großen Strategiethemen gehen.
+
+Ja, die haben wir auch drin, ja.
+
+Naja, es ist Strategie von Konform haben wir drin.
+
+Und sind verschiedene Abteilungen eingebunden
+
+oder es ist erstmal abteilungsintern.
+
+gehört es zum Aufgaben
+
+oder gehört es
+
+zur Kernaufgabe?
+
+Ich weiß es noch nicht.
+
+Jetzt können wir natürlich sagen, ja natürlich gehört es zu unserer
+
+vordefinierten Kernaufgabe, auch ein neues Produkt zu entwickeln.
+
+und das machen wir zusammen mit F&E und fertig.
+
+Und Business Development und Marketing brauchen wir dafür sowieso nicht.
+
+Jetzt sagt Marketing, aber ihr habt ja aber vorher dran gedacht
+
+ich habe da doch Fragen zu.
+
+Und Business Development sagt, wo ist denn euer Markt?
+
+Den gibt es doch gar nicht, habt ihr das abgeklopft?
+
+Das wird wirklich schwer.
+
+Für welche Projekte wollen wir dieses übergeordnete Projektmanagement
+
+diesen Zusatz gern machen?
+
+und für welche wollen wir das nicht.
+
+Aber glaubst du nicht, dass wenn wir in einer Runde sitzen
+
+und die zusammengetragenen Informationen lesen

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_08.txt

@@ -0,0 +1,335 @@
+dass wir das nicht direkt bewerten können,
+
+ohne dass wir jetzt Filterkriterien aufschreiben in dem Fall
+
+und das versuchen fortzunehmen?
+
+Aber wir werden doch nicht alle Projekte,
+
+die Frage ist ja erstmal, wer kommt denn mit welcher Liste
+
+und wer stellt denn welches Projekt in welchem Gremium?
+
+Sagen wir mal, wir werden hier das Gremium.
+
+zur Diskussion.
+
+Das hatten wir aber schon definiert.
+
+Das steht hier auch drin.
+
+Wir haben die Ideenliste.
+
+Das hatte ich
+
+verteilt vor zwei Wochen mit der Bitte.
+
+Diese
+
+genauen Punkte, die stehen hier alle
+
+drunter. Also Leiter F&E
+
+führt die Projektliste auf den zweiwöchentlichen
+
+Schnittstellen-Stand-Up. Das ist dieser Termin.
+
+Hier wird definiert, ob es sich ein
+
+F für Forschung, E-Entwicklung,
+
+PM- oder BD-Projekt handelt.
+
+So, hier wird die Projektleitung und alle in Kenntnis zu setzen Personen festgelegt. Zu dem Zeitpunkt ist es auch schon nach gewissen Kriterien kategorisiert. Es sind Vorfilter entlaufen und wenn wir hier einen Punkt haben, hier sind die Arten der Projekte, das hattet ihr vorher auch schon mal 2018 alles sehr gut ausgearbeitet. Hier haben wir noch ein paar Ergänzungen vorgenommen.
+
+So, und hier wird dann ja diskutiert, jetzt scrolle ich einmal hoch, priorisiert ist, wie weiter vorgegangen wird, weil ab dieser Projektliste, ab diesem Termin, wo es vorgestellt wird, wird jemandem der Hut aufgesetzt und hier zu sagen, okay, hier musst du bitte XY erst einmal prüfen oder gegebenenfalls einen Projektplan erstellen.
+
+und dann führst du das Projekt durch und gibst uns erstmal einen Zwischenbericht
+
+und dann geht es erneut durch diesen Kreislauf nochmal wieder durch.
+
+Also ich glaube, das wird einfach on the fly, wird man da relativ schnell erkennen,
+
+ob man bei einem Projekt noch zusätzliche Informationen braucht oder nicht.
+
+Das habt ihr damals sehr gut durchdacht.
+
+Ich glaube, wir verkomplizieren das wirklich in diesem Fall,
+
+weil in dieser Liste wird relativ schnell klar werden,
+
+okay, das hätten James und David vielleicht schon mal direkt an die Fachabteilung zurückgeben müssen.
+
+Das hätte vielleicht gar nicht hier landen sollen und so weiter und so fort.
+
+Und ich glaube, dass wir da relativ schnell ein Gefühl für entwickeln.
+
+Aber das ist nichts, was in diesem sehr oberflächlich groß gesehenen Prozess mit abgebildet werden muss.
+
+Und der Rest, das kann man schlecht vordefinieren.
+
+Ich würde wirklich sagen, lass uns dafür ein Gefühl entwickeln.
+
+Und wir können es ja im halben Jahr dann immer noch sagen,
+
+okay, beim BD-Projekt haben wir jetzt immer nach der und der Folie gefragt,
+
+weil Giovanna möchte das einfach für ihre Art von Projekten haben.
+
+So what? Bitte gerne einfach immer ihren Leuten, die den Hut aufsetzen, sagen,
+
+die Folie bitte auch immer ausfüllen.
+
+Da sehe ich kein großes Problem.
+
+Und du hast selber geschrieben, wir müssen es nicht zu komplex machen.
+
+Wir wollen ja auch flexibel bleiben.
+
+Und wenn wir das alles vorher abfragen oder noch eine Station vorher einbauen,
+
+weil wir sind jetzt schon bei einer Beantwortung,
+
+alleine weil der Termin nur alle zwei Wochen stattfindet,
+
+bei einer frühesten Beantwortung zum nächsten Termin.
+
+Also das macht ja auch schon langsam dann in dem Fall.
+
+Sorry, ich muss mich einmal kurz auf Abschieden,
+
+weil ich ganz dringend.
+
+Ansonsten, Lars, du schickst mir wahrscheinlich nachher
+
+einmal nochmal rum, ne?
+
+Ich schick das nochmal rum.
+
+Dankeschön, klar.
+
+Okay, tschüss dann.
+
+Ciao.
+
+Ja, ich sehe es auch so.
+
+Also je länger ich darüber nachdenke, das ist nicht Projekt, also das, was wir hier tun, ist nicht die konkrete Projektleitung. Wir geben vielleicht noch ein, zwei Sachen an die Hand, damit soweit das geht, in jeder Art von Projekt die gleichen Fragen nach den gleichen Kriterien beantwortet werden.
+
+Also ich würde mir gerne die Diskussion ersparen, warum ein Projekt ähnlicher Art in der F&E abgelehnt wurde, weil der ROI nicht gegeben ist, aber in Abteilung XY läuft sowas halt durch, weil die halt anders, einfach subjektiv anders gehandelt haben.
+
+da, wo das geht. Aber ansonsten, die Bearbeitung der Projekte
+
+muss und kann nur in den Fachabteilungen passieren.
+
+Also wir sagen nur grob, okay, wir wissen, was läuft eigentlich so,
+
+was ist reingekommen und wo ist es hingegangen?
+
+Und wer kriegt den Hut auf? Genau. Wo ist es hingegangen?
+
+Und wir sollten auch noch, da bin ich auch noch dabei,
+
+noch gucken, was draus geworden ist. Aber nur im Sinne von,
+
+läuft noch, gibt irgendwie einen großen Milestone,
+
+oder ist in der Fachabteilung eingestellt worden.
+
+Ja, das Bewerten der Ergebnisse ist auch wieder in dem Gremium.
+
+Beziehungsweise ist es hier jetzt in der F&E,
+
+weil es wieder zurückgespielt wird.
+
+Ja, da würde ich jetzt sagen, das würde ich ändern.
+
+Also hier steht.
+
+Ja, wo wir darüber sprechen,
+
+das passiert dann auch in der Abteilung,
+
+in Abstimmung mit der GF,
+
+wie das Ergebnis am Ende behandelt wird.
+
+Ich kann nicht, nochmal,
+
+ich kann nicht darüber entscheiden, ob ein Marketingprojekt
+
+erfolgreich gelaufen ist.
+
+Habe ich überhaupt gar keine Kompetenz für.
+
+Ja, oder auch...
+
+Ja.
+
+Ich denke,
+
+wir zwei scheinen uns auf jeden Fall ziemlich
+
+nicht so zu sein.
+
+Aber es wäre wertvoll, dass die
+
+Erkenntnis... Malte, teile mal bitte den Link von dem Miro.
+
+Ja, den hast du schon.
+
+Warte mal.
+
+Ja, ich kopiere den hier nochmal rein.
+
+weil Henning hat den nicht.
+
+Am Ende ist es immer hilfreich, ihn direkt vor Augen zu haben.
+
+Ja, mit Henning, also ich hatte das vor drei Wochen rumgeschickt
+
+oder vor vier Wochen mit der Bitte um Durchsicht
+
+und da hatte sich nur einer drauf gemeldet.
+
+Und also die ganzen Änderungen,
+
+ich habe das jetzt auch schon angestoßen dementsprechend.
+
+Ich sitze jetzt gleich halt schon mit Henning zusammen.
+
+Wenn ich das jetzt nochmal zurückziehen muss,
+
+dann müsste ich das auf jeden Fall wissen.
+
+Nein.
+
+Schmalte, mach das bitte mal
+
+in der Geschwindigkeit, wie wir das diskutieren.
+
+Und bevor Giovanna und Björn
+
+nicht gesagt haben, sie sind damit einverstanden,
+
+braucht Henning da überhaupt nichts tun
+
+und vor allem nicht einarbeiten.
+
+Wir hatten das aber durchgesprochen.
+
+Das sind keine neuen Ergebnisse,
+
+da sind keine Änderungen dran, die a,
+
+nicht vorher gemeinsam festgelegt wurden
+
+und b, nicht danach nochmal.
+
+Also Giovanna
+
+ist damit auf jeden Fall mal,
+
+hat es überhaupt noch nicht mitgekriegt und nicht verstanden,
+
+weil sie nämlich hier in der Mail, ihr habt sie vorhin gelesen,
+
+noch darüber nachdenkt, wie denn die Filterkriterien
+
+und wie so ein Projektablauf überhaupt aussehen sollte.
+
+Die ist noch überhaupt nicht auf dem Weg zu akzeptieren,
+
+dass dieser Prozess, den wir schon haben, der geeignete ist.
+
+Also die müssen wir da erstmal nochmal mitnehmen.
+
+Da bin ich jetzt ein bisschen bei Malte.
+
+Er hat das alles verteilt,
+
+alles ist angeschrieben worden, alle hatten die
+
+Gelegenheit, da reinzugucken
+
+und wenn da in vier Wochen nichts passiert ist.
+
+Also mindestens mal
+
+Giovanna und ich haben es
+
+nicht mitgekriegt und hatten keine Gelegenheit
+
+reinzugucken oder haben es
+
+für uns war es nicht klar und Björn
+
+offensichtlich auch nicht.
+
+Und wenn wir hier was bauen wollen, was
+
+für mindestens drei relevante Abteile
+
+im Haus relevant ist, dann
+
+nehmen wir uns halt die Zeit,
+
+bis es alle verstanden haben.
+
+Jetzt nützt es uns doch nichts.
+
+Also lass uns das jetzt hier nochmal
+
+so definieren.
+
+Ich suche es gerade raus.
+
+Dann schicke mir den Link, dann packe ich
+
+den hier mit rein.
+
+Ja,
+
+Die muss bereits jetzt im Prozess definiert.
+
+Hier würde ich jetzt den Link zum Miro nochmal reinkopieren, Walter.
+
+Ja, ich leite das gerade nochmal weiter.
+
+Hier ist der Link. Ich hatte es runtergeschrieben.
+
+Nochmals Link.
+
+ich kopiere deine mail auch noch mal rein in den ganzen chat
+
+das war alles an einer stelle haben
+
+das unten noch mal unter johannas mehr
+
+und dann kopiere ich den link da noch mal rüber
+
+Jetzt muss ich aber nochmal was fragen. Also ich habe das die ganze Zeit so verstanden, dass wir in diesem Gremium, dass das ein nicht ganz kleiner Teil davon ist, auch sicherzustellen, dass bestimmte Projekte eben nicht weggeschmissen werden, obwohl sie sozusagen, nur weil einer gesagt hat, was für ein Blödsinn.
+
+Ich sage mal so, ich nehme mich selbst als Beispiel, ich kriege irgendeine Projektidee und sage, was für ein Blödsinn, machen wir nicht, lehne die ab und dann fällt es irgendwo runter und irgendjemand anders sagt, hey Mensch, da hast du aber übersehen, das ist hierfür total relevant, weil wir haben hier in der EDD seit, kriegen wir pro Jahr 37 Anfragen für genau das oder eben auch andersrum, das kann ja auch passieren, Business Development entdeckt irgendeinen crazy Markt irgendwo
+
+und wir müssen dann am Ende sagen,
+
+so ein Produkt können wir
+
+einfach überhaupt gar nicht herstellen,
+
+weil Physik können wir nicht verbiegen.
+
+Und nicht in diesem Gremium
+
+jetzt wirklich die Projektleitung machen.
+
+Also ein bisschen...
+
+Nee, nee, nee, ist richtig.
+
+Und auch noch mal so ein bisschen,
+
+auch das ist gut,
+
+also, dass alle

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_08_changes.json

@@ -0,0 +1,318 @@
+{
+  "source_file": "chunk_08.txt",
+  "output_file": "chunk_08_normalized.txt",
+  "blocks_total": 168,
+  "blocks_changed": 41,
+  "policy": {
+    "removed": [
+      "isolated filler sounds such as äh, ähm, hm, mhm",
+      "immediate duplicate words",
+      "immediate duplicate phrases of two to four words",
+      "redundant whitespace"
+    ],
+    "explicitly_preserved": [
+      "negations",
+      "modal words and qualifiers",
+      "dates, times, numbers and quantities",
+      "technical statements",
+      "responsibilities",
+      "deadlines",
+      "decisions and commitments"
+    ],
+    "principle": "When uncertain, leave the text unchanged."
+  },
+  "changes": [
+    {
+      "block_number": 1,
+      "original": "dass wir das nicht direkt bewerten können,",
+      "normalized": "dass wir das nicht direkt bewerten können",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 4,
+      "original": "Aber wir werden doch nicht alle Projekte,",
+      "normalized": "Aber wir werden doch nicht alle Projekte",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 20,
+      "original": "F für Forschung, E-Entwicklung,",
+      "normalized": "F für Forschung, E-Entwicklung",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 23,
+      "original": "So, und hier wird dann ja diskutiert, jetzt scrolle ich einmal hoch, priorisiert ist, wie weiter vorgegangen wird, weil ab dieser Projektliste, ab diesem Termin, wo es vorgestellt wird, wird jemandem der Hut aufgesetzt und hier zu sagen, okay, hier musst du bitte XY erst einmal prüfen oder gegebenenfalls einen Projektplan erstellen.",
+      "normalized": "So, und hier wird dann ja diskutiert, jetzt scrolle ich einmal hoch, priorisiert ist, wie weiter vorgegangen wird, weil ab dieser Projektliste, ab diesem Termin, wo es vorgestellt wird jemandem der Hut aufgesetzt und hier zu sagen, okay, hier musst du bitte XY erst einmal prüfen oder gegebenenfalls einen Projektplan erstellen.",
+      "removed_fillers": [],
+      "duplicate_reductions": [
+        "wird, wird"
+      ]
+    },
+    {
+      "block_number": 26,
+      "original": "Also ich glaube, das wird einfach on the fly, wird man da relativ schnell erkennen,",
+      "normalized": "Also ich glaube, das wird einfach on the fly, wird man da relativ schnell erkennen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 29,
+      "original": "Ich glaube, wir verkomplizieren das wirklich in diesem Fall,",
+      "normalized": "Ich glaube, wir verkomplizieren das wirklich in diesem Fall",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 30,
+      "original": "weil in dieser Liste wird relativ schnell klar werden,",
+      "normalized": "weil in dieser Liste wird relativ schnell klar werden",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 37,
+      "original": "Und wir können es ja im halben Jahr dann immer noch sagen,",
+      "normalized": "Und wir können es ja im halben Jahr dann immer noch sagen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 38,
+      "original": "okay, beim BD-Projekt haben wir jetzt immer nach der und der Folie gefragt,",
+      "normalized": "okay, beim BD-Projekt haben wir jetzt immer nach der und der Folie gefragt",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 40,
+      "original": "So what? Bitte gerne einfach immer ihren Leuten, die den Hut aufsetzen, sagen,",
+      "normalized": "So what? Bitte gerne einfach immer ihren Leuten, die den Hut aufsetzen, sagen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 45,
+      "original": "Und wenn wir das alles vorher abfragen oder noch eine Station vorher einbauen,",
+      "normalized": "Und wenn wir das alles vorher abfragen oder noch eine Station vorher einbauen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 46,
+      "original": "weil wir sind jetzt schon bei einer Beantwortung,",
+      "normalized": "weil wir sind jetzt schon bei einer Beantwortung",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 47,
+      "original": "alleine weil der Termin nur alle zwei Wochen stattfindet,",
+      "normalized": "alleine weil der Termin nur alle zwei Wochen stattfindet",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 50,
+      "original": "Sorry, ich muss mich einmal kurz auf Abschieden,",
+      "normalized": "Sorry, ich muss mich einmal kurz auf Abschieden",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 63,
+      "original": "Also wir sagen nur grob, okay, wir wissen, was läuft eigentlich so,",
+      "normalized": "Also wir sagen nur grob, okay, wir wissen, was läuft eigentlich so",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 66,
+      "original": "Und wir sollten auch noch, da bin ich auch noch dabei,",
+      "normalized": "Und wir sollten auch noch, da bin ich auch noch dabei",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 67,
+      "original": "noch gucken, was draus geworden ist. Aber nur im Sinne von,",
+      "normalized": "noch gucken, was draus geworden ist. Aber nur im Sinne von",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 68,
+      "original": "läuft noch, gibt irgendwie einen großen Milestone,",
+      "normalized": "läuft noch, gibt irgendwie einen großen Milestone",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 71,
+      "original": "Beziehungsweise ist es hier jetzt in der F&E,",
+      "normalized": "Beziehungsweise ist es hier jetzt in der F&E",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 75,
+      "original": "Ja, wo wir darüber sprechen,",
+      "normalized": "Ja, wo wir darüber sprechen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 76,
+      "original": "das passiert dann auch in der Abteilung,",
+      "normalized": "das passiert dann auch in der Abteilung",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 77,
+      "original": "in Abstimmung mit der GF,",
+      "normalized": "in Abstimmung mit der GF",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 79,
+      "original": "Ich kann nicht, nochmal,",
+      "normalized": "Ich kann nicht, nochmal",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 85,
+      "original": "Ich denke,",
+      "normalized": "Ich denke",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 98,
+      "original": "Und also die ganzen Änderungen,",
+      "normalized": "Und also die ganzen Änderungen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 101,
+      "original": "Wenn ich das jetzt nochmal zurückziehen muss,",
+      "normalized": "Wenn ich das jetzt nochmal zurückziehen muss",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 107,
+      "original": "nicht gesagt haben, sie sind damit einverstanden,",
+      "normalized": "nicht gesagt haben, sie sind damit einverstanden",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 111,
+      "original": "Das sind keine neuen Ergebnisse,",
+      "normalized": "Das sind keine neuen Ergebnisse",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 112,
+      "original": "da sind keine Änderungen dran, die a,",
+      "normalized": "da sind keine Änderungen dran, die a",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 116,
+      "original": "ist damit auf jeden Fall mal,",
+      "normalized": "ist damit auf jeden Fall mal",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 117,
+      "original": "hat es überhaupt noch nicht mitgekriegt und nicht verstanden,",
+      "normalized": "hat es überhaupt noch nicht mitgekriegt und nicht verstanden",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 118,
+      "original": "weil sie nämlich hier in der Mail, ihr habt sie vorhin gelesen,",
+      "normalized": "weil sie nämlich hier in der Mail, ihr habt sie vorhin gelesen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 121,
+      "original": "Die ist noch überhaupt nicht auf dem Weg zu akzeptieren,",
+      "normalized": "Die ist noch überhaupt nicht auf dem Weg zu akzeptieren",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 125,
+      "original": "Er hat das alles verteilt,",
+      "normalized": "Er hat das alles verteilt",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 138,
+      "original": "nehmen wir uns halt die Zeit,",
+      "normalized": "nehmen wir uns halt die Zeit",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 146,
+      "original": "Ja,",
+      "normalized": "Ja",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 158,
+      "original": "und wir müssen dann am Ende sagen,",
+      "normalized": "und wir müssen dann am Ende sagen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 160,
+      "original": "einfach überhaupt gar nicht herstellen,",
+      "normalized": "einfach überhaupt gar nicht herstellen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 165,
+      "original": "Nee, nee, nee, ist richtig.",
+      "normalized": "Nee, ist richtig.",
+      "removed_fillers": [],
+      "duplicate_reductions": [
+        "Nee, nee",
+        "Nee, nee"
+      ]
+    },
+    {
+      "block_number": 166,
+      "original": "Und auch noch mal so ein bisschen,",
+      "normalized": "Und auch noch mal so ein bisschen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 167,
+      "original": "auch das ist gut,",
+      "normalized": "auch das ist gut",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    }
+  ]
+}

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_08_normalized.txt

@@ -0,0 +1,335 @@
+dass wir das nicht direkt bewerten können
+
+ohne dass wir jetzt Filterkriterien aufschreiben in dem Fall
+
+und das versuchen fortzunehmen?
+
+Aber wir werden doch nicht alle Projekte
+
+die Frage ist ja erstmal, wer kommt denn mit welcher Liste
+
+und wer stellt denn welches Projekt in welchem Gremium?
+
+Sagen wir mal, wir werden hier das Gremium.
+
+zur Diskussion.
+
+Das hatten wir aber schon definiert.
+
+Das steht hier auch drin.
+
+Wir haben die Ideenliste.
+
+Das hatte ich
+
+verteilt vor zwei Wochen mit der Bitte.
+
+Diese
+
+genauen Punkte, die stehen hier alle
+
+drunter. Also Leiter F&E
+
+führt die Projektliste auf den zweiwöchentlichen
+
+Schnittstellen-Stand-Up. Das ist dieser Termin.
+
+Hier wird definiert, ob es sich ein
+
+F für Forschung, E-Entwicklung
+
+PM- oder BD-Projekt handelt.
+
+So, hier wird die Projektleitung und alle in Kenntnis zu setzen Personen festgelegt. Zu dem Zeitpunkt ist es auch schon nach gewissen Kriterien kategorisiert. Es sind Vorfilter entlaufen und wenn wir hier einen Punkt haben, hier sind die Arten der Projekte, das hattet ihr vorher auch schon mal 2018 alles sehr gut ausgearbeitet. Hier haben wir noch ein paar Ergänzungen vorgenommen.
+
+So, und hier wird dann ja diskutiert, jetzt scrolle ich einmal hoch, priorisiert ist, wie weiter vorgegangen wird, weil ab dieser Projektliste, ab diesem Termin, wo es vorgestellt wird jemandem der Hut aufgesetzt und hier zu sagen, okay, hier musst du bitte XY erst einmal prüfen oder gegebenenfalls einen Projektplan erstellen.
+
+und dann führst du das Projekt durch und gibst uns erstmal einen Zwischenbericht
+
+und dann geht es erneut durch diesen Kreislauf nochmal wieder durch.
+
+Also ich glaube, das wird einfach on the fly, wird man da relativ schnell erkennen
+
+ob man bei einem Projekt noch zusätzliche Informationen braucht oder nicht.
+
+Das habt ihr damals sehr gut durchdacht.
+
+Ich glaube, wir verkomplizieren das wirklich in diesem Fall
+
+weil in dieser Liste wird relativ schnell klar werden
+
+okay, das hätten James und David vielleicht schon mal direkt an die Fachabteilung zurückgeben müssen.
+
+Das hätte vielleicht gar nicht hier landen sollen und so weiter und so fort.
+
+Und ich glaube, dass wir da relativ schnell ein Gefühl für entwickeln.
+
+Aber das ist nichts, was in diesem sehr oberflächlich groß gesehenen Prozess mit abgebildet werden muss.
+
+Und der Rest, das kann man schlecht vordefinieren.
+
+Ich würde wirklich sagen, lass uns dafür ein Gefühl entwickeln.
+
+Und wir können es ja im halben Jahr dann immer noch sagen
+
+okay, beim BD-Projekt haben wir jetzt immer nach der und der Folie gefragt
+
+weil Giovanna möchte das einfach für ihre Art von Projekten haben.
+
+So what? Bitte gerne einfach immer ihren Leuten, die den Hut aufsetzen, sagen
+
+die Folie bitte auch immer ausfüllen.
+
+Da sehe ich kein großes Problem.
+
+Und du hast selber geschrieben, wir müssen es nicht zu komplex machen.
+
+Wir wollen ja auch flexibel bleiben.
+
+Und wenn wir das alles vorher abfragen oder noch eine Station vorher einbauen
+
+weil wir sind jetzt schon bei einer Beantwortung
+
+alleine weil der Termin nur alle zwei Wochen stattfindet
+
+bei einer frühesten Beantwortung zum nächsten Termin.
+
+Also das macht ja auch schon langsam dann in dem Fall.
+
+Sorry, ich muss mich einmal kurz auf Abschieden
+
+weil ich ganz dringend.
+
+Ansonsten, Lars, du schickst mir wahrscheinlich nachher
+
+einmal nochmal rum, ne?
+
+Ich schick das nochmal rum.
+
+Dankeschön, klar.
+
+Okay, tschüss dann.
+
+Ciao.
+
+Ja, ich sehe es auch so.
+
+Also je länger ich darüber nachdenke, das ist nicht Projekt, also das, was wir hier tun, ist nicht die konkrete Projektleitung. Wir geben vielleicht noch ein, zwei Sachen an die Hand, damit soweit das geht, in jeder Art von Projekt die gleichen Fragen nach den gleichen Kriterien beantwortet werden.
+
+Also ich würde mir gerne die Diskussion ersparen, warum ein Projekt ähnlicher Art in der F&E abgelehnt wurde, weil der ROI nicht gegeben ist, aber in Abteilung XY läuft sowas halt durch, weil die halt anders, einfach subjektiv anders gehandelt haben.
+
+da, wo das geht. Aber ansonsten, die Bearbeitung der Projekte
+
+muss und kann nur in den Fachabteilungen passieren.
+
+Also wir sagen nur grob, okay, wir wissen, was läuft eigentlich so
+
+was ist reingekommen und wo ist es hingegangen?
+
+Und wer kriegt den Hut auf? Genau. Wo ist es hingegangen?
+
+Und wir sollten auch noch, da bin ich auch noch dabei
+
+noch gucken, was draus geworden ist. Aber nur im Sinne von
+
+läuft noch, gibt irgendwie einen großen Milestone
+
+oder ist in der Fachabteilung eingestellt worden.
+
+Ja, das Bewerten der Ergebnisse ist auch wieder in dem Gremium.
+
+Beziehungsweise ist es hier jetzt in der F&E
+
+weil es wieder zurückgespielt wird.
+
+Ja, da würde ich jetzt sagen, das würde ich ändern.
+
+Also hier steht.
+
+Ja, wo wir darüber sprechen
+
+das passiert dann auch in der Abteilung
+
+in Abstimmung mit der GF
+
+wie das Ergebnis am Ende behandelt wird.
+
+Ich kann nicht, nochmal
+
+ich kann nicht darüber entscheiden, ob ein Marketingprojekt
+
+erfolgreich gelaufen ist.
+
+Habe ich überhaupt gar keine Kompetenz für.
+
+Ja, oder auch...
+
+Ja.
+
+Ich denke
+
+wir zwei scheinen uns auf jeden Fall ziemlich
+
+nicht so zu sein.
+
+Aber es wäre wertvoll, dass die
+
+Erkenntnis... Malte, teile mal bitte den Link von dem Miro.
+
+Ja, den hast du schon.
+
+Warte mal.
+
+Ja, ich kopiere den hier nochmal rein.
+
+weil Henning hat den nicht.
+
+Am Ende ist es immer hilfreich, ihn direkt vor Augen zu haben.
+
+Ja, mit Henning, also ich hatte das vor drei Wochen rumgeschickt
+
+oder vor vier Wochen mit der Bitte um Durchsicht
+
+und da hatte sich nur einer drauf gemeldet.
+
+Und also die ganzen Änderungen
+
+ich habe das jetzt auch schon angestoßen dementsprechend.
+
+Ich sitze jetzt gleich halt schon mit Henning zusammen.
+
+Wenn ich das jetzt nochmal zurückziehen muss
+
+dann müsste ich das auf jeden Fall wissen.
+
+Nein.
+
+Schmalte, mach das bitte mal
+
+in der Geschwindigkeit, wie wir das diskutieren.
+
+Und bevor Giovanna und Björn
+
+nicht gesagt haben, sie sind damit einverstanden
+
+braucht Henning da überhaupt nichts tun
+
+und vor allem nicht einarbeiten.
+
+Wir hatten das aber durchgesprochen.
+
+Das sind keine neuen Ergebnisse
+
+da sind keine Änderungen dran, die a
+
+nicht vorher gemeinsam festgelegt wurden
+
+und b, nicht danach nochmal.
+
+Also Giovanna
+
+ist damit auf jeden Fall mal
+
+hat es überhaupt noch nicht mitgekriegt und nicht verstanden
+
+weil sie nämlich hier in der Mail, ihr habt sie vorhin gelesen
+
+noch darüber nachdenkt, wie denn die Filterkriterien
+
+und wie so ein Projektablauf überhaupt aussehen sollte.
+
+Die ist noch überhaupt nicht auf dem Weg zu akzeptieren
+
+dass dieser Prozess, den wir schon haben, der geeignete ist.
+
+Also die müssen wir da erstmal nochmal mitnehmen.
+
+Da bin ich jetzt ein bisschen bei Malte.
+
+Er hat das alles verteilt
+
+alles ist angeschrieben worden, alle hatten die
+
+Gelegenheit, da reinzugucken
+
+und wenn da in vier Wochen nichts passiert ist.
+
+Also mindestens mal
+
+Giovanna und ich haben es
+
+nicht mitgekriegt und hatten keine Gelegenheit
+
+reinzugucken oder haben es
+
+für uns war es nicht klar und Björn
+
+offensichtlich auch nicht.
+
+Und wenn wir hier was bauen wollen, was
+
+für mindestens drei relevante Abteile
+
+im Haus relevant ist, dann
+
+nehmen wir uns halt die Zeit
+
+bis es alle verstanden haben.
+
+Jetzt nützt es uns doch nichts.
+
+Also lass uns das jetzt hier nochmal
+
+so definieren.
+
+Ich suche es gerade raus.
+
+Dann schicke mir den Link, dann packe ich
+
+den hier mit rein.
+
+Ja
+
+Die muss bereits jetzt im Prozess definiert.
+
+Hier würde ich jetzt den Link zum Miro nochmal reinkopieren, Walter.
+
+Ja, ich leite das gerade nochmal weiter.
+
+Hier ist der Link. Ich hatte es runtergeschrieben.
+
+Nochmals Link.
+
+ich kopiere deine mail auch noch mal rein in den ganzen chat
+
+das war alles an einer stelle haben
+
+das unten noch mal unter johannas mehr
+
+und dann kopiere ich den link da noch mal rüber
+
+Jetzt muss ich aber nochmal was fragen. Also ich habe das die ganze Zeit so verstanden, dass wir in diesem Gremium, dass das ein nicht ganz kleiner Teil davon ist, auch sicherzustellen, dass bestimmte Projekte eben nicht weggeschmissen werden, obwohl sie sozusagen, nur weil einer gesagt hat, was für ein Blödsinn.
+
+Ich sage mal so, ich nehme mich selbst als Beispiel, ich kriege irgendeine Projektidee und sage, was für ein Blödsinn, machen wir nicht, lehne die ab und dann fällt es irgendwo runter und irgendjemand anders sagt, hey Mensch, da hast du aber übersehen, das ist hierfür total relevant, weil wir haben hier in der EDD seit, kriegen wir pro Jahr 37 Anfragen für genau das oder eben auch andersrum, das kann ja auch passieren, Business Development entdeckt irgendeinen crazy Markt irgendwo
+
+und wir müssen dann am Ende sagen
+
+so ein Produkt können wir
+
+einfach überhaupt gar nicht herstellen
+
+weil Physik können wir nicht verbiegen.
+
+Und nicht in diesem Gremium
+
+jetzt wirklich die Projektleitung machen.
+
+Also ein bisschen...
+
+Nee, ist richtig.
+
+Und auch noch mal so ein bisschen
+
+auch das ist gut
+
+also, dass alle

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_09.txt

@@ -0,0 +1,307 @@
+klar sind, was in den Abteilungen so ungefähr
+
+läuft, damit man da nochmal
+
+die
+
+gegenseitige Information ein bisschen stärkt.
+
+Aber wenn wir das jetzt
+
+so extrem aufblasen in dem
+
+Schritt, dann machen wir es auch
+
+echt doppelt, weil jede Abteilung
+
+hat diese Kriterien
+
+ja im Grunde sowieso.
+
+Und meiner Meinung nach
+
+haben wir genau
+
+das vor vier Wochen
+
+auch alles schon
+
+gesprochen.
+
+Also wir hatten diese Änderungen ja schon.
+
+Ja,
+
+Entschuldigung,
+
+ich so direkt bin, aber die Mail
+
+sagt eigentlich ganz klar, hier ist das und das, was
+
+geändert wird, bitte Rückmeldung bis zum nächsten
+
+Meeting. Und die ist
+
+an alle gegangen. Keiner
+
+in CC, alles direkt.
+
+Gut, aber daran soll es
+
+jetzt nicht scheitern. Dann Henning wird nicht
+
+traurig sein, wenn du den Termin absagst. Der hat
+
+genug anderes zu tun.
+
+Dann ziehen wir es jetzt noch einmal gerade.
+
+Ich komme
+
+in das Board gar nicht ran, Malte.
+
+Du hast gerade mit einer gmail.com
+
+E-Mail-Adresse angefragt.
+
+Ich hatte dich
+
+über das Tool, ja, ich weiß nicht,
+
+ich mache es jetzt nochmal so.
+
+Also wir haben ja hier so die Namen
+
+in dem Tool, wo man einfach enter
+
+E-Mails to invite
+
+from. Ich weiß nicht.
+
+Ich weiß nicht, warum er mir jetzt hier das gerade...
+
+Also ich habe die
+
+lasvollmatt.bbgeo.com
+
+Die ist drin. Das ist die, die mir vorgeschlagen
+
+wurde von Miro.
+
+Als ich lasvollmatt eingegeben habe.
+
+Aber die
+
+lasvollmatt.naue.gmail.com
+
+ist jetzt auch
+
+drin.
+
+Also jetzt kannst du mit
+
+beiden rein auf jeden Fall.
+
+Komm nicht rein.
+
+So, jetzt komme ich da rein.
+
+Keine Ahnung, warum ich da vorher nicht drin war.
+
+So, für Giovanna wäre jetzt noch wichtig, glaube ich, Ideenpool in dem Prozess, wo ist jetzt dieses Gremium?
+
+Das Gremium ist unter der Projektliste im Text.
+
+Hier sieht man das.
+
+Der Leiter F&E führt die Projektliste auf dem zweiwöchentlichen Schnittstellen-Stand-Up.
+
+Hier wird definiert, ob es sich um und so weiter und so fort.
+
+das ist auch so weiter von meinem screenshot
+
+kopiert das dann auch ein weiß johann dass sie da reingucken muss
+
+gut ok
+
+Okay, das da jetzt in die Mail rein.
+
+Ich höre mir jetzt aber trotzdem gleich kurz das Feedback von Henning an, was ihm noch fehlt aus deren Sicht, weil dann kann ich die Änderungen direkt zusammenführen.
+
+Die Möglichkeit.
+
+Also unter Filtern und Kategorisieren.
+
+Wo bist du gerade gedanklich?
+
+Ich kann dir gerade kurz nicht folgen.
+
+Achso, unter Projektliste steht der Satz.
+
+Oder welchen meinst du jetzt?
+
+Ja, aber es gibt ja einen Punkt hier,
+
+filtern und kategorisieren.
+
+Genau, der dann erst mal auch der Vorfilter ist.
+
+Genau, so ein bisschen.
+
+Welche Richtung geht es überhaupt?
+
+Da würde ich meinen, dass Giovanna damit Probleme hat,
+
+weil da steht, also das ist ja eben kein Gremium.
+
+Nee, das Filtern erstmal ist es eine Idee auf Team- und Abteilungsebene.
+
+Zu dem Zeitpunkt ist es ja noch nicht mal in der Projektliste,
+
+sondern da ist es einfach erstmal eine Idee, die per Mail reingekommen ist.
+
+Wo gefiltert wird, muss das überhaupt in die Liste, in der unsere Filter gelten.
+
+Das ist nochmal ein Vorfilter. Wir haben zwei Orte, an denen wir filtern, wenn du so willst.
+
+in dem Gremium und einmal vorher
+
+die Punkte, gehört das überhaupt rein?
+
+Ja, alles klar.
+
+Also da filtern wir auch nur die...
+
+Okay, weil sonst schmeißt du schon raus in die...
+
+Sonst schmeißt du schon wieder zurück in die Fachabteilung.
+
+Ja, aber nur die ganz offensichtlichen.
+
+Da passieren nur die ganz offensichtlichen falschen Sachen
+
+und die ganz klar entscheidbar sind, dass die einfach kein Projekt sind.
+
+Und auch die würden wir ja nachrichtlich
+
+dann in dem Filter 2 nochmal
+
+nennen. Also falls da einer ein Veto hat,
+
+kann er das an der Stelle ja einlegen.
+
+Ja.
+
+Aber die Erfahrung aus den Jahren zeigt halt einfach,
+
+es gibt Dinge, mit denen brauchst
+
+du dich dann weiter nicht beschäftigen, weil die einfach
+
+sonnenklar in irgendeiner Abteilung
+
+liegen.
+
+Und es ist ja auch gut, es geht ja darum,
+
+dass es nicht wie
+
+Einer von euch beiden hat es vorhin schon gesagt, bei den höher bezahlten Leuten früh liegen und von drei Leuten schon mal angeschaut werden.
+
+Genau das soll ja verhindert werden auch damit.
+
+Unter anderem.
+
+Und natürlich gilt, im Zweifel geht es immer durch.
+
+Ja.
+
+Vielleicht können wir es im Wording so machen,
+
+dieser erste Filter ist eher eine Entscheidungsvorlage
+
+als eine endgültige Entscheidung schon.
+
+Ja, früher als manchmal.
+
+MS-Text.
+
+Ja.
+
+Ich kann nur noch mal sagen, wenn
+
+Guana das im Business Development machen will,
+
+ist sie herzlich eingeladen.
+
+Es geht hier an ganz vielen Stellen nur um
+
+schnödes Doing.
+
+Da bin ich überhaupt gar nicht gepicht drauf.
+
+Gut, okay.
+
+Also unabhängig vom Prozess
+
+würde es trotzdem Sinn machen,
+
+dass wir uns Gedanken machen,
+
+welche sind die
+
+Prüfsteine?
+
+Was ist relevant für die Fachabteilung?
+
+Das können wir gerne machen,
+
+aber ich würde hoffen, dass jeder das eh schon hat.
+
+Das haben wir nicht zusammengetragen,
+
+Glaube ich nicht.
+
+Nee, gibt es schon gar nicht.
+
+Aber jeder für sich sollte das eigentlich haben.
+
+Ja, jeder für sich hat Kriterien im Kopf, keine Frage.
+
+Aber das müssen nicht zwangsläufig dieselben sein
+
+und erst recht nicht, was ist zum Beispiel die Anforderung der Geschäftsführung
+
+an Ergebnisertrag, Zeit.
+
+Da hat jeder seine eigenen Kriterien und biegt sich die auch gerade so zurecht,
+
+damit er das Projekt entweder ablehnen oder machen kann, je nach Bauchgefühl.
+
+Dem widerspreche ich.
+
+Ja, okay.
+
+Danke, dass du das nicht noch hinterher geschoben hast.
+
+Okay, gut.
+
+Dann lassen wir das doch so stehen.
+
+Dann schicken wir das jetzt einfach mal raus
+
+und beenden die Diskussion jetzt an dieser Stelle mal.
+
+Und warten wir ab, ob da von Johanna noch was kommt oder von Björn.
+
+Ja?
+
+Gut.
+
+Okay, alles klar.
+
+Prima.
+
+Dann danke euch erstmal.
+
+Ciao.

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_09_changes.json

@@ -0,0 +1,147 @@
+{
+  "source_file": "chunk_09.txt",
+  "output_file": "chunk_09_normalized.txt",
+  "blocks_total": 154,
+  "blocks_changed": 17,
+  "policy": {
+    "removed": [
+      "isolated filler sounds such as äh, ähm, hm, mhm",
+      "immediate duplicate words",
+      "immediate duplicate phrases of two to four words",
+      "redundant whitespace"
+    ],
+    "explicitly_preserved": [
+      "negations",
+      "modal words and qualifiers",
+      "dates, times, numbers and quantities",
+      "technical statements",
+      "responsibilities",
+      "deadlines",
+      "decisions and commitments"
+    ],
+    "principle": "When uncertain, leave the text unchanged."
+  },
+  "changes": [
+    {
+      "block_number": 17,
+      "original": "Ja,",
+      "normalized": "Ja",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 18,
+      "original": "Entschuldigung,",
+      "normalized": "Entschuldigung",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 35,
+      "original": "über das Tool, ja, ich weiß nicht,",
+      "normalized": "über das Tool, ja, ich weiß nicht",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 44,
+      "original": "Die ist drin. Das ist die, die mir vorgeschlagen",
+      "normalized": "Die ist drin. Das ist die mir vorgeschlagen",
+      "removed_fillers": [],
+      "duplicate_reductions": [
+        "die, die"
+      ]
+    },
+    {
+      "block_number": 72,
+      "original": "Ja, aber es gibt ja einen Punkt hier,",
+      "normalized": "Ja, aber es gibt ja einen Punkt hier",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 77,
+      "original": "Da würde ich meinen, dass Giovanna damit Probleme hat,",
+      "normalized": "Da würde ich meinen, dass Giovanna damit Probleme hat",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 80,
+      "original": "Zu dem Zeitpunkt ist es ja noch nicht mal in der Projektliste,",
+      "normalized": "Zu dem Zeitpunkt ist es ja noch nicht mal in der Projektliste",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 95,
+      "original": "nennen. Also falls da einer ein Veto hat,",
+      "normalized": "nennen. Also falls da einer ein Veto hat",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 98,
+      "original": "Aber die Erfahrung aus den Jahren zeigt halt einfach,",
+      "normalized": "Aber die Erfahrung aus den Jahren zeigt halt einfach",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 103,
+      "original": "Und es ist ja auch gut, es geht ja darum,",
+      "normalized": "Und es ist ja auch gut, es geht ja darum",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 110,
+      "original": "Vielleicht können wir es im Wording so machen,",
+      "normalized": "Vielleicht können wir es im Wording so machen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 117,
+      "original": "Guana das im Business Development machen will,",
+      "normalized": "Guana das im Business Development machen will",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 124,
+      "original": "würde es trotzdem Sinn machen,",
+      "normalized": "würde es trotzdem Sinn machen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 125,
+      "original": "dass wir uns Gedanken machen,",
+      "normalized": "dass wir uns Gedanken machen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 129,
+      "original": "Das können wir gerne machen,",
+      "normalized": "Das können wir gerne machen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 131,
+      "original": "Das haben wir nicht zusammengetragen,",
+      "normalized": "Das haben wir nicht zusammengetragen",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    },
+    {
+      "block_number": 139,
+      "original": "Da hat jeder seine eigenen Kriterien und biegt sich die auch gerade so zurecht,",
+      "normalized": "Da hat jeder seine eigenen Kriterien und biegt sich die auch gerade so zurecht",
+      "removed_fillers": [],
+      "duplicate_reductions": []
+    }
+  ]
+}

samples/benchmarks/meeting_context_v1/source_reconstruction/chunk_09_normalized.txt

@@ -0,0 +1,307 @@
+klar sind, was in den Abteilungen so ungefähr
+
+läuft, damit man da nochmal
+
+die
+
+gegenseitige Information ein bisschen stärkt.
+
+Aber wenn wir das jetzt
+
+so extrem aufblasen in dem
+
+Schritt, dann machen wir es auch
+
+echt doppelt, weil jede Abteilung
+
+hat diese Kriterien
+
+ja im Grunde sowieso.
+
+Und meiner Meinung nach
+
+haben wir genau
+
+das vor vier Wochen
+
+auch alles schon
+
+gesprochen.
+
+Also wir hatten diese Änderungen ja schon.
+
+Ja
+
+Entschuldigung
+
+ich so direkt bin, aber die Mail
+
+sagt eigentlich ganz klar, hier ist das und das, was
+
+geändert wird, bitte Rückmeldung bis zum nächsten
+
+Meeting. Und die ist
+
+an alle gegangen. Keiner
+
+in CC, alles direkt.
+
+Gut, aber daran soll es
+
+jetzt nicht scheitern. Dann Henning wird nicht
+
+traurig sein, wenn du den Termin absagst. Der hat
+
+genug anderes zu tun.
+
+Dann ziehen wir es jetzt noch einmal gerade.
+
+Ich komme
+
+in das Board gar nicht ran, Malte.
+
+Du hast gerade mit einer gmail.com
+
+E-Mail-Adresse angefragt.
+
+Ich hatte dich
+
+über das Tool, ja, ich weiß nicht
+
+ich mache es jetzt nochmal so.
+
+Also wir haben ja hier so die Namen
+
+in dem Tool, wo man einfach enter
+
+E-Mails to invite
+
+from. Ich weiß nicht.
+
+Ich weiß nicht, warum er mir jetzt hier das gerade...
+
+Also ich habe die
+
+lasvollmatt.bbgeo.com
+
+Die ist drin. Das ist die mir vorgeschlagen
+
+wurde von Miro.
+
+Als ich lasvollmatt eingegeben habe.
+
+Aber die
+
+lasvollmatt.naue.gmail.com
+
+ist jetzt auch
+
+drin.
+
+Also jetzt kannst du mit
+
+beiden rein auf jeden Fall.
+
+Komm nicht rein.
+
+So, jetzt komme ich da rein.
+
+Keine Ahnung, warum ich da vorher nicht drin war.
+
+So, für Giovanna wäre jetzt noch wichtig, glaube ich, Ideenpool in dem Prozess, wo ist jetzt dieses Gremium?
+
+Das Gremium ist unter der Projektliste im Text.
+
+Hier sieht man das.
+
+Der Leiter F&E führt die Projektliste auf dem zweiwöchentlichen Schnittstellen-Stand-Up.
+
+Hier wird definiert, ob es sich um und so weiter und so fort.
+
+das ist auch so weiter von meinem screenshot
+
+kopiert das dann auch ein weiß johann dass sie da reingucken muss
+
+gut ok
+
+Okay, das da jetzt in die Mail rein.
+
+Ich höre mir jetzt aber trotzdem gleich kurz das Feedback von Henning an, was ihm noch fehlt aus deren Sicht, weil dann kann ich die Änderungen direkt zusammenführen.
+
+Die Möglichkeit.
+
+Also unter Filtern und Kategorisieren.
+
+Wo bist du gerade gedanklich?
+
+Ich kann dir gerade kurz nicht folgen.
+
+Achso, unter Projektliste steht der Satz.
+
+Oder welchen meinst du jetzt?
+
+Ja, aber es gibt ja einen Punkt hier
+
+filtern und kategorisieren.
+
+Genau, der dann erst mal auch der Vorfilter ist.
+
+Genau, so ein bisschen.
+
+Welche Richtung geht es überhaupt?
+
+Da würde ich meinen, dass Giovanna damit Probleme hat
+
+weil da steht, also das ist ja eben kein Gremium.
+
+Nee, das Filtern erstmal ist es eine Idee auf Team- und Abteilungsebene.
+
+Zu dem Zeitpunkt ist es ja noch nicht mal in der Projektliste
+
+sondern da ist es einfach erstmal eine Idee, die per Mail reingekommen ist.
+
+Wo gefiltert wird, muss das überhaupt in die Liste, in der unsere Filter gelten.
+
+Das ist nochmal ein Vorfilter. Wir haben zwei Orte, an denen wir filtern, wenn du so willst.
+
+in dem Gremium und einmal vorher
+
+die Punkte, gehört das überhaupt rein?
+
+Ja, alles klar.
+
+Also da filtern wir auch nur die...
+
+Okay, weil sonst schmeißt du schon raus in die...
+
+Sonst schmeißt du schon wieder zurück in die Fachabteilung.
+
+Ja, aber nur die ganz offensichtlichen.
+
+Da passieren nur die ganz offensichtlichen falschen Sachen
+
+und die ganz klar entscheidbar sind, dass die einfach kein Projekt sind.
+
+Und auch die würden wir ja nachrichtlich
+
+dann in dem Filter 2 nochmal
+
+nennen. Also falls da einer ein Veto hat
+
+kann er das an der Stelle ja einlegen.
+
+Ja.
+
+Aber die Erfahrung aus den Jahren zeigt halt einfach
+
+es gibt Dinge, mit denen brauchst
+
+du dich dann weiter nicht beschäftigen, weil die einfach
+
+sonnenklar in irgendeiner Abteilung
+
+liegen.
+
+Und es ist ja auch gut, es geht ja darum
+
+dass es nicht wie
+
+Einer von euch beiden hat es vorhin schon gesagt, bei den höher bezahlten Leuten früh liegen und von drei Leuten schon mal angeschaut werden.
+
+Genau das soll ja verhindert werden auch damit.
+
+Unter anderem.
+
+Und natürlich gilt, im Zweifel geht es immer durch.
+
+Ja.
+
+Vielleicht können wir es im Wording so machen
+
+dieser erste Filter ist eher eine Entscheidungsvorlage
+
+als eine endgültige Entscheidung schon.
+
+Ja, früher als manchmal.
+
+MS-Text.
+
+Ja.
+
+Ich kann nur noch mal sagen, wenn
+
+Guana das im Business Development machen will
+
+ist sie herzlich eingeladen.
+
+Es geht hier an ganz vielen Stellen nur um
+
+schnödes Doing.
+
+Da bin ich überhaupt gar nicht gepicht drauf.
+
+Gut, okay.
+
+Also unabhängig vom Prozess
+
+würde es trotzdem Sinn machen
+
+dass wir uns Gedanken machen
+
+welche sind die
+
+Prüfsteine?
+
+Was ist relevant für die Fachabteilung?
+
+Das können wir gerne machen
+
+aber ich würde hoffen, dass jeder das eh schon hat.
+
+Das haben wir nicht zusammengetragen
+
+Glaube ich nicht.
+
+Nee, gibt es schon gar nicht.
+
+Aber jeder für sich sollte das eigentlich haben.
+
+Ja, jeder für sich hat Kriterien im Kopf, keine Frage.
+
+Aber das müssen nicht zwangsläufig dieselben sein
+
+und erst recht nicht, was ist zum Beispiel die Anforderung der Geschäftsführung
+
+an Ergebnisertrag, Zeit.
+
+Da hat jeder seine eigenen Kriterien und biegt sich die auch gerade so zurecht
+
+damit er das Projekt entweder ablehnen oder machen kann, je nach Bauchgefühl.
+
+Dem widerspreche ich.
+
+Ja, okay.
+
+Danke, dass du das nicht noch hinterher geschoben hast.
+
+Okay, gut.
+
+Dann lassen wir das doch so stehen.
+
+Dann schicken wir das jetzt einfach mal raus
+
+und beenden die Diskussion jetzt an dieser Stelle mal.
+
+Und warten wir ab, ob da von Johanna noch was kommt oder von Björn.
+
+Ja?
+
+Gut.
+
+Okay, alles klar.
+
+Prima.
+
+Dann danke euch erstmal.
+
+Ciao.

samples/benchmarks/meeting_context_v1/source_reconstruction/manifest.json

@@ -0,0 +1,78 @@
+{
+  "source_file": "meeting_speech_cleaned.json",
+  "chunk_count": 9,
+  "chunks": [
+    {
+      "number": 1,
+      "filename": "chunk_01.txt",
+      "chars": 9020,
+      "blocks": 143,
+      "first_timestamp": null,
+      "last_timestamp": null
+    },
+    {
+      "number": 2,
+      "filename": "chunk_02.txt",
+      "chars": 9062,
+      "blocks": 103,
+      "first_timestamp": null,
+      "last_timestamp": null
+    },
+    {
+      "number": 3,
+      "filename": "chunk_03.txt",
+      "chars": 9005,
+      "blocks": 85,
+      "first_timestamp": null,
+      "last_timestamp": null
+    },
+    {
+      "number": 4,
+      "filename": "chunk_04.txt",
+      "chars": 9030,
+      "blocks": 99,
+      "first_timestamp": null,
+      "last_timestamp": null
+    },
+    {
+      "number": 5,
+      "filename": "chunk_05.txt",
+      "chars": 9145,
+      "blocks": 148,
+      "first_timestamp": null,
+      "last_timestamp": null
+    },
+    {
+      "number": 6,
+      "filename": "chunk_06.txt",
+      "chars": 9048,
+      "blocks": 92,
+      "first_timestamp": null,
+      "last_timestamp": null
+    },
+    {
+      "number": 7,
+      "filename": "chunk_07.txt",
+      "chars": 9038,
+      "blocks": 162,
+      "first_timestamp": null,
+      "last_timestamp": null
+    },
+    {
+      "number": 8,
+      "filename": "chunk_08.txt",
+      "chars": 9006,
+      "blocks": 168,
+      "first_timestamp": null,
+      "last_timestamp": null
+    },
+    {
+      "number": 9,
+      "filename": "chunk_09.txt",
+      "chars": 5777,
+      "blocks": 154,
+      "first_timestamp": null,
+      "last_timestamp": null
+    }
+  ]
+}

samples/benchmarks/meeting_context_v1/todo_prompt_explicit_responsibility_v1/chunk_01_extraction_with_context.json

@@ -0,0 +1,25 @@
+{
+  "facts": [
+    "Martin | Das ist das aktuelle Projektdeckblatt, was wir in der F&E benutzen. | clear | Ja, also das Ganze ist ja auch nicht mit dem Hintergrund gedacht gewesen sondern das ist das aktuelle Projektdeckblatt, was wir in der F&E benutzen.",
+    "Das Ding ist jetzt kein Filtersystem. | clear | Mehr ist es nicht. Also es ist jetzt kein Filtersystem gewesen. Dafür war es auch nie gedacht."
+  ],
+  "decisions": [
+    "Jovana wird die Auswahlkriterien für Business Development-Projekte zusammenstellen und diese mit den von EDD, Marketing und PM definierten Kriterien integrieren. | Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt [...] bittet aber im Prinzip darum, es wäre hilfreich, wenn wir auch die von euch EDD, Marketing, PM bereits definierten Auswahlkriterien mit integrieren könnten in den Filter."
+  ],
+  "todos": [
+    "Zusammenstellen der Kriterien für Business Development-Projekte und Integration der bestehenden Auswahlkriterien aus EDD, Marketing und PM. | Jovana | Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt"
+  ],
+  "questions": [
+    "Welche spezifischen Auswahlkriterien sind für digitale Produkte relevant (z.B. kulturelle Hürden, Sprache)? | Wenn wir zum Beispiel über das Portal reden, dann reden wir zum Beispiel über digitale Affinität [...] Dann reden wir halt, wie gesagt, über Sprache, auch primär wichtig."
+  ],
+  "positions": [],
+  "technical": [
+    "Projektsheet Struktur | Das ist eine kurze Projektidee. Teilweise sind das nur ein, zwei, drei Sätze. | clear | Name, Projektname, was auch immer. Das ist eine kurze Projektidee. Das ist natürlich jetzt hier viel Dummy-Text.",
+    "Nutzung des Projektsheets in F&E | Die Folien, die wir nicht benutzen, die blenden wir einfach aus. | clear | Und zwar ist das auch eher, ich sage mal, optional, was da so drin steht. [...] Und die Folien, die wir nicht benutzen, die blenden wir einfach aus."
+  ],
+  "context": {
+    "meeting_id": "2026-07-27-projektprozess",
+    "source_file": "samples\\real_live\\project_process_meeting\\meeting_context.yaml",
+    "schema_version": "1"
+  }
+}

samples/benchmarks/meeting_context_v1/todo_prompt_explicit_responsibility_v1/comparison.md

@@ -0,0 +1,83 @@
+# Todo Prompt Explicit Responsibility Evaluation
+
+## Prompt Change
+
+- Modified only `prompts/todos.md`.
+- Added one focused rule requiring explicit assignment, volunteering, or acceptance before naming a responsible person.
+
+## Run
+
+- Runtime seconds: 17.604
+- Prompt characters: 16482
+- Model: qwen3.5:9B
+- Thinking: false
+- Task prompt names: ['decisions.md', 'todos.md']
+
+## Category Counts
+
+| Category | Historical chunk_01 | Previous context-aware | New prompt run |
+| --- | ---: | ---: | ---: |
+| facts | 2 | 3 | 2 |
+| decisions | 0 | 0 | 1 |
+| todos | 2 | 3 | 1 |
+| questions | 1 | 2 | 1 |
+| positions | 0 | 0 | 0 |
+| technical | 2 | 2 | 2 |
+
+## Old Todo List
+
+```json
+[
+  "Giovanna soll sich darum bemühen, die Kriterien zusammenzustellen. | Also Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt,",
+  "Es wäre hilfreich, wenn EDD, Marketing und PM bereits definierte Auswahlkriterien mit integrieren könnten in den Filter. | bittet aber im Prinzip darum, es wäre hilfreich, wenn wir auch die von euch EDD, Marketing, PM bereits definierten Auswahlkriterien mit integrieren könnten in den Filter.",
+  "Björn soll Kriterien für das Thema Testmarkt (Marketing) definieren. | Björn, für das Thema Testmarkt ging das, glaube ich, so."
+]
+```
+
+## New Todo List
+
+```json
+[
+  "Zusammenstellen der Kriterien für Business Development-Projekte und Integration der bestehenden Auswahlkriterien aus EDD, Marketing und PM. | Jovana | Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt"
+]
+```
+
+## New Positions Involving Bjoern
+
+```json
+[]
+```
+
+## New Items Involving Bjoern
+
+```json
+[]
+```
+
+## New Items Mentioning Jovana Or Giovanna
+
+```json
+[
+  {
+    "category": "decisions",
+    "item": "Jovana wird die Auswahlkriterien für Business Development-Projekte zusammenstellen und diese mit den von EDD, Marketing und PM definierten Kriterien integrieren. | Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt [...] bittet aber im Prinzip darum, es wäre hilfreich, wenn wir auch die von euch EDD, Marketing, PM bereits definierten Auswahlkriterien mit integrieren könnten in den Filter."
+  },
+  {
+    "category": "todos",
+    "item": "Zusammenstellen der Kriterien für Business Development-Projekte und Integration der bestehenden Auswahlkriterien aus EDD, Marketing und PM. | Jovana | Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt"
+  }
+]
+```
+
+## Assessment
+
+- Historical BD false item present: False
+- Previous unsupported Testmarkt task present: False
+- Unsupported Bjoern todo candidates: []
+- Bjoern associated with Marketing: False
+- Bjoern reassigned to Business Development: False
+- Bjoern represented as position/objection/qualification: False
+- Absent person assignment candidates: ["Zusammenstellen der Kriterien für Business Development-Projekte und Integration der bestehenden Auswahlkriterien aus EDD, Marketing und PM. | Jovana | Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt"]
+- Important information loss: False
+- New serious attribution errors: ["Zusammenstellen der Kriterien für Business Development-Projekte und Integration der bestehenden Auswahlkriterien aus EDD, Marketing und PM. | Jovana | Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt"]
+- Overall result: worsened

samples/benchmarks/meeting_context_v1/todo_prompt_explicit_responsibility_v1/run_metadata.json

@@ -0,0 +1,12 @@
+{
+  "runtime_seconds": 17.604,
+  "prompt_characters": 16482,
+  "model": "qwen3.5:9B",
+  "prompt_eval_count": 4014,
+  "eval_count": 887,
+  "think": false,
+  "task_prompt_names": [
+    "decisions.md",
+    "todos.md"
+  ]
+}

samples/benchmarks/meeting_context_v1/valid_bjoern_case/chunk_01_extraction_with_context.json

@@ -0,0 +1,27 @@
+{
+  "facts": [
+    "Martin | Das ist das aktuelle Projektdeckblatt, was wir in der F&E benutzen. | clear | Ja, also das Ganze ist ja auch nicht mit dem Hintergrund gedacht gewesen sondern das ist das aktuelle Projektdeckblatt, was wir in der F&E benutzen.",
+    "Die 5 Millionen in 5 Jahren von 5 Leuten oder so ähnlich. | clear | Also die Frage von der GF ist ja dann häufig, was kommt da überhaupt raus? Die 5 Millionen in 5 Jahren von 5 Leuten oder so ähnlich.",
+    "Das Ding ist ja mit einer anderen Idee entwickelt worden. | clear | So, teilen. Das Ding ist ja mit einer anderen Idee entwickelt worden."
+  ],
+  "decisions": [],
+  "todos": [
+    "Giovanna soll sich darum bemühen, die Kriterien zusammenzustellen. | Also Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt,",
+    "Es wäre hilfreich, wenn EDD, Marketing und PM bereits definierte Auswahlkriterien mit integrieren könnten in den Filter. | bittet aber im Prinzip darum, es wäre hilfreich, wenn wir auch die von euch EDD, Marketing, PM bereits definierten Auswahlkriterien mit integrieren könnten in den Filter.",
+    "Björn soll Kriterien für das Thema Testmarkt (Marketing) definieren. | Björn, für das Thema Testmarkt ging das, glaube ich, so."
+  ],
+  "questions": [
+    "Welche spezifischen Kriterien sind relevant für digitale Produkte im Vergleich zu Realprodukten? | Also jetzt als Beispiel, Johann hat ja schon mal nachgefragt und er hat mir auch schon Notizen zugemacht. Wenn wir zum Beispiel über das Portal reden, dann reden wir zum Beispiel über digitale Affinität...",
+    "Wie sollen die Auswahlkriterien aus EDD, Marketing und PM in den Filter integriert werden? | ...dass sie da mal einen ersten Entwurf für macht. Du hast es auch vorgeschlagen."
+  ],
+  "positions": [],
+  "technical": [
+    "Projektdeckblatt Maya | Das ist das aktuelle Projektdeckblatt, was wir in der F&E benutzen. | clear | Ja, also das Ganze ist ja auch nicht mit dem Hintergrund gedacht gewesen sondern das ist das aktuelle Projektdeckblatt, was wir in der F&E benutzen.",
+    "Nutzung des Deckblatts als Filter | Das Ding ist ja mit einer anderen Idee entwickelt worden. Also hier erstmal Name... Das ist eine kurze Projektidee. | clear | So, teilen. Das Ding ist ja mit einer anderen Idee entwickelt worden."
+  ],
+  "context": {
+    "meeting_id": "2026-07-27-projektprozess",
+    "source_file": "samples\\real_live\\project_process_meeting\\meeting_context.yaml",
+    "schema_version": "1"
+  }
+}

samples/benchmarks/meeting_context_v1/valid_bjoern_case/comparison.md

@@ -0,0 +1,105 @@
+# Meeting Context V1 Evaluation - Valid Bjoern Case
+
+## Run
+
+- Runtime seconds: 19.471
+- Prompt characters: 15615
+- Model: qwen3.5:9B
+- Thinking: false
+
+## Category Counts
+
+| Category | Old | New |
+| --- | ---: | ---: |
+| facts | 2 | 3 |
+| decisions | 0 | 0 |
+| todos | 2 | 3 |
+| questions | 1 | 2 |
+| positions | 0 | 0 |
+| technical | 2 | 2 |
+
+## Old Todos
+
+```json
+[
+  {
+    "item_id": "action_item_0001",
+    "category": "action_item",
+    "text": "Giovanna stellt die Kriterien zusammen und erstellt einen ersten Entwurf für den Auswahlkatalog, der EDD-, Marketing- und PM-Kriterien integriert.",
+    "evidence": "Also Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt",
+    "source_file": "chunk_01_extraction.json",
+    "source_index": 0,
+    "original_value": "Giovanna stellt die Kriterien zusammen und erstellt einen ersten Entwurf für den Auswahlkatalog, der EDD-, Marketing- und PM-Kriterien integriert. | Giovanna | Also Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt",
+    "responsible": "Giovanna",
+    "deadline": null,
+    "source_references": [
+      {
+        "source_file": "chunk_01_extraction.json",
+        "source_index": 0,
+        "evidence": "Also Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt",
+        "original_value": "Giovanna stellt die Kriterien zusammen und erstellt einen ersten Entwurf für den Auswahlkatalog, der EDD-, Marketing- und PM-Kriterien integriert. | Giovanna | Also Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt"
+      }
+    ],
+    "duplicate_count": 1
+  },
+  {
+    "item_id": "action_item_0002",
+    "category": "action_item",
+    "text": "Björn definiert andere Kriterien für Business Development Projekte (z.B. digitale Affinität, kulturelle Hürden) und integriert diese in den Filter.",
+    "evidence": "aus Marketing-Sicht, Björn, wirst du andere Kriterien haben",
+    "source_file": "chunk_01_extraction.json",
+    "source_index": 1,
+    "original_value": "Björn definiert andere Kriterien für Business Development Projekte (z.B. digitale Affinität, kulturelle Hürden) und integriert diese in den Filter. | Björn | aus Marketing-Sicht, Björn, wirst du andere Kriterien haben",
+    "responsible": "Björn",
+    "deadline": null,
+    "source_references": [
+      {
+        "source_file": "chunk_01_extraction.json",
+        "source_index": 1,
+        "evidence": "aus Marketing-Sicht, Björn, wirst du andere Kriterien haben",
+        "original_value": "Björn definiert andere Kriterien für Business Development Projekte (z.B. digitale Affinität, kulturelle Hürden) und integriert diese in den Filter. | Björn | aus Marketing-Sicht, Björn, wirst du andere Kriterien haben"
+      }
+    ],
+    "duplicate_count": 1
+  }
+]
+```
+
+## New Todos
+
+```json
+[
+  "Giovanna soll sich darum bemühen, die Kriterien zusammenzustellen. | Also Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt,",
+  "Es wäre hilfreich, wenn EDD, Marketing und PM bereits definierte Auswahlkriterien mit integrieren könnten in den Filter. | bittet aber im Prinzip darum, es wäre hilfreich, wenn wir auch die von euch EDD, Marketing, PM bereits definierten Auswahlkriterien mit integrieren könnten in den Filter.",
+  "Björn soll Kriterien für das Thema Testmarkt (Marketing) definieren. | Björn, für das Thema Testmarkt ging das, glaube ich, so."
+]
+```
+
+## New Positions Involving Bjoern
+
+```json
+[]
+```
+
+## New Items Mentioning Jovana Or Giovanna
+
+```json
+[
+  {
+    "category": "todos",
+    "item": "Giovanna soll sich darum bemühen, die Kriterien zusammenzustellen. | Also Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt,"
+  }
+]
+```
+
+## Assessment
+
+- Historical false item present in new todos: False
+- Unsupported Bjoern responsibility present: False
+- Bjoern represented as position/objection/qualification: False
+- Bjoern associated with Marketing in new output: False
+- Bjoern reassigned to Business Development: False
+- Jovana/Giovanna task assigned: True
+- Important information loss detected: False
+- New false assignment candidates: ["Giovanna soll sich darum bemühen, die Kriterien zusammenzustellen. | Also Giovanna hat ja auch selber schon vorgeschlagen, sie würde sich darum bemühen, dass sie dann entsprechend mal die Kriterien zusammenstellt,"]
+- Overall result: worsened

samples/benchmarks/meeting_context_v1/valid_bjoern_case/run_metadata.json

@@ -0,0 +1,8 @@
+{
+  "runtime_seconds": 19.471,
+  "prompt_characters": 15615,
+  "model": "qwen3.5:9B",
+  "prompt_eval_count": 3851,
+  "eval_count": 991,
+  "think": false
+}

samples/benchmarks/progeo_llm_comparison_20260805_133942_report.md

@@ -0,0 +1,50 @@
+# Experiment 2 LLM Comparison Report
+
+## Benchmark Directories
+
+- qwen3.5:9b: `samples\benchmarks\progeo_qwen35_9b_20260805_133942`
+- qwen3.5:35B-A3B: `samples\benchmarks\progeo_qwen35_35b_a3b_20260805_133942`
+
+## Configuration
+
+- Input: `samples/real_live/progeo_meeting/progeo_whispercpp_vulkan_turbo_trimmed_converted.json`
+- Meeting Context: `samples/real_live/progeo_meeting/meeting_context.yaml`
+- Chunking: `target_chars=4500`, `max_chars=5500`, `min_chars=2500`, `overlap_blocks=0`
+- Model parameters: `think=false`, `temperature=0`, `num_ctx=32768`; committed generation limits and adaptive consolidator sizing; no retries; no manual intervention.
+
+## Runtime
+
+| Stage | qwen3.5:9b | qwen3.5:35B-A3B |
+|---|---:|---:|
+| chunking | 0.271 | 0.276 |
+| normalization | 1.366 | 1.344 |
+| extraction | 389.75 | 953.042 |
+| canonicalizer | 0.139 | 0.316 |
+| semantic_consolidator | 103.788 | 119.612 |
+| renderer | 64.85 | 87.72 |
+
+- Total qwen3.5:9b: 560.164 seconds
+- Total qwen3.5:35B-A3B: 1162.31 seconds
+
+## Structural Counts
+
+- qwen3.5:9b extraction: {'facts': 106, 'decisions': 10, 'todos': 40, 'questions': 26, 'positions': 0, 'technical': 63}
+- qwen3.5:35B-A3B extraction: {'facts': 125, 'decisions': 9, 'todos': 36, 'questions': 37, 'positions': 0, 'technical': 79}
+- qwen3.5:9b canonical: {'fact': 106, 'decision': 10, 'action_item': 35, 'open_question': 26, 'position': 0, 'technical_detail': 63}
+- qwen3.5:35B-A3B canonical: {'fact': 125, 'decision': 9, 'action_item': 36, 'open_question': 37, 'position': 0, 'technical_detail': 79}
+
+## Validation And Repair
+
+- qwen3.5:9b: validator before valid=False, violations=11; repair_count=14; validator after valid=True.
+- qwen3.5:35B-A3B: validator before valid=False, violations=78; repair_count=78; validator after valid=True.
+
+## Renderer
+
+- qwen3.5:9b: valid=False; done_reason=length; eval_count=4096; response_text_length=16429.
+- qwen3.5:35B-A3B: valid=False; done_reason=stop; eval_count=1861; response_text_length=7594.
+
+## Result
+
+- Selected winner: `qwen3.5:9b WINS`
+- Confidence: medium
+- Engineering recommendation: do not switch production to `qwen3.5:35B-A3B` on this evidence. It was slower, required much more deterministic repair, still failed the renderer contract, and did not reduce core extraction overclassification enough to justify the runtime cost.

samples/benchmarks/progeo_meeting_20260804_083849/RUN_DIR.txt

@@ -0,0 +1 @@
+samples\benchmarks\progeo_meeting_20260804_083849