# Reference Scenario Suite v1

> **Kein Doku-Artefakt — die erste Ground Truth / Living Reference Suite.** Erzeugt aus den REALEN deployten Engines (aktueller deployter main) via `reference_scenarios/generate.py`. Jede `Architecture Coverage`-Zelle ist aus dem echten Lauf ABGELEITET; sobald eine Domaene landet, kippt die Zelle automatisch (z. B. Sz2/Environmental UNSUPPORTED -> PASS). Beantwortet dauerhaft: „Ist BreakPilot besser als vor sechs Monaten?" — anhand echter Kundensituationen, nicht LOC.

Synthetische `Cert->Capability`-Mappings sind als ILLUSTRATIV markiert; die echte Tabelle gehoert Compliance Execution (siehe Master Capability Registry).

## Szenario 1 — Maschinenbauer mit ISMS + SBOM + Remote Access

**Frage:** „Was gilt fuer uns, und reicht das?"

**Input:** Maschine, vernetzt (Remote/Cloud), Firmware, Rolle Hersteller, Maerkte EU/DE; Company: ISMS (ISO27001) + SBOM + Incident Response.

**Expected Regulatory Map**

> Für Industrielle Verpackungsmaschine (machinery) — Maschine; vernetzt; Firmware; Rolle: manufacturer; Märkte: EU, DE gelten nach derzeitigem Stand wahrscheinlich: CRA, MaschinenVO, EMV. Unsicher (fehlende Fakten): RED, DataAct, NIS2. Ausgeschlossen: keine. Nicht abgedeckt (Regelkorpus fehlt): keine. Ermittelt: 12 registry-verlinkte Pflichten. Es wurden keine weiteren Regelwerke im aktuellen Korpus identifiziert.

- **CRA** (Cyber Resilience Act (EU) 2024/2847) — Pflichten: sbom_creation, provide_security_updates, support_period_maintenance, signed_update_integrity, vuln_handling_process, coordinated_vulnerability_disclosure, exploited_vuln_reporting_authorities, user_authentication_required, no_default_credentials, event_logging_security_events, remote_access_attack_surface_min, remote_access_confidentiality_integrity
- **MaschinenVO** (Maschinenverordnung (EU) 2023/1230) — Pflichten: Pflichten für dieses Regelwerk sind noch nicht registry-verlinkt.
- **EMV** (EMV-Richtlinie 2014/30/EU) — Pflichten: Pflichten für dieses Regelwerk sind noch nicht registry-verlinkt.
- _unsicher_ RED — fehlt: Besitzt das Produkt ein Funkmodul (WLAN, Bluetooth, Mobilfunk)?
- _unsicher_ DataAct — fehlt: Erzeugt das vernetzte Produkt nutzbare Produkt-/Nutzungsdaten?
- _unsicher_ NIS2 — fehlt: Unternehmensgröße (Mitarbeiterzahl / Umsatz)?, In welchem Sektor ist das Unternehmen tätig (Anhang I/II)?, Fällt das Unternehmen als wesentliche/wichtige Einrichtung unter NIS2?
- Overlap VULNERABILITY_HANDLING: vuln_handling_process, coordinated_vulnerability_disclosure
- Overlap SECURITY_UPDATES: provide_security_updates, signed_update_integrity
- 1 Nachweis `repo_scan` => 2 Pflichten
- 1 Nachweis `policy` => 5 Pflichten
- 1 Nachweis `ticket` => 3 Pflichten
- 1 Nachweis `test_report` => 3 Pflichten
- 1 Nachweis `config_export` => 6 Pflichten
- 1 Nachweis `pentest` => 3 Pflichten

**Input — Company Context** _(ILLUSTRATIVES Mapping: ISO27001 -> incident_response, supplier_management, asset_management)_

- candidate: cap_patch_management — declared (declaration:maschinenbau)
- candidate: cap_incident_response — inferred (certification:ISO27001)
- candidate: cap_supplier_management — inferred (certification:ISO27001)
- candidate: cap_asset_management — inferred (certification:ISO27001)
- CONFIRMED: cap_sbom_management — confirmed (Nachweis: sbom.json)

**Expected Interpretation**

> Auslegung „5 Jahre Updates -> CRA erfuellt" -> **uncertain**
> Ihre Interpretation ist wahrscheinlich unsicher. Kein bekanntes Auslegungsmuster erkannt — bewusst keine Scheinsicherheit. Diese Auslegung betrifft kein Regelwerk Ihrer aktuellen Produkt-Map.

**Expected RCI** _(CRA-Novelle gegen gespeicherte Baseline)_

