breakpilot-compliance/docs-src/development/compliance_meta_model_v1.md

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, capability_model_v1.md (Modell C), 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".