From 75f7bd8de4b012f7c37ec28a56091b5bf5af7c78 Mon Sep 17 00:00:00 2001 From: Benjamin Admin Date: Fri, 26 Jun 2026 01:08:57 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20meta=5Fmodel=5Fvalidation=5Fv1.md=20(Ph?= =?UTF-8?q?ase=206)=20=E2=80=94=20Modell=20ist=20regulierungsunabhaengig?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit User-Stresstest VOR der naechsten Regulierung: passt MaschVO/Data-Act/AI-Act/NIS2 ins 6-Klassen-Modell (Obligation/Capability/Procedure/Control/Evidence + Guidance) OHNE neue Objektklasse? Ergebnis 4x NEIN -> Compliance Meta Model steht. 2 Verfeinerungen (realized_by Capability OPTIONAL; Risiko-Niveau/Frist/Hazard-Schwere/Risiko-Tier = Attribute, keine Klassen). 1 Watch-Point: Hazard/Threat (erst noetig bei quantitativem FMEA-Risiko als First-Class-Knoten, nicht fuer Compliance-Abbildung). Kein Code, keine Regulierung ingestiert. Co-Authored-By: Claude Opus 4.7 --- .../development/meta_model_validation_v1.md | 159 ++++++++++++++++++ 1 file changed, 159 insertions(+) create mode 100644 docs-src/development/meta_model_validation_v1.md diff --git a/docs-src/development/meta_model_validation_v1.md b/docs-src/development/meta_model_validation_v1.md new file mode 100644 index 00000000..8706bb47 --- /dev/null +++ b/docs-src/development/meta_model_validation_v1.md @@ -0,0 +1,159 @@ +# 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.