> affects_product = True — 1 neu, 2 geändert, 0 entfällt, 0 bereits abgedeckt, 2 zu prüfen, 0 nicht relevant.
- cra_new_disclosure_duty -> **new** (fehlende Nachweise: -)
- sbom_creation -> **changed** (fehlende Nachweise: repo_scan)
- vuln_handling_process -> **changed** (fehlende Nachweise: policy, ticket)

**Expected Unsupported Domains**

- keine — alle getriggerten Domaenen sind im Korpus

**Known Gaps:** Interpretation kennt kein CRA-Muster (RS-001) · MaschinenVO/EMV-Pflichten nicht registry-verlinkt (RS-004) · cap/MCAP/Pflicht-Evidence nicht gejoint = Company-Gap (RS-003).

**Architecture Coverage**

| Layer | Status | Hinweis |
|---|---|---|
| Company Context | **PASS** | ISO27001 + SBOM + Declaration |
| Product Profile | **PASS** | Maschine, vernetzt, Firmware |
| Navigator | **PASS** | ready_for_scope |
| Scope | **PASS** | CRA/MaschinenVO/EMV + 3 unsicher |
| Regulatory Map | **PASS** | Overlaps + 1-Nachweis-N-Pflichten |
| CRA Obligations | **PASS** | 12 registry-verlinkt |
| MaschinenVO/EMV Obligations | **PARTIAL** | Scope ja, Pflichten nicht verlinkt → RS-004 |
| Interpretation | **PARTIAL** | kein CRA-Muster → RS-001 |
| RCI | **PASS** | 1 neu, 2 geaendert |
| Company Gap | **TODO** | cap↔MCAP↔Pflicht nicht gejoint → RS-003 |
| Environmental | **N/A** | keine Umwelt-Trigger |

## Szenario 2 — Industriespuelmaschine mit Abwasser/Chemikalien

**Frage:** „Welche Umweltbereiche sind noch nicht abgedeckt?"

**Input:** Maschine mit Chemikalien-Dosierung + Abwasserauslass; Umwelt-Trigger gesetzt.

**Expected Regulatory Map**

> Für Industriespuelmaschine (machinery) — Maschine; Firmware; Rolle: manufacturer; Märkte: EU, DE gelten nach derzeitigem Stand wahrscheinlich: CRA, MaschinenVO, EMV. Unsicher (fehlende Fakten): RED, DataAct, NIS2. Ausgeschlossen: keine. Nicht abgedeckt (Regelkorpus fehlt): environment_water, chemicals, energy_resources. Ermittelt: 10 registry-verlinkte Pflichten. Es wurden keine weiteren Regelwerke im aktuellen Korpus identifiziert.

- **CRA** (Cyber Resilience Act (EU) 2024/2847) — Pflichten: sbom_creation, provide_security_updates, support_period_maintenance, signed_update_integrity, vuln_handling_process, coordinated_vulnerability_disclosure, exploited_vuln_reporting_authorities, user_authentication_required, no_default_credentials, event_logging_security_events
- **MaschinenVO** (Maschinenverordnung (EU) 2023/1230) — Pflichten: Pflichten für dieses Regelwerk sind noch nicht registry-verlinkt.
- **EMV** (EMV-Richtlinie 2014/30/EU) — Pflichten: Pflichten für dieses Regelwerk sind noch nicht registry-verlinkt.
- _unsicher_ RED — fehlt: Besitzt das Produkt ein Funkmodul (WLAN, Bluetooth, Mobilfunk)?
- _unsicher_ DataAct — fehlt: Erzeugt das vernetzte Produkt nutzbare Produkt-/Nutzungsdaten?
- _unsicher_ NIS2 — fehlt: Unternehmensgröße (Mitarbeiterzahl / Umsatz)?, In welchem Sektor ist das Unternehmen tätig (Anhang I/II)?, Fällt das Unternehmen als wesentliche/wichtige Einrichtung unter NIS2?
- Overlap VULNERABILITY_HANDLING: vuln_handling_process, coordinated_vulnerability_disclosure
- Overlap SECURITY_UPDATES: provide_security_updates, signed_update_integrity
- 1 Nachweis `policy` => 5 Pflichten
- 1 Nachweis `ticket` => 3 Pflichten
- 1 Nachweis `test_report` => 3 Pflichten
- 1 Nachweis `config_export` => 4 Pflichten

**Expected Unsupported Domains**

- `environment_water` (Trigger: discharges_to_wastewater) -> Abwasser-/Gewässerrecht (z. B. AbwV, WRRL) — noch nicht im Korpus.
- `chemicals` (Trigger: uses_cleaning_chemicals) -> Chemikalienrecht (REACH/CLP/Detergenzien/Biozide) — noch nicht im Korpus.
- `energy_resources` (Trigger: consumes_energy_or_water) -> Energie-/Ökodesign-Recht — noch nicht im Korpus.

