From c7339e68dfbfc75564e88615622de8da7bb1fd9a Mon Sep 17 00:00:00 2001 From: Benjamin Admin Date: Fri, 26 Jun 2026 22:11:43 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20Architekturprinzip=20=E2=80=94=20Owners?= =?UTF-8?q?hip=20auf=20BEZIEHUNGEN,=20nicht=20Knoten=20+=20cap.*=3Dkanonis?= =?UTF-8?q?che=20ID?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- .../development/session_ownership_model_v1.md | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/docs-src/development/session_ownership_model_v1.md b/docs-src/development/session_ownership_model_v1.md index 815e262e..e4dc6a8e 100644 --- a/docs-src/development/session_ownership_model_v1.md +++ b/docs-src/development/session_ownership_model_v1.md @@ -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).