docs: session_ownership_model_v1.md — Arbeitsteilung nach Modell-Besitz + 3 Vertraege

User-Antwort auf „wie verteilen wir die Arbeit": nach BESITZ der Datenmodelle, NICHT nach
Regulierung. 3 Domaenen (Legal Knowledge / Compliance Execution / Product Knowledge), jede
besitzt EIN Modell (andere read-only). 3 Vertraege: Legal->Compliance citation_span->legal_basis ·
Product->Compliance Feature->Capability (WICHTIGSTE Schnittstelle) · Compliance->Legal
obligation_id->legal_basis. Product Knowledge Graph = naechster Meilenstein (Reasoning-Session
umfokussieren, besitzt schon CanonicalProductRegulatoryProfile+Navigator). NIS2 verschoben.
Offene Fragen: Legal-KG-Owner, IACE-4.-Session, Compliance-2-Branch-Split.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

docs-src/development/session_ownership_model_v1.md

@@ -0,0 +1,77 @@
+# Session Ownership Model v1 — Arbeitsteilung nach Modell-Besitz
+
+Status: **Vorschlag/Vertrag (2026-06-26).** Antwort auf „Wie verteilen wir die Arbeit?":
+**nach BESITZ der Datenmodelle, NICHT nach Regulierung.** Ergänzt
+[compliance_meta_model_v1.md](compliance_meta_model_v1.md) (Architektur-Freeze v1.0).
+
+## Leitregel
+
+> **Jede Session besitzt genau EIN Datenmodell. Andere Sessions dürfen es LESEN, nie SCHREIBEN.**
+
+Verteilung nach Regulierung wäre instabil (jede Reg. zieht durch alle Schichten). Verteilung nach
+Modell-Besitz ist stabil: drei Wissenswelten, die BreakPilot zusammenführt — **Recht · Produkt · Compliance**.
+
+## Die drei Domänen
+
+### Domäne 1 — Legal Knowledge Graph („Was steht im Recht?")
+Besitzt: Dokumente · Parser · CELLAR · Chunk/Span · **citation_span** · Authority · `source_class` ·
+`source_role` · Explainability · Retriever.
+Kennt NICHT: Capabilities, Procedures, Produktfeatures.
+Liefert: `citation_span → legal_basis → authority`.
+
+### Domäne 2 — Compliance Execution Graph („Wie wird eine Pflicht erfüllt?")
+Besitzt: **Obligation Registry · Capability Registry · Procedures · Controls · Evidence** ·
+Discovery-Pipeline · Reuse-Metrik · Cross-Regulation · Runtime (obligation-status).
+Kennt NICHT: Dokumente/Parser/Spans, Produktfeatures.
+Modell: `Obligation → Capability → Procedure → Control → Evidence` (Meta-Model v1.0, eingefroren).
+
+### Domäne 3 — Product Knowledge Graph („Was hat der Kunde gebaut?")
+Besitzt: Produktmodell · Komponenten · **Business Features** · **Feature → Capability** ·
+Product Profile (`CanonicalProductRegulatoryProfile`) · Scope Discovery · Missing-Facts (Navigator).
+Kennt NICHT: Paragraphen, Controls.
+Beispiel-Features: SPS · HMI · Cloud · MQTT · OPC-UA · Fernwartung · VPN · WLAN · Ethernet ·
+Bluetooth · USB · Kamera · KI · Mobile App · OTA · Sensorik · Aktorik.
+
+## Die drei öffentlichen Verträge (die EINZIGE Kopplung)
+
+```
+1. Legal → Compliance     citation_span  → legal_basis      (Recht hängt an der Obligation)
+2. Product → Compliance    Business Feature → Capability      ← WICHTIGSTE Schnittstelle des Systems
+3. Compliance → Legal      obligation_id  → legal_basis      (jede Pflicht ist begründbar)
+```
+
+**Vertrag 2 (`Feature → Capability`) ist die Innovation.** Er macht aus Kundensprache Regulierungs-
+sprache: „Wir haben Fernwartung" → Capabilities {transport_encryption, multi_factor_authentication,
+least_privilege_access_control} → Obligations über CRA + MaschVO + NIS2 → fehlende Nachweise.
+**Owner des Mappings: Domäne 3** (liest die Capability Registry von Domäne 2 read-only).
+
+## Der vollständige Fluss (das Kundengespräch)
+
+```
+Produktbeschreibung → Product Graph → Capabilities → Compliance Graph → Legal Graph → Antwort
+```
+beantwortet: „Wir bauen diese Maschine mit diesen Funktionen — welche Gesetze gelten, was erfüllen
+wir, was fehlt, wo interpretieren wir falsch?"
+
+## Mapping auf aktuelle Branches + OFFENE FRAGEN (User/Team entscheidet)
+
+| Domäne | Kandidat-Branch heute | Klärungsbedarf |
+|---|---|---|
+| 1 Legal Knowledge | (Re-Ingest/Span-Arbeit — Owner benennen) | **Wer besitzt Parser/CELLAR/Span?** noch nicht eindeutig einer Branch zugeordnet |
+| 2 Compliance Execution | `feat/obligation-aggregation` (Registry/Capability/Discovery) **+** `feat/advisor-status` (Controls/Evidence/Endpoint) | **Domäne 2 liegt aktuell auf ZWEI Branches** → zusammenführen oder klare Subteilung |
+| 3 Product Knowledge | `feat/regulatory-reasoning-engine` (Reasoning **→ umfokussieren** auf Product Graph) | Reasoning besitzt schon `CanonicalProductRegulatoryProfile` + Navigator → wird Domäne 3 |
+| — | `feat/iace-gt-warewashing` (IACE Hazard-Engine-Qualität) | **4. Session existiert.** User-Prinzip „keine 4. Session" → IACE als Sub-Track von Domäne 2 (Hazard→Obligation) einordnen ODER bewusst separater Engine-Quality-Track |
+
+## Erste Aufgaben je Domäne
+
+- **Domäne 1:** Re-Ingest fertig · Span-Anker stabil · `obligation_id` im Legal Graph joinbar (über
+  Vertrag, NICHT selbst vergeben) · zitierfähige API.
+- **Domäne 2:** Capability Registry ausbauen · Procedure Registry erweitern · Runtime auf Capability-
+  Ebene · `Obligation↔Capability↔Procedure↔Evidence` stabilisieren.
+- **Domäne 3 (wichtigster neuer Block):** Feature-Katalog (~150–300 Features Maschinen-/Anlagenbau) ·
+  `Feature → Capability` kuratieren · Produktprofil ableiten · Missing-Facts-Engine.
+
+## Nicht jetzt
+NIS2/AI-Act/Data-Act-Runs verschoben (liefern Reuse-Kennzahlen, aber keine neue Produktfrage). KEINE
+weitere Datenmodell-Klasse (Freeze v1.0). Product Knowledge Graph hat Vorrang — er schließt die Lücke
+zwischen Kunden- und Regulierungssprache.