**Expected Interpretation** _(Umwelt -> bewusst nicht bewertet)_

> Ihre Interpretation ist wahrscheinlich unsicher. Kein bekanntes Auslegungsmuster erkannt — bewusst keine Scheinsicherheit. Für environment_water, chemicals liegt noch kein Regelkorpus vor — diese Aspekte werden nicht bewertet (future_corpus_needed).

**Known Gaps:** Abwasser/Chemikalien/Energie sind `unsupported_domain` — Environmental Corpus fehlt (RS-002).

**Architecture Coverage**

| Layer | Status | Hinweis |
|---|---|---|
| Product Profile | **PASS** | Maschine + Umwelt-Komponenten |
| Scope | **PASS** |  |
| Regulatory Map | **PASS** | CRA/MaschinenVO/EMV |
| Environmental (Abwasser/Chemikalien/Energie) | **UNSUPPORTED** | ehrlich „noch nicht im Korpus" → RS-002 |
| Interpretation (Umwelt) | **PARTIAL** | future_corpus_needed statt Scheinsicherheit |

## Szenario 3 — ISO27001-zertifiziertes Unternehmen

**Frage:** „Welche Capabilities sind inferred, declared oder confirmed?"

_ILLUSTRATIVES Mapping: ISO27001 -> incident_response, supplier_management, asset_management_

**Expected Company Capability Profile** _(4-Zustands-Trust-Model)_

- cap_incident_response — **inferred** (Quelle: certification:ISO27001)
- cap_supplier_management — **inferred** (Quelle: certification:ISO27001)
- cap_asset_management — **inferred** (Quelle: certification:ISO27001)
- cap_patch_management — **confirmed** (Nachweis: patch-policy.pdf)

**Expected Master Capability Registry** _(computed confidence, policy-versioniert)_

- ISO27001 *supports* MCAP-00001 -> inferred/low (policy capability-policy-v0) — computed, nicht gespeichert
- ir-runbook.pdf *confirms* MCAP-00001 -> confirmed/high — nur echtes Artefakt erreicht confirmed

**Known Gaps:** `cap_*` (Company 2A) und `MCAP-*` (Registry) sind noch nicht verlinkt (RS-003).

**Architecture Coverage**

| Layer | Status | Hinweis |
|---|---|---|
| Company Context | **PASS** | ISO27001 + Declaration + Evidence |
| Trust-State (declared/inferred/confirmed) | **PASS** | Zertifizierung nie confirmed |
| Master Capability Registry | **PASS** | computed confidence, policy-versioniert |
| cap ↔ MCAP Linking | **TODO** | zwei Vokabulare unverbunden → RS-003 |

## Szenario 4 — Transition (RS-005 fährt JEDEN Knowledge Pattern)

_Genericity-Beweis: derselbe Algorithmus trägt jeden Transition Knowledge Pattern, nicht nur den CRA._

**ISO/IEC 27001 → TISAX** _(TP-ISMS-TISAX-v1, status=draft)_
> 13 zu klären, 0 bereits abgedeckt, 8 vermutlich vorhanden, 5 fehlt, 0 n/a, 0 nicht im Korpus.
- Delta zuerst (HIGH): data_protection_processing_on_behalf, prototype_protection, tisax_assessment_via_enx, tisax_label_scope_selection, vda_isa_self_assessment
- vermutlich abgedeckt: information_security_management, access_control_and_authentication, asset_and_configuration_management, incident_management, supplier_security, cryptography, physical_security, security_awareness_training
- Pattern getragen: **ja** (13 caps → 13 coverage + 13 requests)

**ISO/IEC 27001 → Cyber Resilience Act** _(TP-ISO27001-CRA-v1, status=reviewed)_
> 17 zu klären, 0 bereits abgedeckt, 8 vermutlich vorhanden, 9 fehlt, 0 n/a, 0 nicht im Korpus.
- Delta zuerst (HIGH): ce_conformity_assessment_and_technical_documentation, coordinated_vulnerability_disclosure, exploited_vuln_and_incident_reporting, product_cyber_risk_assessment, public_security_advisories, sbom_creation, secure_by_default_no_default_credentials, secure_signed_update_distribution, security_update_support_period
- vermutlich abgedeckt: incident_management, technical_vulnerability_management, supplier_security, access_control_and_authentication, cryptography, security_logging_and_monitoring, secure_development_lifecycle, asset_and_configuration_management
- Pattern getragen: **ja** (17 caps → 17 coverage + 17 requests)

