From 429ac957c10d29f0954cac2c03b2e7493dd0ee82 Mon Sep 17 00:00:00 2001 From: Benjamin Admin Date: Fri, 26 Jun 2026 10:45:46 +0200 Subject: [PATCH] docs: Feature Knowledge Graph + Sequenz (Domaene 3 Rename + Feature Library; Domaene 2 STOPP #59) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- .../development/session_ownership_model_v1.md | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/docs-src/development/session_ownership_model_v1.md b/docs-src/development/session_ownership_model_v1.md index 1838df12..c47abc88 100644 --- a/docs-src/development/session_ownership_model_v1.md +++ b/docs-src/development/session_ownership_model_v1.md @@ -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 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.