Document canonicalization and consolidation milestone

- preserve Working Protocol Synthesizer V0 as comparison baseline
- introduce deterministic canonicalization stage
- define semantic consolidator responsibilities
- clarify Canonical Meeting Knowledge generation
- document source-language output policy
- align roadmap, architecture and experiment log

samples/benchmarks/working_protocol_synthesizer_v0/README.md

@@ -0,0 +1,32 @@
+# Working Protocol Synthesizer V0
+
+## Summary
+
+- Experiment name: Working Protocol Synthesizer V0
+- Source: nine independent chunk extraction JSON files
+- Model: `qwen3.5:9b`
+- Prompt characters: 24,979
+- Actual prompt eval tokens: 5,929
+- Output tokens: 1,486
+- Runtime: 294.204 seconds
+- Output language: English
+- Purpose: baseline for later canonicalizer/consolidator comparisons
+
+## Known Characteristics
+
+- Readable and well structured.
+- Topic-oriented synthesis.
+- Still based directly on raw chunk extractions.
+- No separate canonicalization or semantic consolidation.
+- Output language did not match the German source material.
+
+## Versioning Decision
+
+Generated runtime artifacts are normally ignored in this repository. This
+selected output is intentionally versioned as a deliberate benchmark reference
+artifact so future deterministic canonicalizer, semantic consolidator and
+renderer experiments can be compared against the pre-consolidation baseline.
+
+Do not treat this Markdown file as canonical source data. It is a preserved
+experiment result.
+

samples/benchmarks/working_protocol_synthesizer_v0/working_protocol.md

