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

Meta-Model Validation v1 — Ist das Modell regulierungsunabhängig?

Status: Phase 6 — Meta-Validierung (2026-06-26). KEIN neues Coding, KEINE Regulierung ingestiert. Dieses Dokument ist der Stresstest VOR der nächsten Regulierung. Baut auf capability_model_v1.md (Modell C, #5b materialisiert) + legal_obligation_layer_v1.md.

Die eigentliche Frage

Nicht „welche Regulierung kommt als nächstes?", sondern:

Kann eine völlig neue Regulierung in dieses Modell eingeordnet werden, OHNE eine neue Objektklasse einzuführen?

Wenn ja für MaschVO + Data Act + AI Act + NIS2 → das ist kein CRA-Graph mehr, sondern ein Compliance Meta Model. Ab dann bringt jede Regulierung primär Daten, nicht Architektur.

Das zu testende Modell (6 Klassen + Attribute, KEINE weitere Klasse erlaubt)

Regulation
   ↓ definiert
Legal Obligation   (CORE ⊇ DOMAIN; tier=LEGAL_MINIMUM/BEST_PRACTICE; objective_tags[]; applicability)
   ↓ realized_by   (OPTIONAL)
Capability         (regulierungs-agnostische technische Faehigkeit; guidance_basis hier)
   ↓ deployed_via
Procedure
   ↓ verified_by
Control
   ↓ produces
Evidence

Quer: Guidance (NIST/OWASP/ISO/BSI) hängt an der Capability. Attribute (keine Klassen): tier, objective_tags, applicability, später deadline/risk_level/severity. Kanten: realized_by · specializes · contributes_to · deployed_via · verified_by · produces · described_by · same_as.

---

Test 1 — Maschinenverordnung (EU) 2023/1230

Modell-Klasse	MaschVO-Inhalt
Legal Obligation (CORE)	hazard_minimization (Sicherheits-Analogon zu attack_surface_minimization), safe_control_systems, machine_risk_assessment, ce_conformity, instructions_for_use — exakt die machine_*-Obligations, die die Reasoning-Session bereits unabhängig geprägt hat.
Capability	physische Sicherheitsfunktionen: emergency_stop, safety_interlock, two_hand_control, guarding, safe_torque_off. → die Capability-Klasse generalisiert von Cyber auf physische Safety (gleiche Klasse, andere Domäne).
Procedure	Risikobeurteilung (ISO 12100), CE-Konformitätsbewertung.
Evidence	Technische Unterlagen, Risikobeurteilungsbericht, Konformitätserklärung.

Stress-Punkt: „Hazard" (mechanisch/elektrisch/thermisch) = Schadensquelle — weder Obligation noch Capability. Kandidat für eine neue Klasse? → Nein, für die Repräsentation: ein Hazard ist ein Risiko-Treiber (Attribut/Applicability der Risikobeurteilungs-Procedure); eine Capability mitigiert einen Hazard, genau wie eine Cyber-Capability eine (implizite) Bedrohung kontert. PL/SIL = Attribut (wie tier). Hazard wird erst dann eine Klasse, wenn ihr quantitatives FMEA-Risiko als First-Class-Graph-Knoten wollt (vgl. project-fmea-safety-direction) — nicht für Compliance-Abbildung.

Verdikt: KEINE neue Klasse. (Stärkstes Ergebnis: die Capability-Klasse trägt von Cyber zu Safety.)

---

Test 2 — Data Act (EU) 2023/2854

Modell-Klasse	Data-Act-Inhalt
Legal Obligation	data_act_data_access_by_design, data_act_user_data_access, data_portability_switching, fair_contract_terms (FRAND), interoperability — deckt sich mit den data_act_*-Obligations der Reasoning-Session.
Capability	data_export_api, interoperability_interface, access_control (Reuse). ABER: fair_contract_terms hat KEINE technische Capability.
Procedure	FRAND-Klauseln entwerfen; Switching-Prozess.
Evidence	Vertrag/Klauselwerk, API-Doku.

Stress-Punkt: vertraglich-rechtliche Pflichten (FRAND, Verbot unfairer Klauseln) haben kein technisches Mittel. → Beleg, dass realized_by Capability OPTIONAL ist: manche Obligations werden rein über Procedure (Entwurf) + Evidence (Vertrag) erfüllt. Das ist KEINE neue Klasse — wir haben es schon gesehen (SBOM-Familie war Evidence-/Procedure-lastig, kaum Capability).

Verdikt: KEINE neue Klasse. Verfeinerung: Capability ist optional (Obligation → Procedure → Evidence ohne Capability ist gültig).

---

Test 3 — AI Act (EU) 2024/1689

Modell-Klasse	AI-Act-Inhalt
Legal Obligation	ai_risk_management_system, ai_data_governance, ai_technical_documentation, ai_transparency_disclosure, human_oversight, accuracy_robustness, fundamental_rights_assessment.
Capability	event_logging (Reuse!), bias_detection, accuracy_testing, human_oversight_mechanism, ai_transparency_notice.
Procedure	Risikomanagement-Prozess; FRIA-Durchführung; Human-Oversight-Prozess.
Evidence	Technische Dokumentation, FRIA-Bericht, Logs.

Stress-Punkt: Risiko-Klassifikation (unacceptable/high/limited/minimal) bestimmt, WELCHE Obligations gelten. → das ist Applicability (existiert bereits; analog zu CRA-Produktklasse). human_oversight = Procedure + Capability (Oversight-UI). transparency = Disclosure (Capability/Evidence, wie Cookie/DSE-Offenlegung). FRIA = Procedure + Evidence.

Verdikt: KEINE neue Klasse. Verfeinerung: Risiko-Tier = Applicability-Attribut (vorhanden).

---

Test 4 — NIS2 (EU) 2022/2555

Modell-Klasse	NIS2-Inhalt
Legal Obligation	nis2_risk_management_measures, nis2_incident_reporting, supply_chain_security, governance_accountability, business_continuity.
Capability	MFA, transport_encryption, security_monitoring_alerting, patch/update, backup — dieselben Capabilities wie CRA. Das ist die Auszahlung: NIS2-Obligations realized_by die bereits gebaute Capability-Schicht.
Procedure	Incident-Response-Prozess; Lieferketten-Audit; Governance-Prozess.
Evidence	Incident-Reports, Audit-Logs, Vorstandsprotokolle.

Stress-Punkt: Meldefristen (24h/72h/1 Monat) = zeitgebundene Procedure → deadline = Attribut. governance_accountability (Management-Haftung) = organisatorische Obligation → Procedure + Evidence.

Verdikt: KEINE neue Klasse. Stärkster Reuse-Fall (teilt die CRA-Capability-Schicht vollständig).

---

Ergebnis: 4 × NEIN → das Metamodell steht

Alle vier Regulierungen passen in die 6 Klassen ohne neue Objektklasse — unter zwei Verfeinerungen, die der Test selbst aufdeckt (beide sind KEINE neuen Klassen):

1. realized_by Capability ist OPTIONAL. Vertraglich/dokumentarisch/prozessuale Obligations (Data-Act-FRAND, NIS2-Governance, AI-Act-FRIA) werden rein über Procedure + Evidence erfüllt.
2. Risiko-Niveau / Frist / Hazard-Schwere / Risiko-Tier sind ATTRIBUTE, keine Klassen (tier-Muster: deadline, risk_level, severity, risk_tier).

Der einzige Watch-Point: Hazard / Threat. Heute implizit (Obligations existieren, um sie zu kontern). Eine eigene Klasse wird erst nötig, wenn ihr quantitatives Risiko first-class modelliert (FMEA: Hazard→Risiko→Maßnahme als Graph-Knoten). Für die reine Compliance-Abbildung: nicht nötig. → Das ist die präzise Antwort auf „wo wäre erstmals eine neue Klasse nötig?".

Empirische Stütze (nicht nur Theorie)

Die 3. Session (Reasoning Engine) hat unabhängig proposed=True-Obligations für MaschVO (machine_*) und Data Act (data_act_*) geprägt — und brauchte dafür keine neue Objektklasse, nur Obligation-IDs. Zwei Sessions kommen unabhängig zum selben Schluss.

Konsequenz für die Reasoning-Schicht (Produktvision)

Heute: Product → Applicable Regulations → Applicable Obligations. Mit der Capability-Schicht wird daraus:

Applicable Capabilities → Required Procedures → Expected Evidence

Antwort auf die Kundenaussage „Ich habe X umgesetzt" ist dann nicht „CRA Artikel …", sondern:

✓ Capability A   ✓ Capability B   ✗ Capability C
   ↓
erfüllt CRA, MaschVO, NIS2  (teilweise)

Eine Capability erfüllt Obligations über mehrere Regulierungen (n:m) → eine Umsetzung wird gegen das gesamte Regelwerk bewertet. Das ist qualitativ ein anderes Produkt als RAG.

Entscheidung / nächster Schritt

Wenn dieses Dokument akzeptiert ist („keine weitere Klasse nötig"), verschiebt sich die Arbeit von Architektur zu Wissensaufbau: jede neue Regulierung läuft durch Parser → Discovery-Pipeline → Review → Registry (vorhandene Tooling), statt das Modell zu ändern. Offen für den User: (a) Metamodell als stabil einfrieren? (b) den Hazard/Threat-Watch-Point als bewusste Nicht-Klasse dokumentieren (bis FMEA-Quantifizierung)? (c) dann erste Regulierung als DATEN.

Bewusst NICHT in diesem Schritt

Kein Code, keine Regulierung ingestiert, keine neue Klasse angelegt. Reiner Modell-Stresstest.