Merge remote-tracking branch 'origin/main' into feat/advisor-status
This commit is contained in:
Benjamin Admin
@@ -0,0 +1,108 @@
|
|||||||
|
# Compliance Operating System — Meta Model v1.0 (FROZEN)
|
||||||
|
|
||||||
|
> **STATUS: EINGEFROREN (2026-06-26). ARCHITEKTUR-FREEZE IN KRAFT.**
|
||||||
|
> Ab v1.0 dürfen neue Regulierungen das Modell **nicht mehr verändern** — sie müssen sich
|
||||||
|
> **einfügen**. Das Modell wird nur wieder geöffnet, wenn eine Regulierung **nachweislich
|
||||||
|
> scheitert** (eine Anforderung lässt sich ohne neue Objektklasse nicht abbilden).
|
||||||
|
> Validiert gegen 5 Regulierungsarten: DSGVO · CRA · MaschVO · Data Act · NIS2.
|
||||||
|
|
||||||
|
Konsolidiert + friert ein: [legal_obligation_layer_v1.md](legal_obligation_layer_v1.md),
|
||||||
|
[capability_model_v1.md](capability_model_v1.md) (Modell C), [meta_model_validation_v1.md](meta_model_validation_v1.md).
|
||||||
|
Was hier eingefroren wird, ist **ausschließlich die Meta-Semantik** — NICHT die Registry, NICHT die
|
||||||
|
Capabilities-Liste, NICHT die Procedures (diese wachsen als Daten weiter).
|
||||||
|
|
||||||
|
## 1. Objektklassen (6 + Guidance) — eingefroren
|
||||||
|
|
||||||
|
| Klasse | Was | Regulierungs-Bindung |
|
||||||
|
|---|---|---|
|
||||||
|
| **Regulation** | Rechtsakt | — |
|
||||||
|
| **Legal Obligation** | rechtlich verankerte Pflicht; **CORE ⊇ DOMAIN** | regulierungs-anchored |
|
||||||
|
| **Capability** | implementierbare technische Faehigkeit (OPTIONAL für eine Obligation) | **agnostisch** (n:m über Regulierungen) |
|
||||||
|
| **Procedure** | wiederholbarer operativer Prozess | agnostisch |
|
||||||
|
| **Control** | testbare Prüfanweisung | agnostisch |
|
||||||
|
| **Evidence** | Nachweis-Artefakt | agnostisch |
|
||||||
|
| **Guidance** *(quer)* | externe nicht-bindende Empfehlung (NIST/OWASP/ISO/BSI) — hängt an der **Capability** | agnostisch |
|
||||||
|
|
||||||
|
## 2. Die Kette + kanonisches Kanten-Vokabular — eingefroren
|
||||||
|
|
||||||
|
```
|
||||||
|
Regulation
|
||||||
|
↓ definiert
|
||||||
|
Legal Obligation (CORE ⊇ DOMAIN)
|
||||||
|
↓ realized_by (OPTIONAL — rein prozessuale/dokumentarische Obligations überspringen Capability)
|
||||||
|
Capability
|
||||||
|
↓ deployed_via (alias: operationalized_by)
|
||||||
|
Procedure
|
||||||
|
↓ verified_by
|
||||||
|
Control
|
||||||
|
↓ produces (alias: produces_evidence_for)
|
||||||
|
Evidence
|
||||||
|
→ Produktstatus
|
||||||
|
```
|
||||||
|
|
||||||
|
Kanten (gerichtet, eingefroren):
|
||||||
|
`specializes` (DOMAIN→CORE) · `realized_by` (Obligation→Capability) · `deployed_via` (Capability→Procedure) ·
|
||||||
|
`verified_by` (Procedure/Capability→Control) · `produces` (Procedure→Evidence) · `described_by` (Capability→Guidance) ·
|
||||||
|
`supports` / `depends_on` / `contributes_to` (Obligation↔Obligation) · `same_as` (Merge/Alias).
|
||||||
|
**Das Modell ist ein GRAPH, kein Baum** (n:m an realized_by, supports, produces).
|
||||||
|
|
||||||
|
## 3. Attribute (KEINE Klassen) — eingefroren
|
||||||
|
|
||||||
|
`applicability` · `tier` (LEGAL_MINIMUM/BEST_PRACTICE) · `legal_basis` (Primärrecht) ·
|
||||||
|
`guidance_basis` (NIST/OWASP/…, kanonisch an der Capability) · `objective_tags`
|
||||||
|
(integrity/confidentiality/attack_surface/… — Vorwärts-Kompat zu einer späteren Security-Objective-
|
||||||
|
Klasse) · `risk_level` · `deadline` · **`hazard` (Attribut, KEINE Klasse)**.
|
||||||
|
|
||||||
|
**Watch-Point (bewusste Nicht-Klasse):** `Hazard/Threat` bleibt ein Risiko-Treiber-Attribut. Es wird
|
||||||
|
*erst dann* eine eigene Klasse, wenn quantitatives Risiko (FMEA: Hazard→Risiko→Maßnahme) als
|
||||||
|
First-Class-Graph-Knoten modelliert werden soll — das ist die einzige bekannte künftige Öffnungs-Ursache.
|
||||||
|
|
||||||
|
## 4. Architektur-Freeze-Policy
|
||||||
|
|
||||||
|
1. **Neue Regulierung = Daten, nicht Architektur.** Sie läuft durch `Parser → Discovery-Pipeline →
|
||||||
|
Review → Registry` und fügt Obligations/Capabilities/Procedures/Evidence hinzu.
|
||||||
|
2. **Eine neue Objektklasse ist eine Architektur-Änderung** und erfordert explizite Wieder-Öffnung +
|
||||||
|
Begründung (nachgewiesenes Scheitern der Abbildung). Default-Erwartung: **0 neue Klassen.**
|
||||||
|
3. Verfeinerungen an Attributen (neues `*_tag`, neues risk-Attribut) sind erlaubt, solange keine
|
||||||
|
neue Klasse entsteht.
|
||||||
|
|
||||||
|
## 5. Reuse-Metrik (KPI je neuer Regulierung) — der Wissens-Akkumulations-Beweis
|
||||||
|
|
||||||
|
Für jede neue Regulierung gemessen (Baseline = der jeweils vorhandene Bestand):
|
||||||
|
|
||||||
|
| Kennzahl | Soll/Bedeutung |
|
||||||
|
|---|---|
|
||||||
|
| **Neue Objektklassen** | **= 0** (Invariante; sonst Freeze gebrochen) |
|
||||||
|
| Neue Capabilities | additiv (z.B. +8) |
|
||||||
|
| **Wiederverwendete Capabilities %** | Kern-KPI (z.B. NIS2 ~70–80 % erwartet) |
|
||||||
|
| Wiederverwendete Procedures % | (z.B. 58 %) |
|
||||||
|
| Wiederverwendete Evidence % | (z.B. 81 %) |
|
||||||
|
| Neue Obligations | additiv (z.B. +42) |
|
||||||
|
|
||||||
|
Zielaussage: *„Beim AI Act: 0 neue Objektklassen, 12 neue Capabilities, 41 neue Obligations,
|
||||||
|
78 % der vorhandenen Capabilities wiederverwendet."* → belegt, dass das System **Wissen akkumuliert**,
|
||||||
|
statt je Regulierung neu gebaut zu werden. (Tool zur Berechnung folgt mit dem ersten Live-Durchlauf.)
|
||||||
|
|
||||||
|
## 6. Der Burggraben (warum das mehr ist als ein Advisor / RAG)
|
||||||
|
|
||||||
|
Der Kunde denkt nicht in Artikeln, sondern: *„Wir haben Remote-Updates / signierte Firmware / einen
|
||||||
|
Vuln-Prozess."* Über die Capability-Schicht bildet das System diese Aussagen auf **alle betroffenen
|
||||||
|
Obligations mehrerer Regulierungen** ab und beantwortet die eigentliche Frage aus dem Kundengespräch:
|
||||||
|
> **„Habe ich das Gesetz richtig verstanden, und reicht das, was wir umgesetzt haben?"**
|
||||||
|
|
||||||
|
Das ist regel-/wissensgestütztes Reasoning über ein gemeinsames Modell — keine RAG-Aufgabe.
|
||||||
|
(Die Reasoning-Session hält dabei die Welt-Grenze: `ClaimCoverage` „potenziell relevant" ⊥
|
||||||
|
`ComplianceStatus` „erfüllt aus Nachweisen".)
|
||||||
|
|
||||||
|
## 7. Was NICHT eingefroren ist (wächst weiter als Daten)
|
||||||
|
|
||||||
|
Registry-Inhalte (Obligations je Regulierung), die Capabilities-Liste, Procedures, Evidence-Typen,
|
||||||
|
Applicability-Prädikate, Citation-Spans. Diese Schicht ist **Wissensaufbau** — explizit erwünschtes
|
||||||
|
Wachstum gegen das eingefrorene Modell.
|
||||||
|
|
||||||
|
## 8. Erster Live-Durchlauf (User-Priorität nach Informationswert)
|
||||||
|
|
||||||
|
1. **MaschVO** ⭐⭐⭐⭐⭐ — beweist „Compliance-OS ≠ Cybersecurity" (physische Safety, CE, Restgefahren).
|
||||||
|
2. **NIS2** ⭐⭐⭐⭐ — misst maximalen Capability-Reuse (erwartet 70–80 %).
|
||||||
|
3. **AI Act** ⭐⭐⭐⭐ — Risikoklassifizierung/Governance, vermutlich 0 neue Klassen.
|
||||||
|
4. **Data Act** ⭐⭐⭐ — bestätigt „Capability optional".
|
||||||
Reference in New Issue
Block a user