Benjamin_Boenisch/breakpilot-compliance
1
1
Fork 0
Code Issues 24 Pull Requests 1 Actions 1 Packages Projects Releases Wiki Activity

docs: Feature Knowledge Graph + Sequenz (Domaene 3 Rename + Feature Library; Domaene 2 STOPP #59)

Browse Source 
User-Entscheidung: Domaene 3 = „Feature Knowledge Graph" (Kunden kaufen Features, nicht
Capabilities — Advisor beginnt bei „Fernwartung", nicht „cap.transport_encryption"). Besitzt
zusaetzlich Feature Library (~200-400 Features) != Product Profile. Volle Pipeline
Feature Library -> Product Profile -> Capabilities -> Obligations -> Procedures -> Controls -> Evidence.
SEQUENZ: (1) cap.*-Vertrag JETZT an Domaene 3 uebergeben (Multiplikator); (2) Domaene 3 Vollgas
(Feature->cap.*); (3) Domaene 2 STOPP bei #59 (Capability Registry STABIL, nur Bugfixes, bis
Domaene 3 den realen Bedarf zeigt); (4) Domaene 1 Re-Ingest/Spans/Citation.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
Benjamin Admin
2026-06-26 10:45:46 +02:00
parent 2063615d37
commit 429ac957c1
1 changed files with 26 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs-src/development/session_ownership_model_v1.md
+26
View File
@@ -98,3 +98,29 @@ Evidence Library`; darauf sitzen Advisor · Runtime · Auditor · Ticket-System
Assistent — **alle auf derselben Wissensbasis**. Die **Capability Library/Registry ist der Dreh- und 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** Angelpunkt** zwischen Product- und Compliance-Graph → muss ein **stabiler, versionierter API-Vertrag**
sein (stabile `cap.*`-IDs, nie umbenennen; produktneutral). Das ist #59. 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.