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

## 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** |

## ARCHITEKTURPRINZIP (User 2026-06-26): Ownership liegt auf BEZIEHUNGEN, nicht auf Knoten

Nicht „Session 2 besitzt Capability". Sondern: **jede Session besitzt bestimmte KANTEN.** Der
Capability-Knoten ist gemeinsam nutzbar, aber **keine Session besitzt alle ein- UND ausgehenden Kanten** —
genau das verhindert die Vermischung von Produkt- und Compliance-Wissen.

| Beziehung (Kante) | Owner |
|---|---|
| `Feature → Capability` | Session 3 |
| `Certificate → Capability` | Session 3 |
| `Capability → Obligation` | Session 2 |
| `Obligation → Procedure` | Session 2 |
| `Procedure → Control` | Session 2 |
| `Control → Evidence` | Session 2 |
| `Citation Span → Legal Basis` | Session 1 |

**`cap.*` = kanonische ID auf `obligation_id`-Niveau** (RE-LINKEN, nie umbenennen). **Capability ist der
EINZIGE Knoten, der drei Welten verbindet — Recht ⊕ Produkt ⊕ Nachweis = der semantische Mittelpunkt
des Systems.**

**Künftiger Vertrag (noch NICHT jetzt) — Confidence/Disambiguierung:** sobald Domäne 3 liefert
`Fernwartung → cap.transport_encryption (confidence 0.91)` und mehrere Capabilities möglich sind,
**entscheidet Domäne 3** (Produktverständnis), NICHT Domäne 2. Domäne 2 nimmt an: *ein geliefertes
`cap.X` ist produktseitig bereits bewertet.* Diese Grenze jetzt benennen, später vertraglich fixieren.

**Reifegrad:** Domäne 2 ist „fertig genug, um auf andere Teams zu warten" — kein Stillstand, sondern
stabile Schnittstellen. Weitere Arbeit hier birgt das Risiko, unbewusst in Domäne 1/3 hineinzuwachsen.
→ Domäne 2 ruht bewusst unverändert bis ein Wake-up-Trigger feuert (Session 1 Span-Anker ODER Session 3
Feature Library).
