Define topic-oriented protocol architecture

2026-08-11 14:42:18 +02:00
parent c2b7b6b4d2
commit bcb197a908
2 changed files with 99 additions and 1 deletions
@@ -186,6 +186,76 @@ An “unresolved question” is a derived, protocol-relevant combination rather

 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
@@ -221,10 +291,21 @@ Semantic merging becomes better informed, but not automatically easy. Equivalenc

 ### Renderer and output policy

-The renderer should not make commitment classification decisions. A policy/view-selection stage should provide protocol-worthy semantic states to the renderer. The normal Working or Distribution Protocol renderer should therefore receive Decisions, established/ongoing Action Items and unresolved information needs, not raw proposals.
+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.