@@ -0,0 +1,69 @@
+# Working Protocol: Project Idea Intake and Process Adaptation
+
+## Overview
+The meeting focused on adapting the existing R&D (F&E) project process to accommodate Business Development (BD), Marketing, and Product Management projects. The primary objective was to define a flexible framework that avoids over-engineering for a mid-sized company while establishing clear criteria for filtering ideas before they enter formal development pools. Key outcomes include defining minimum requirements for new ideas, assigning responsibility for initial screening, and agreeing on the structure of project documentation (Project Deck Sheet vs. Lastenheft) based on project type.
+
+## Topics
+
+### 1. Project Intake Requirements and Documentation
+**Background:**
+The current process is historically an R&D-focused workflow involving a "Project Deck Sheet" used in F&E departments. It was clarified that this document is not intended to be a filter system but rather a concise summary of the project idea, goal, counterpart, development hurdles (e.g., patents), and budget inquiry. The use of Gantt diagrams on every deck sheet is deemed unnecessary for all projects; they are only required when specifically needed during search or planning phases.
+
+**Decisions:**
+*   **Minimum Requirements for New Ideas:** A new idea must minimally answer: Title, Project Idea (a few sentences), and Project Goal. Optionally, underlying assumptions (e.g., expected market volume) may be listed but are not mandatory initially.
+*   **Documentation Adaptation by Type:** The general process flow remains consistent across project types (F&E, PM, Marketing, BD). However, specific documents vary:
+    *   F&E Projects use the standard Project Deck Sheet and Lastenheft structure.
+    *   Business Development (BD) projects require a Project Deck Sheet and a Lastenheft defining market targets.
+    *   The process steps for different types are left open in Swimlane diagrams to accommodate various perspectives, rather than being formally rigidly defined at this stage.
+
+**Action Items:**
+*   **Giovanna:** Compile criteria and create the first draft of the selection catalog integrating F&E, Marketing, and PM criteria.
+*   **Björn:** Define specific criteria for Business Development projects (e.g., digital affinity, cultural hurdles) from a marketing perspective and integrate these into the filter.
+
+**Open Questions:**
+*   How will specific selection criteria be defined and integrated for digital products (e.g., Portals) versus physical real products? Criteria are acknowledged as never being general but always specific to the context.
+*   Exactly how should requirements for the Lastenheft in non-F&E projects be defined, allowing departments autonomy if they have different needs?
+
+### 2. Filtering and Screening Process
+**Background:**
+Ideas must undergo pre-processing before F&E or other units consider them. It is noted that secretariats are often dismissive of vague requests (e.g., just a keyword), so ideas need to be enriched with minimal requirements beforehand. The network connection at municipalities is currently very slow, which may impact communication speeds but does not alter the process logic.
+
+**Decisions:**
+*   **Pre-Filtering Responsibility:** There was discussion regarding whether pre-filtering should be centralized or decentralized. While some hesitation exists about placing this responsibility solely within F&E (specifically David and James), there is agreement that someone must handle initial sorting and data collection formally acting as a "Gatekeeper." Björn expressed willingness to let others take over the preliminary filtering if desired, provided it happens.
+*   **Filter Criteria Definition:** The group agreed not to plan everything in advance but rather adapt the existing framework based on needs observed after 2-4 meetings or 10-15 projects. Filter criteria must be defined for different cases (new products/applications vs. existing markets).
+
+**Action Items:**
+*   **Björn & PM/BD:** Discuss specific project examples (e.g., Papatikus-Anker) and route them to the respective specialist departments.
+*   **Gatekeepers (James/David):** Formally process a few items and gather information at the entry point of the pool, though full resolution is not expected immediately.
+
+**Open Questions:**
+*   At which stage does a department decide independently versus when it must refer an idea to the central "pot" or management? It remains unclear exactly where projects enter this pot and where they do not.
+*   Are we convinced that specific market studies should be initiated based on these filtered ideas?
+
+### 3. Project Classification and Management Levels
+**Background:**
+The process distinguishes between tasks handled at the team/department level versus those requiring cross-departmental or strategic relevance/budget approval. The R&D "pot" is jointly managed and not fragmented. It was clarified that F&E leadership maintains an overview of projects during bi-weekly interface stand-ups to categorize them as Research (F), Development, PM, or BD projects at the time they are presented on this list.
+
+**Decisions:**
+*   **Project Categorization:** At the point where a project is listed and categorized by F&E leadership, it has already passed certain pre-filters. The processing of these projects must occur exclusively within the specialist departments (Fachabteilungen).
+*   **Management Scope:** Management does not decide on the success or failure of specific marketing projects but maintains oversight of the overall portfolio.
+
+**Action Items:**
+*   Define a few "checkpoints" (Prüfsteine) to determine if an idea is cross-departmental/strategic, requires budget, or can be handled internally by a team/unit. If it does not meet these criteria, it returns to the department level.
+
+### 4. Process Implementation and Governance
+**Background:**
+The goal is to establish a process where filters are securely queried without creating complex additional processes for a mid-sized company. The implementation of this new workflow relies on execution rather than perfect upfront planning. A Miro board containing relevant links (e.g., from Malte) was discussed as a resource for the team, specifically shared with Henning and others via chat.
+
+**Decisions:**
+*   **Process Flexibility:** Agree to utilize the existing process framework and adapt it to needs without creating complex additional processes suitable only for larger enterprises. The group agreed on this approach collectively.
+*   **Filter Nature:** The first filter is defined as a decision proposal (Entscheidungsvorlage) rather than a final binding decision, allowing flexibility before formal review by the committee or leadership.
+
+**Action Items:**
+*   **Malte:** Copy and distribute the Miro link to all relevant persons in the chat.
+*   **Giovanna & Björn:** Await their feedback on the proposed criteria catalog; once they agree, the discussion is considered concluded for now.
+*   **Raik:** Must ensure ideas are entered into the pool with proper context (not just keywords) when contacted or instructed to do so by others.
+
+**Open Questions:**
+*   Which checkpoints are relevant specifically for the specialist departments independent of the main process?
+*   Who presents which project list in which committee, and who is responsible for setting up the necessary checks or creating a project plan at that specific term?