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

docs: Architekturprinzip — Ownership auf BEZIEHUNGEN, nicht Knoten + cap.*=kanonische ID

Browse Source 
User-Reframe (die eigentliche Reife): nicht „Session X besitzt Knoten Y", sondern jede Session
besitzt KANTEN. Edge-Ownership-Tabelle: Feature/Cert->Cap = S3 · Cap->Obligation/Procedure/
Control/Evidence = S2 · Citation-Span->Legal-Basis = S1. Kein Owner hält alle ein+ausgehenden
Kanten eines Knotens. `cap.*` = kanonische ID auf obligation_id-Niveau. Capability = EINZIGER
Knoten über 3 Welten (Recht/Produkt/Nachweis) = semantischer Mittelpunkt. Künftiger Vertrag:
Confidence/Disambiguierung bei mehreren Capabilities = Domaene 3, Domaene 2 vertraut geliefertem
cap.X. Domaene 2 ruht stabil bis Wake-up.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
Benjamin Admin
2026-06-26 22:11:43 +02:00
parent 06efb9e61b
commit c7339e68df
1 changed files with 30 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs-src/development/session_ownership_model_v1.md
+30
View File
@@ -180,3 +180,33 @@ regulatorische Pflichten erfüllen.* (Verhindert, dass Domäne 2 zur Produktmode
| 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).