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

feat: Ownership-Konflikt #1 RESOLVED (Capability = geteilter Knoten) + Reasoning#1 Re-Link

Browse Source 
User-Entscheidung: Feature->Capability + Certificate->Capability = Session 3 (Domaene 3), NICHT
Compliance. Capability = GETEILTER Knoten: eingehende Kanten (Feature/Cert->Cap) = Domaene 3 ·
Knoten+IDs+ausgehende Kanten (Cap->Obligation/Procedure/Control/Evidence) = Domaene 2. Expliziter
Vertrag: „Domaene 2 besitzt NIE Wissen, welche Produkte/Zertifikate welche Capabilities brauchen."
+ Ownership-Tabelle in session_ownership_model_v1.md.
Reasoning#1 (Domaene 2, Registry-Kanonisierung): obligations/proposed_obligation_canonical_map.json
— 5 machine_* -> cra_machinery (re-link, Ziele validiert), 7 data_act_*/cra_* pending (Regulierung
nicht geschnitten). RE-LINK, kein Re-Mint.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
Benjamin Admin
2026-06-26 21:54:07 +02:00
parent 37c9b8e773
commit aaacec087c
2 changed files with 54 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs-src/development/session_ownership_model_v1.md
+32
View File
@@ -148,3 +148,35 @@ Output: je Feature die Lücken — fehlende Capability · fehlende Procedure ·
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** |