breakpilot-compliance/docs-src/development/session_ownership_model_v1.md

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 (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.

RESOLVED (2026-06-26, User-Entscheidung) — die 3 offenen Fragen geklärt, Vertrag final

1. Legal Knowledge Owner = die Re-Ingest-/Knowledge-Session. Besitzt Parser/CELLAR/Span/Authority/ Retrieval/Citation-API. Vergibt KEINE obligation_id — liefert nur citation_span → legal_basis; die obligation_id entsteht im Compliance-Graph. Verhindert, dass dieselbe Pflicht zweimal modelliert wird.
2. 4. Session NICHT auflösen → umbenennen in „Quality & Validation". Besitzt KEINE Daten/Registry — NUR Tests: Golden/Regression/Precision/Recall/Halluzination/Benchmark/Hazard-Qualität/FMEA-Validierung. Darf produktive Modelle NIE verändern; sagt nur „funktioniert / funktioniert nicht". → 4 Verantwort- lichkeiten: Legal liefert Wissen · Compliance modelliert Wissen · Product liefert Kontext · Quality prüft alles.
3. Compliance Execution bleibt 2 Branches (dauerhaft getrennt, NICHT mergen):
   • Branch A (feat/obligation-aggregation) = BUILD: Registry · Discovery · Ontology · Capabilities · Procedures · Graph (ändert sich ~wöchentlich).
   • Branch B (feat/advisor-status) = RUNTIME / Execution Engine: API · Advisor · Endpoint · Status · Evidence · Reasoning (ändert sich ~täglich). Unterschiedliche Geschwindigkeit → bewusst getrennt.

Plattform-Zielbild: 4 Bibliotheken — Legal Library → Product Library → Capability Library → Evidence Library; darauf sitzen Advisor · Runtime · Auditor · Ticket-System · CE-/CRA-/NIS2-/AI-Act- Assistent — alle auf derselben Wissensbasis. Die Capability Library/Registry ist der Dreh- und Angelpunkt zwischen Product- und Compliance-Graph → muss ein stabiler, versionierter API-Vertrag sein (stabile cap.*-IDs, nie umbenennen; produktneutral). Das ist #59.

Update (2026-06-26): Domäne 3 = FEATURE Knowledge Graph + Sequenz-Entscheidung

Rename Domäne 3 → „Feature Knowledge Graph". Kunden kaufen keine Capabilities/Obligations — sie kaufen Maschinen mit Fernwartung, Cloud, OTA, SPS, HMI, KI. Der Advisor MUSS dort beginnen, wo der Kunde steht (Fernwartung), nicht bei cap.transport_encryption. Domäne 3 besitzt zusätzlich die Feature Library (alle bekannten ~200–400 Features: Fernwartung/Cloud/OTA/VPN/WLAN/Bluetooth/USB/ Ethernet/OPC-UA/MQTT/CAN/Profinet/EtherCAT/SPS/Safety-SPS/HMI/Vision/Kamera/RFID/NFC/Mobile-App/REST-API/ Webserver/SSH/Benutzerverwaltung/Rollenmodell/Logging/KI/…). Feature Library ≠ Product Profile: Library = alle bekannten Features; Profile = die Features EINES konkreten Produkts.

Volle Pipeline (der eigentliche Advisor):

Feature Library → Product Profile → Capabilities → Legal Obligations → Procedures → Controls → Evidence

„Fernwartung + Cloud + VPN + OTA + Benutzerverwaltung" → N Capabilities → M Obligations → K Regulierungen → Procedures → Controls → Evidence. Das beginnt das Gespräch in Kundensprache.

Sequenz-Entscheidung (User 2026-06-26):

1. JETZT: cap.*-Vertrag (capability_registry_v1) an Domäne 3 übergeben = der Multiplikator.
2. Domäne 3 Vollgas: Feature Library + Komponenten + Feature → cap.* + Product Profile + Missing-Facts. Zuerst OHNE Regulierungen — reine Kundensprache.
3. Domäne 2 STOPP bei #59: Capability Registry bleibt STABIL (nur Bugfixes, KEINE neuen Capabilities/ Procedures), bis Domäne 3 zeigt, WELCHE Capabilities real gebraucht werden (sonst modelliert man 30, von denen 12 genutzt werden).
4. Domäne 1: Re-Ingest abschließen, Span-Anker, Citation-API stabilisieren.

Domäne 2 — Wake-up-Trigger (statt vagem „pausiert")

Domäne 2 ruht NICHT unbestimmt — sie wird wieder aktiv, sobald EINER dieser Trigger feuert:

Feature Graph (Domäne 3) >= 200 Features      → Feature Coverage Report (erster Auftrag, s.u.)
ODER Span-Anker verfügbar (Domäne 1)          → pending_span_anchor auflösen (citation_pending → echte Spans)
ODER neue Regulierung ingestiert              → Discovery-Cut + Reuse-Metrik
ODER Runtime (Branch B) kennt neue Evidence-Typen → required_procedures/evidence_patterns endgültig füllen

Bis dahin steht überall citation_pending / required_procedures: [] — bewusst, kein Defekt.

Erster Folgeauftrag von Domäne 2 (sobald Feature Library v1 steht): FEATURE COVERAGE REPORT

NICHT „neue CRA-Domäne". Sondern die Wissenslücken-Analyse, die diese Architektur erstmals ermöglicht: pro Feature die Kette Feature → cap.* → realizes_obligations → Procedures → Evidence traversieren und Coverage % je Feature berechnen — wie vollständig ist die Modellierungskette?

Fernwartung → 100 %   ·   USB → 94 %   ·   Bluetooth → 83 %   ·   Cloud → 71 %

Output: je Feature die Lücken — fehlende Capability · fehlende Procedure · fehlender Evidence-Typ. Zeigt sofort, was schon vollständig modelliert ist und wo Domäne 2 als Nächstes nacharbeiten muss. Traversal-Logik gehört Domäne 2 (cap.→Obligation→Procedure→Evidence); der Feature→cap.-Input kommt read-only von Domäne 3. Gated auf Feature Library v1.

RESOLVED (2026-06-26): Ownership-Konflikt #1 — Capability ist ein GETEILTER Knoten

Konflikt: die Reasoning/Company-Session beanspruchte Feature→Capability/Certificate→Capability für Domäne 2. User-Entscheidung: beide bleiben bei Domäne 3 (Feature Knowledge Graph).

Feature ------+
Certificate --+──▶  CAPABILITY  ──▶ Obligation ─▶ Procedure ─▶ Control ─▶ Evidence
   (Domäne 3:        (Domäne 2:        (Domäne 2: ausgehende Kanten)
    eingehende        Knoten +
    Kanten)           IDs)

• Knoten + ausgehende Kanten = Domäne 2: Capability Registry · Capability-IDs (cap.*) · Capability→Obligation (realizes) · Capability→Procedure→Control→Evidence.
• eingehende Kanten = Domäne 3: Feature→Capability (requires) · Certificate→Capability · Product Profile→Features.

Begründung: „Fernwartung→transport_encryption" oder „IEC 62443-4-2→Capabilities" sind PRODUKT-/ Technik-Aussagen — kein Jurist weiß das → Produktwissen (Domäne 3). „Capability→Obligation" ist regulatorisches Wissen (Domäne 2). Gleiches Objekt, andere Kante, andere Domäne.

EXPLIZITER VERTRAG: Domäne 2 besitzt NIEMALS Wissen darüber, welche Produkte oder Zertifikate welche Capabilities benötigen. Sie besitzt ausschließlich das Wissen, welche Capabilities regulatorische Pflichten erfüllen. (Verhindert, dass Domäne 2 zur Produktmodellierung abdriftet.)

Thema	Owner
Capability Registry · Capability-IDs	Domäne 2
Capability → Obligation · Capability → Procedure → Control → Evidence	Domäne 2
proposed → canonical obligation_id (Reasoning#1)	Domäne 2
Feature → Capability · Certificate → Capability · Product Profile → Features	Domäne 3