Benjamin Admin
2063615d37
#59 (geschaerft, User): capabilities.json -> capability_registry_v1 (contract_version 1.0): stabile `cap.*`-IDs (NIE umbenennen) + 5 Vertragsfelder (description/guidance_basis/ realizes_obligations/required_procedures/evidence_patterns), PRODUKTNEUTRAL (keine Features). = stabiler API-Vertrag fuer die Product->Compliance-Schnittstelle (Feature->Capability, Session 3 mappt read-only dagegen). session_ownership_model_v1.md RESOLVED: Legal-Owner = Re-Ingest-Session (vergibt KEINE obligation_id, nur citation_span->legal_basis) · 4. Session -> Quality & Validation (nur Tests, KEINE Daten) · Compliance 2 Branches DAUERHAFT (A=Build, B=Runtime). 4-Bibliotheken- Zielbild (Legal/Product/Capability/Evidence). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
101 lines
6.5 KiB
Markdown
101 lines
6.5 KiB
Markdown
# 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.
|
||
|
||
## 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.
|