diff --git a/docs-src/development/compliance_meta_model_v1.md b/docs-src/development/compliance_meta_model_v1.md new file mode 100644 index 00000000..dc9bd0cc --- /dev/null +++ b/docs-src/development/compliance_meta_model_v1.md @@ -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".