# Customer Mission #1 — Maschinenbauer: „Was muss ich in den nächsten 6 Monaten tun?"

_KEINE Demo, KEIN Reference Scenario — eine vollständige Simulation eines Beratungsprojekts mit den ECHTEN Engines. Gemessen wird, wie oft der Berater „springen" muss (Sonderlogik statt sauberem Engine-Fluss). Synthetischer Kunde, keine echten Namen._

## Der Kunde (synthetisch)
> ISO 9001 · ISMS (ISO 27001) · CE-Prozess · SPS · Fernwartung · Cloud · 80 Entwickler · Export EU
> **Eine Frage:** „Was muss ich in den nächsten sechs Monaten tun?"

## 1. Scope — was gilt? _(Regulatory Map)_
- **Gilt:** CRA, MaschinenVO, EMV
- **Unsicher (Rückfrage):** RED, DataAct, NIS2
- **Overlaps:** VULNERABILITY_HANDLING, SECURITY_UPDATES

## 2. Journey — welche Übergänge? _(aus Zertifikaten + Zielen)_
- Hat **ISO 27001 + ISO 9001**, Produkt = vernetzte Maschine → Ziel **CRA + MaschinenVO**.
- Gewählte Journey: **ISO 27001 → CRA + MaschinenVO** (Convergence-Pattern) + QM-Seite ISO 9001 → MaschinenVO.
- ⚠️ Die Übergänge stehen als DATEN in `knowledge/programs/transitions.yaml`, aber **keine Engine wählt sie aus Zertifikaten+Zielen** — hier manuell selektiert.

## 3. Capability Delta — was fehlt? _(Company 2A + RS-005)_
> 17 zu klären, 0 bereits abgedeckt, 5 vermutlich vorhanden, 12 fehlt, 0 n/a, 0 nicht im Korpus.
- Vermutlich vorhanden (aus ISMS, Welt 1): incident_management, technical_vulnerability_management, access_control_and_authentication, secure_development_lifecycle …
- Fehlt (Delta): 12 Capabilities, z. B. ce_conformity_assessment_and_technical_documentation, coordinated_vulnerability_disclosure, exploited_vuln_and_incident_reporting, machine_safety_risk_assessment …

## 4. Roadmap — was zuerst? _(Optimization, größter Hebel)_
> 16 identifizierte Anforderungen aus 2 Regelwerken -> 12 Massnahmen (Ø Hebel 1.3).
- **Top-Maßnahmen:** `ce_conformity_assessment_and_technical_documentation`(2), `product_cyber_risk_assessment`(2), `protection_against_corruption_of_safety_functions`(2), `secure_signed_update_distribution`(2), `coordinated_vulnerability_disclosure`(1)

## 5. Playbooks — wie umsetzen? _(Berater-Renderer)_
- 7 von 12 Maßnahmen haben ein Playbook; 5 brauchen Inhalt (Maschinensicherheits-Playbooks @IACE delegiert).

## 6. Nachweise — was belegen? _(expected_evidence)_
- Geforderte Nachweise (Auszug): advisory_process, config_export, cvd_policy, declaration_of_conformity, machine_risk_assessment, operating_instructions …

## 7. Verification — kann ich es BEWEISEN?
- ⚠️ **Nicht gebaut** — der Verification-Layer (Evidence × Reality → bewiesen) ist Vision V2 (geparkt, Task #45).

## 8. Completeness — wie sicher/vollständig? _(auditierbar)_
> Identifiziert 6 · bewertet 2 · offen 4 · Unsicherheiten 1 · Begründung ja
- Offen/begründet: `DataAct`(query_required), `EMV`(future_corpus), `NIS2`(future_corpus), `RED`(future_corpus)

## Die 6-Monats-Antwort (Beratungsnarrativ)

> „Sie sind als Maschinenbauer von **CRA + MaschinenVO** (und EMV) betroffen; RED/Data Act/NIS2 sind erst nach **einer Rückfrage** (`generates_usage_data`) zu klären. Ihr ISMS deckt die Informationssicherheits-Seite *wahrscheinlich* ab (zu bestätigen). Offen sind **12 Maßnahmen**. **Wenn Sie in den nächsten 6 Monaten die Top-5 nach regulatorischem Hebel umsetzen, schließen Sie 9 von 16 identifizierten Anforderungen (56%)** — beginnend mit den Maßnahmen, die CRA UND MaschinenVO gleichzeitig erfüllen. Für jede gibt es ein Umsetzungs-Playbook und die geforderten Nachweise; was wir noch NICHT bewerten konnten (EMV/RED/NIS2), weisen wir transparent aus."

## Flow-Continuity-Audit — der eigentliche Test

| Übergang | Status | Befund |
|---|---|---|
| Onboarding → Scope | ✅ sauber | Regulatory Map leitet aus dem Produktprofil CRA/MaschinenVO/EMV ab; RED/DataAct/NIS2 unsicher. |
| Scope → Journey | ⚠️ SPRUNG | Kein Selektor-Engine `certs × applicable-targets → journeys` — die Journey-Wahl ist Glue (Daten existieren in transitions.yaml). |
| Journey → Capability Delta | ✅ sauber | assess_transition(Company-Profil, Required) → Coverage + Delta; sauberer Engine-Handoff. |
| Zertifikate → Capabilities (Dependency) | 🔌 Dependency | cert→capability-Map ist Execution-owned + injiziert (hier gemockt) — bewusste Ownership-Grenze, kein Architektur-Bruch. |
| Capability Delta → Roadmap | ✅ sauber | roadmap_from_delta(assessment, covers_targets) → Maßnahmen nach Hebel; sauber. |
| Roadmap → Playbook | ✅ sauber | playbooks_for_plan(plan, knowledge) → Reise je Maßnahme; fehlender Inhalt = ehrliche `missing`-Stubs. |
| Playbook → Evidence | ✅ sauber | expected_evidence trägt aus Pattern/Playbook durch — Datenfeld, kein Bruch. |
| Evidence → Verification | ⚠️ SPRUNG | Verification-Layer fehlt (bewusst geparkt, Vision V2 / Requirements Verification Platform). |
| Completeness (Dependency) | 🔌 Dependency | corpus_status (welche Regelwerke validiert) wird kuratiert/injiziert, nicht aus dem Korpus abgeleitet. |

**5 sauber · 2 Sprünge · 2 bewusste Dependencies.**

**Befund:** Die Plattform trägt den **gesamten Beratungsfluss** end-to-end — von der Kundenfrage bis zur priorisierten 6-Monats-Maßnahmenliste mit Playbooks, Nachweisen und ehrlicher Vollständigkeit. **Genau ZWEI echte Sprünge:** (1) **Scope → Journey** — es fehlt ein Selektor-Engine `Zertifikate × Ziele → Journeys` (die Daten existieren, nur die Auswahl ist Glue); (2) **Evidence → Verification** — bewusst geparkter Layer (Vision V2). Die zwei Dependencies (cert→capability-Map @Execution, corpus_status-Kuratierung) sind gewollte Ownership-Grenzen, keine Architektur-Brüche. → **Wenn der Scope→Journey-Selektor steht, ist das Fundament im Wesentlichen fertig; ab dann ist die Arbeit Wissen, nicht Architektur.**