Benjamin Admin
63fe2d496e
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>
4.7 KiB
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_idim 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↔Evidencestabilisieren. - Domäne 3 (wichtigster neuer Block): Feature-Katalog (~150–300 Features Maschinen-/Anlagenbau) ·
Feature → Capabilitykuratieren · 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.