# 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](capability_model_v1.md) (Modell C, #5b materialisiert) +
[legal_obligation_layer_v1.md](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.