**ISO 9001 → Cyber Resilience Act** _(TP-ISO9001-CRA-v1, status=draft)_
> 13 zu klären, 0 bereits abgedeckt, 3 vermutlich vorhanden, 10 fehlt, 0 n/a, 0 nicht im Korpus.
- Delta zuerst (HIGH): access_control_and_authentication, ce_conformity_assessment_and_technical_documentation, coordinated_vulnerability_disclosure, exploited_vuln_and_incident_reporting, product_cyber_risk_assessment, sbom_creation, secure_development_lifecycle, secure_signed_update_distribution, security_update_support_period, technical_vulnerability_management
- vermutlich abgedeckt: document_and_change_control, supplier_evaluation, release_and_approval_process
- Pattern getragen: **ja** (13 caps → 13 coverage + 13 requests)

**Architecture Coverage**

| Layer | Status | Hinweis |
|---|---|---|
| Transition ISOIEC27001→TISAX | **PASS** | draft · 5 HIGH-Delta + 8 zu bestätigen |
| Transition ISOIEC27001→Cyber Resilience Act | **PASS** | reviewed · 9 HIGH-Delta + 8 zu bestätigen |
| Transition ISO9001→Cyber Resilience Act | **PASS** | draft · 10 HIGH-Delta + 3 zu bestätigen |
| RS-005.1 Renderer (Fragetext) | **TODO** | verschoben — Engine liefert nur Requests |

## Reference Transition Scenarios (RTS) — kanonische Regression (Soll/Ist)

_Anonymisierte Archetypen (KEINE Firmennamen). Jeder RTS pinnt ein Expected Outcome; jeder Commit muss es reproduzieren (identisch oder besser). Data Act = `uncertain`, nie fix „gilt/gilt-nicht"._

**RTS-001** — Automotive supplier with a mature ISMS — embedded electronics + software, CE products, OEM supply chain
> Start TISAX+ISO27001 → CRA. 17 zu klären, 0 bereits abgedeckt, 8 vermutlich vorhanden, 9 fehlt, 0 n/a, 0 nicht im Korpus.
- Expected Delta erfüllt: **ja** (7/7 Soll-Delta in der Ist-Lücke)
- Expected likely_covered erfüllt: **ja**
- Data Act: Engine sagt **uncertain** (Soll: uncertain; nie asserted) → ok
- MaschinenVO: Soll **uncertain** (Komponente, deciding: is_safety_component) → Engine asserted nicht: ok

**RTS-002** — Classic machine builder with only a QMS — precision systems, CE products, no ISMS
> Start ISO9001 → CRA. 13 zu klären, 0 bereits abgedeckt, 3 vermutlich vorhanden, 10 fehlt, 0 n/a, 0 nicht im Korpus.
- Expected Delta erfüllt: **ja** (9/9 Soll-Delta in der Ist-Lücke)
- Expected likely_covered erfüllt: **ja**
- Data Act: Engine sagt **uncertain** (Soll: uncertain; nie asserted) → ok
- MaschinenVO **gilt** (is_machine): Safety-Delta machine_safety_risk_assessment, mechanical_safety_and_guards, operating_instructions_and_safety_information — **geringe Konvergenz ohne ISMS** (RS-004 reg-map-Gate offen)

**RTS-003** — Machine builder with an ISMS and networked products — connected machines that may generate usage data
> Start ISO27001 → CRA. 17 zu klären, 0 bereits abgedeckt, 8 vermutlich vorhanden, 9 fehlt, 0 n/a, 0 nicht im Korpus.
- Expected Delta erfüllt: **ja** (7/7 Soll-Delta in der Ist-Lücke)
- Expected likely_covered erfüllt: **ja**
- Data Act: Engine sagt **uncertain** (Soll: uncertain; nie asserted) → ok
- MaschinenVO **gilt** (is_machine): 4/4 Safety-Delta in der Ist-Lücke (Convergence-Pattern) → ok
- Konvergenz CRA∩MaschinenVO: 4/4 erwartete Multi-Target-Caps → ok (4 von 12 Capabilities decken >= 2 Regelwerke gleichzeitig ab (CRA + MaschinenVO).)

**Architecture Coverage**

| Layer | Status | Hinweis |
|---|---|---|
| RTS-001 (TISAX→CRA+MaschVO) | **PASS** | 7/7 Delta-Soll · likely_covered ok · DataAct=uncertain · MaschVO=uncertain(ok) |
| RTS-002 (ISO9001→CRA+MaschVO) | **PASS** | 9/9 Delta-Soll · likely_covered ok · DataAct=uncertain · MaschVO=applies (geringe Konvergenz, kein ISMS) |
| RTS-003 (ISO27001→CRA+MaschVO) | **PASS** | 7/7 Delta-Soll · likely_covered ok · DataAct=uncertain · MaschVO=applies 4/4 Safety-Delta · Konvergenz ok |

