Benjamin Admin
fa536f9714
User-Entscheidung: Metamodell als v1.0 einfrieren (nur META-SEMANTIK: 6 Klassen + Kanten- Vokabular + Attribute; NICHT Registry/Capabilities/Procedures). Architektur-Freeze in Kraft: neue Regulierung = DATEN nicht Architektur; 0 neue Objektklassen erwartet; reopen nur bei nachgewiesenem Scheitern (Hazard/Threat = einzige bekannte künftige Öffnungs-Ursache, nur fuer FMEA). Reuse-Metrik-KPI definiert (Wissens-Akkumulations-Beweis). Validiert gegen 5 Regulierungsarten (DSGVO/CRA/MaschVO/Data-Act/NIS2). Erster Live-Durchlauf: MaschVO. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
109 lines
5.9 KiB
Markdown
109 lines
5.9 KiB
Markdown
# 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".
|