breakpilot-compliance/backend-compliance/reference_scenarios/customer_mission_1.md

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.