# 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".