## Regulatory Convergence — CRA + MaschinenVO (Cross-Regulation Capability Mapping)

_Der USP: welche Capability deckt MEHRERE Regelwerke gleichzeitig? (Convergence Pattern, RTS-003-Archetyp.)_

**Cross-Regulation Capability Mapping (Delta):** 4 von 12 Capabilities decken >= 2 Regelwerke gleichzeitig ab (CRA + MaschinenVO).

**Konvergenz — diese neuen Maßnahmen decken BEIDE Regelwerke gleichzeitig:**
- `ce_conformity_assessment_and_technical_documentation`
- `product_cyber_risk_assessment`
- `protection_against_corruption_of_safety_functions`
- `secure_signed_update_distribution`

**Pro Regelwerk benötigt (Delta):** CRA=9, MaschinenVO=7

**Kundensatz:** „Von den 12 neuen Maßnahmen erfüllen 4 gleichzeitig CRA und MaschinenVO." (heute liefert das praktisch kein Tool)

**Architecture Coverage**

| Layer | Status | Hinweis |
|---|---|---|
| Regulatory Convergence Pattern | **PASS** | 2 Targets, 12 Delta-Capabilities |
| Cross-Regulation Capability Mapping | **PASS** | 4 von 12 Capabilities decken >= 2 Regelwerke gleichzeitig ab (CRA + MaschinenVO). |

## Regulatory Optimization — größter regulatorischer Hebel zuerst

_Dieselbe Berechnung wie die GAP-Analyse, anderer Renderer: das **Capability Delta** (RS-005) wird nach **regulatorischem Hebel** priorisiert (eine Maßnahme schließt N Regelwerke gleichzeitig). Welt-1: % über die IDENTIFIZIERTEN Anforderungen, kein Compliance-Urteil._

**Kompression:** 16 identifizierte Anforderungen aus 2 Regelwerken -> 12 Massnahmen (Ø Hebel 1.3).

**Top-Maßnahmen nach regulatorischem Hebel (Roadmap):**

| # | Maßnahme | Hebel | deckt | kumuliert |
|---|---|---|---|---|
| 1 | `ce_conformity_assessment_and_technical_documentation` | **2** | CRA+MaschinenVO | 2/16 (12%) |
| 2 | `product_cyber_risk_assessment` | **2** | CRA+MaschinenVO | 4/16 (25%) |
| 3 | `protection_against_corruption_of_safety_functions` | **2** | CRA+MaschinenVO | 6/16 (38%) |
| 4 | `secure_signed_update_distribution` | **2** | CRA+MaschinenVO | 8/16 (50%) |
| 5 | `coordinated_vulnerability_disclosure` | **1** | CRA | 9/16 (56%) |
| 6 | `exploited_vuln_and_incident_reporting` | **1** | CRA | 10/16 (62%) |

**Managementsatz:** „Wenn Sie zuerst diese 5 Maßnahmen umsetzen, schließen Sie 9 von 16 identifizierten Anforderungen (56%) — höchster regulatorischer Hebel." (Hebel skaliert mit jedem weiteren Regelwerk/Convergence-Pattern.)

_Eine Wahrheit, zwei Renderer: dasselbe Capability Delta liefert dem Auditor **Fragen** (Interview) und dem GF **Maßnahmen** (Roadmap)._

**Architecture Coverage**

| Layer | Status | Hinweis |
|---|---|---|
| Capability Delta Engine (RS-005) | **PASS** | ein Delta, mehrere Renderer |
| Roadmap/Management Renderer (Hebel) | **PASS** | 16 identifizierte Anforderungen aus 2 Regelwerken -> 12 Massnahmen (Ø Hebel 1.3). |
| Budget-Priorisierung | **PASS** | Top-5 → 56% der identifizierten Anforderungen |

## Implementation Playbook — wie komme ich dort hin? (Berater-Renderer)

_Nach „was fehlt?" (Delta) und „womit anfangen?" (Hebel) die nächste Ebene: **wie umsetzen?** Pro Maßnahme eine komplette Reise aus kuratiertem Wissen + Hebel + (injizierten) Execution-Links. Inhalt ist der Engpass, nicht die Software._

**Reise pro Maßnahme (aus der Roadmap):** 2 von 12 Maßnahmen haben ein Playbook; 10 brauchen noch Inhalt (Knowledge Acquisition).

**Beispielreise — `sbom_creation`** _(draft, schließt CRA)_
> **Warum?** Der CRA verlangt von Herstellern, die Komponenten ihres Produkts zu identifizieren und zu dokumentieren (Schwachstellenbehandlung, Annex I Teil II). Eine SBOM ist das maschinenlesbare Inventar aller (auch transitiven) Software-Bestandteile mit Version und Lizenz. Ohne SBOM kann niemand verlässlich sagen, welche Produkte von einer neuen Schwachstelle (CVE) betroffen sind — SBOM ist damit die Voraussetzung für Schwachstellenüberwachung, Security-Updates und Meldepflichten.
- **Tools:** CycloneDX (Format, OWASP), SPDX (Format, Linux Foundation), Syft (Generator, Container/Filesystem), cdxgen (Generator, Multi-Ökosystem), Trivy (Generator + Scan), OWASP Dependency-Track (Verwaltung + kontinuierliche Überwachung)
- **Prozess:** Format festlegen → Automatisch im Build erzeugen → Transitive Abhängigkeiten + Versionen + Lizenzen erfassen → Pro Release versionieren und ablegen → An Schwachstellenüberwachung anbinden → Release-Gate setzen
- **Nachweise:** Maschinenlesbare SBOM (CycloneDX/SPDX) je ausgelieferter Produktversion, CI-Job-Konfiguration, die die SBOM automatisch erzeugt, Dependency-Track-Projekt (oder gleichwertig) mit laufender Überwachung
- **Wie andere es tun:** Verbreitete Praxis: CycloneDX automatisch in der CI via Syft/cdxgen erzeugen und nach OWASP Dependency-Track pushen, das kontinuierlich gegen neue CVEs prüft. Reifere Organisationen gaten Releases auf das Vorhandensein einer SBOM und teilen sie auf Anfrage mit Kunden/Behörden.

**Roadmap → Implementation (Top-Maßnahmen nach Hebel):**

| Maßnahme | Hebel | schließt | Playbook |
|---|---|---|---|
| `ce_conformity_assessment_and_technical_documentation` | 2 | CRA+MaschinenVO | **fehlt (Inhalt)** |
| `product_cyber_risk_assessment` | 2 | CRA+MaschinenVO | **fehlt (Inhalt)** |
| `protection_against_corruption_of_safety_functions` | 2 | CRA+MaschinenVO | **fehlt (Inhalt)** |
| `secure_signed_update_distribution` | 2 | CRA+MaschinenVO | **fehlt (Inhalt)** |
| `coordinated_vulnerability_disclosure` | 1 | CRA | ✓ draft |
| `exploited_vuln_and_incident_reporting` | 1 | CRA | **fehlt (Inhalt)** |

_Derselbe Capability-Strang, neuer Renderer: aus Diagnose wird Beratung. Die `fehlt`-Einträge sind der ehrliche Content-Backlog (höchster Hebel zuerst befüllen)._

**Architecture Coverage**

| Layer | Status | Hinweis |
|---|---|---|
| Implementation Playbook Renderer | **PASS** | Reise pro Capability (why/tools/process/evidence/controls) |
| Roadmap → Playbook (Verkettung) | **PASS** | 2/12 Maßnahmen mit Playbook |
| Playbook-Inhalt (Knowledge) | **TODO** | 10 Capabilities brauchen noch Inhalt |

## Knowledge Production — Playbook-Entwürfe automatisch assemblieren

_Der Engpass ist nicht Content, sondern Wissensproduktion. Der Corpus wird nicht von Hand geschrieben, sondern deterministisch aus vorhandenen Daten (Transition Pattern + Leverage + injizierte Controls) vorbereitet — dann fachlich kuratiert (wie Gesetz→Parser→Obligation→Review)._

**Aus 1 Pattern → 12 Playbook-Entwürfe** (`status: draft_generated`): eigene Felder (Warum/schließt/Nachweise) aus den Daten gefüllt, der Experte ergänzt nur Tools/Prozess/How-others.

**Beispiel-Entwurf — `sbom_creation`** _(draft_generated)_
- **Warum** (aus Pattern): CRA requires an SBOM; MaschinenVO does not.
- **schließt** CRA · **Nachweise** sbom
- **Provenance:** why←transition_pattern:why_asked, closes_regulations←leverage:covers_targets, expected_evidence←transition_pattern:expected_evidence
- **TODO (Experte/Offline-Propose):** tools, process_steps, how_others_do_it

_So reviewt der Experte 12 Entwürfe statt 12 Playbooks zu schreiben. Derselbe Generator bereitet später ISO14001-/IATF-Entwürfe vor, sobald der Corpus da ist._

**Architecture Coverage**

| Layer | Status | Hinweis |
|---|---|---|
| Playbook Draft Generator (deterministisch) | **PASS** | 12 Entwürfe aus 1 Pattern, kein LLM im Kern |
| Provenance + TODO + Freigabestatus | **PASS** | draft_generated→reviewed→validated→proven |
| Draft-Generatoren neue Domänen (Phase A) | **TODO** | Transition-/Reference-Scenario-Drafts |

## Knowledge Intake — Impact zuerst, Extraktion später

_Vor dem Parser: ein neues Dokument NUR einordnen und seinen Impact auf den bestehenden Wissensbestand bestimmen. „Von N Dokumenten verändern wenige tatsächlich unser Wissen." Deterministisch, keine Extraktion, kein LLM._

| Dokument | Impact | betrifft | Empfehlung |
|---|---|---|---|
| ENISA CRA SBOM-FAQ | **high** | 14C·2PB·3RTS·2Obl | Gezielter Review priorisieren |
| EU Umwelt-Leitfaden | **new_domain** | neue Domäne | Neue Domäne |
| Marketing-Blog | **none** | 0C·0PB·0RTS·0Obl | Wahrscheinlich ignorierbar |

**Beispiel-Knowledge-Package** (`ENISA CRA SBOM-FAQ`): Betrifft 14 Capabilities, 2 Playbooks, 0 Patterns, 3 Reference Scenarios, 2 Obligations; keine neue Domäne.

_So entsteht bei jedem neuen Dokument eine Impact-Analyse statt „200 Seiten PDF" — Targeted Updating statt Schreiben._

**Architecture Coverage**

| Layer | Status | Hinweis |
|---|---|---|
| Knowledge Intake (Klassifikation+Impact) | **PASS** | 6 Regelwerke / 32 Capabilities im Index |
| Impact-Triage (HIGH/LOW/NONE/new_domain) | **PASS** | 3 Beispiel-Dokumente korrekt eingeordnet |
| Regelwerk-ID-Normalisierung | **TODO** | CRA vs Cyber Resilience Act vereinheitlichen |

## Regulatory Completeness — was wir bewerten konnten, und was bewusst nicht

_Interne Qualitätsmaschine (KEIN Confidence-Score): trennt IDENTIFIZIERT von BEWERTET und begründet jede Lücke. Keine Prozentzahl — auditierbar und ehrlich: „Wir zeigen auch, was wir noch nicht wissen und warum."_

**Identifiziert 5 · bewertet 2 · offen 3 · Unsicherheiten 1 · Begründung ja**

> Für dieses Produkt konnten wir 2 von 5 identifizierten regulatorischen Domänen vollständig bewerten. 3 weitere sind noch nicht Bestandteil des validierten Korpus bzw. anwendungsunsicher und wurden deshalb bewusst nicht bewertet.

- **Bewertet:** CRA, MaschinenVO (128 Pflichten)
- **Offen (jeweils begründet):**
  - `DataAct` — generates_usage_data = unbekannt `[query_required]` → Rückfrage: `generates_usage_data`
  - `EMV` — nicht im validierten Korpus `[future_corpus]`
  - `Environmental` — nicht im validierten Korpus `[future_corpus]`
- **Annahmen:** Funkmodul=nein, personenbezogene Nutzungsdaten=nein

_Sobald der Umwelt-Korpus (ISO 14001 etc.) landet, kippt `Environmental` automatisch von offen auf bewertet — die Completeness Engine dokumentiert den Fortschritt je Domäne._

**Architecture Coverage**

| Layer | Status | Hinweis |
|---|---|---|
| Regulatory Completeness (auditierbar) | **PASS** | Identifiziert 5 · bewertet 2 · offen 3 · Unsicherheiten 1 · Begründung ja |
| Begründete Ausschlüsse (Korpus/Anwendbarkeit) | **PASS** | 3 Ausschlüsse, alle mit Grund |
| Fortschritts-Doku je Domäne | **PASS** | Environmental offen→validated bei Korpus-Landung |

## Domain Knowledge Program v1 — Reifegrad je Domäne (reproduzierbarer KPI)

_Engpass = Domänenmodellierung. Jede Domäne läuft durch DIESELBE 7-Stufen-Produktionsstraße (Domain Model → Requirement Sources → Capability Registry → Transition Patterns → Playbooks → Reference Scenarios → Completeness). Reifegrad aus dem ECHTEN Korpus abgeleitet (computed-not-stored), keine Marketingzahl. Einstieg über Industry, nicht Regelwerk._

| Rank | Domäne | Reifegrad (Sources modelliert) | modelliert/total | Korpus TP·PB·RTS |
|---|---|---|---|---|
| 1 | **Industrial Automation Domain** | `████░░░░░░` 43% | 3/7 | 3·2·3 |
| 2 | **Environmental Domain** | `░░░░░░░░░░` 0% | 0/6 | 0·0·0 |
| 3 | **Automotive Domain** | `██░░░░░░░░` 17% | 1/6 | 1·0·0 |
| 4 | **Medical Domain** | `██░░░░░░░░` 20% | 1/5 | 3·2·3 |
| 5 | **Energy Domain** | `██░░░░░░░░` 25% | 1/4 | 3·2·3 |

_Industry-Einstieg + ETO-Hypothese: jede Domäne kennt ihre typischen Sources + Zertifikate → vor dem Onboarding „diese Prozesswelt ist wahrscheinlich vorhanden" (Hypothese, nie Wahrheit; speist Company 2A als `inferred`). Backlog nach Kundennutzen, KPI nach echtem Korpusstand — beides bewusst getrennt._

**Architecture Coverage**

| Layer | Status | Hinweis |
|---|---|---|
| Domain Knowledge Program (7-Stufen-Produktionsstraße) | **PASS** | 5 Domänen im Backlog, Industrial Automation #1 |
| Reifegrad-KPI (computed-not-stored) | **PASS** | aus echtem Korpus abgeleitet (TP/PB/RTS je Domäne) |
| Regelwerk-ID-Normalisierung (Domain Vocabulary) | **PASS** | Aliase aus `vocabulary/regulations.yaml`, nicht mehr hartkodiert |

## Transition Coverage — die Transition ist die Wissenseinheit (Operational Knowledge)

_Der Kunde kauft nicht „EMV-Domain", sondern „wir haben ISO 9001 — helfen Sie uns beim CRA". Die Wissenseinheit ist die TRANSITION (nicht das Gesetz). Status je Transition aus dem echten Pattern-Korpus abgeleitet (computed-not-stored). Drei Ebenen: Regulatory → **Operational (hier, größter Differenzierer)** → Verification (Vision V2)._

| Prio | Transition | Status |
|---|---|---|
| ⭐⭐⭐⭐⭐ | `ISO27001 → CRA` | ✅ reviewed |
| ⭐⭐⭐⭐⭐ | `ISO9001 → CRA` | 🟡 Draft |
| ⭐⭐⭐⭐⭐ | `ISO9001 → MaschinenVO` | ⚪ nicht begonnen |
| ⭐⭐⭐⭐ | `IEC62443 → CRA` | ⚪ nicht begonnen |
| ⭐⭐⭐⭐ | `TISAX → CRA` | ⚪ nicht begonnen |
| ⭐⭐⭐⭐ | `ISO27001 → NIS2` | ⚪ nicht begonnen |
| ⭐⭐⭐⭐ | `IEC62443 → NIS2` | ⚪ nicht begonnen |
| ⭐⭐⭐ | `ISO14001 → Umweltrecht` | ⚪ nicht begonnen |

**Größte Lücke (Track B als Nächstes):** `ISO9001 → MaschinenVO` (⭐⭐⭐⭐⭐) — höchstnachgefragte Transition OHNE Pattern. Stärkerer Produktindikator als „EMV 30% modelliert".

**Architecture Coverage**

| Layer | Status | Hinweis |
|---|---|---|
| Transition Coverage (Operational Knowledge) | **PASS** | 2 von 8 Top-Transitionen mit Pattern |
| Wissenseinheit = Transition (nicht Gesetz) | **PASS** | verkauft wird der Übergang, z. B. ISO9001→CRA |
| 3 Ebenen Regulatory→Operational→Verification | **PASS** | Operational = größter Differenzierer (ADR-010) |

## Gaps → Epics (Backlog — nur erfasst, NICHT implementiert)

| Epic | Titel | schliesst Coverage-Luecke |
|---|---|---|
| RS-001 | Interpretation Pattern Library | Sz1 Interpretation PARTIAL -> PASS (CRA-Muster) |
| RS-002 | Environmental Corpus (Pilotdomaene) | Sz2 Environmental UNSUPPORTED -> PASS |
| RS-003 | Capability Linking (cap↔MCAP) + Company-Gap | Sz1/Sz3 Company Gap TODO -> PASS |
| RS-004 | MaschinenVO/EMV Registry Linking | Sz1/Sz2 MaschinenVO/EMV PARTIAL -> PASS |

## Suite-Status (Roll-up)

- Coverage-Zellen gesamt: **50**
- PASS: **39** · PARTIAL: 3 · UNSUPPORTED: 1 · TODO: 6 · N/A: 1 · NEEDS_FACTS: 0
- Fortschritt = PASS-Anteil steigt, wenn Epics RS-001…004 landen (objektiver Maßstab, kein LOC).
