diff --git a/backend-compliance/knowledge/implementation_playbooks/playbook_ce_conformity_assessment_and_technical_documentation_v1.yaml b/backend-compliance/knowledge/implementation_playbooks/playbook_ce_conformity_assessment_and_technical_documentation_v1.yaml
new file mode 100644
index 00000000..86c9562c
--- /dev/null
+++ b/backend-compliance/knowledge/implementation_playbooks/playbook_ce_conformity_assessment_and_technical_documentation_v1.yaml
@@ -0,0 +1,66 @@
+# Implementation Playbook — curated KNOWLEDGE (the "wie komme ich dort hin?" layer), not runtime code.
+# Capability: ce_conformity_assessment_and_technical_documentation. Expert FIRST DRAFT (machinery-safety /
+# CE-conformity domain, IACE session). NOT a normative requirement. Renderer = compliance/playbook.
+
+id: PB-ce_conformity_assessment_and_technical_documentation-v1
+capability_id: ce_conformity_assessment_and_technical_documentation
+status: draft                      # draft -> reviewed -> validated -> proven
+version: 1
+
+title: "CE-Konformitätsbewertung und Technische Dokumentation für Maschinen"
+canonical_action: "Maschinenkonformität nachweisen"           # Verb+Objekt (capability-is-a-verb-Experiment)
+
+why: >
+  Vor dem Inverkehrbringen muss der Hersteller die Konformität der Maschine nachweisen: das passende
+  Konformitätsbewertungsverfahren durchführen (Maschinenverordnung Anhang XI), die Technische
+  Dokumentation zusammenstellen (Anhang IV), die EU-Konformitätserklärung ausstellen (Anhang V) und die
+  CE-Kennzeichnung anbringen. Dies ist der ABSCHLUSS-Schritt, der Risikobeurteilung, Schutzmaßnahmen und
+  Betriebsanleitung zu einem konformen, marktfähigen Produkt bündelt. Für die in Anhang I gelisteten
+  (Hochrisiko-)Maschinen kann die Einbindung einer notifizierten Stelle erforderlich sein. Bei vernetzten
+  Maschinen greift dies mit der CRA-Konformität (Cyber) ineinander — eine integrierte technische Akte.
+
+tools:
+  - "Maschinenverordnung (EU) 2023/1230 Anhang IV (Inhalt der Technischen Dokumentation)"
+  - "Anhang XI (Konformitätsbewertungsverfahren) + Anhang I (Liste der Hochrisiko-Maschinen)"
+  - "Anhang V (EU-Konformitätserklärung)"
+  - "Harmonisierte Normen (Fundstellen im Amtsblatt -> Vermutungswirkung)"
+  - "NANDO-Datenbank (Auswahl einer notifizierten Stelle, falls erforderlich)"
+
+process_steps:
+  - title: "Maschine klassifizieren"
+    detail: "Prüfen, ob die Maschine in Anhang I (Hochrisiko) fällt — das bestimmt, welche Verfahren nach Anhang XI zulässig sind."
+  - title: "Konformitätsverfahren wählen"
+    detail: "Nicht-Hochrisiko: interne Fertigungskontrolle (Anhang VIII). Hochrisiko/Anhang I: je nach Fall EU-Baumusterprüfung oder umfassende Qualitätssicherung unter Einbindung einer notifizierten Stelle."
+  - title: "Harmonisierte Normen anwenden"
+    detail: "Anwendbare harmonisierte Normen heranziehen und die Anwendung dokumentieren — das verschafft Vermutungswirkung für die abgedeckten Anforderungen."
+  - title: "Technische Dokumentation zusammenstellen (Anhang IV)"
+    detail: "Allgemeine Beschreibung, Konstruktions-/Fertigungsunterlagen, vollständige RISIKOBEURTEILUNG, Liste der angewandten Normen, Betriebsanleitung, Prüf-/Berechnungsberichte (z. B. PL-/SIL-Nachweis)."
+  - title: "EU-Konformitätserklärung ausstellen (Anhang V)"
+    detail: "Eindeutige Maschinenidentifikation, Verweis auf angewandte Rechtsakte (MaschinenVO; ggf. CRA, EMV, NSR) + Normen; rechtsverbindliche Unterschrift."
+  - title: "CE-Kennzeichnung anbringen"
+    detail: "Sichtbar/lesbar/dauerhaft an der Maschine; ggf. Kennnummer der notifizierten Stelle."
+  - title: "Aufbewahren"
+    detail: "Technische Dokumentation + Konformitätserklärung über die vorgeschriebene Frist (i. d. R. 10 Jahre) für die Marktüberwachung verfügbar halten."
+
+expected_evidence:
+  - "Vollständige Technische Dokumentation nach Anhang IV (inkl. Risikobeurteilung + Betriebsanleitung)"
+  - "EU-Konformitätserklärung nach Anhang V (datiert, unterschrieben)"
+  - "Nachweis der CE-Kennzeichnung an der Maschine"
+  - "Falls erforderlich: EU-Baumusterprüfbescheinigung / Bescheinigung der notifizierten Stelle"
+
+typical_controls:                  # INDIKATIV — echte Control-Zuordnung kommt aus der Execution-Schicht
+  - "conformity_assessment_procedure"
+  - "technical_file"
+  - "ce_marking_declaration"
+
+how_others_do_it: >
+  Verbreitete Praxis: für nicht in Anhang I gelistete Maschinen interne Fertigungskontrolle plus
+  konsequente Anwendung harmonisierter Normen (Vermutungswirkung); für Hochrisiko-Maschinen frühzeitige
+  Einbindung einer notifizierten Stelle. Die Technische Dokumentation wird als lebendes Dokument geführt,
+  das Risikobeurteilung, Betriebsanleitung und Prüfberichte bündelt; bei vernetzten Produkten wird die
+  CRA-Cyber-Konformität in dieselbe technische Akte integriert (eine Erklärung, mehrere Rechtsakte).
+
+disclaimer: >
+  Kuratiertes Experten-Wissen (Erstentwurf, Maschinensicherheit / CE-Konformität), KEINE normative
+  Anforderung. Werkzeug- und Schrittempfehlungen sind Beispiele bewährter Praxis, kein Pflichtkatalog.
+  Review durch eine:n CE-/Maschinensicherheits-Expert:in ausstehend (status: draft).
diff --git a/backend-compliance/knowledge/implementation_playbooks/playbook_machine_safety_risk_assessment_v1.yaml b/backend-compliance/knowledge/implementation_playbooks/playbook_machine_safety_risk_assessment_v1.yaml
new file mode 100644
index 00000000..eb6e7d4c
--- /dev/null
+++ b/backend-compliance/knowledge/implementation_playbooks/playbook_machine_safety_risk_assessment_v1.yaml
@@ -0,0 +1,64 @@
+# Implementation Playbook — curated KNOWLEDGE (the "wie komme ich dort hin?" layer), not runtime code.
+# Capability: machine_safety_risk_assessment. Expert FIRST DRAFT (machinery-safety domain, IACE session)
+# — a machine-safety engineer would validate this; it is NOT a normative requirement. The renderer
+# (compliance/playbook) assembles it into the journey.
+
+id: PB-machine_safety_risk_assessment-v1
+capability_id: machine_safety_risk_assessment
+status: draft                      # draft -> reviewed -> validated -> proven
+version: 1
+
+title: "Maschinen-Risikobeurteilung nach ISO 12100 durchführen"
+canonical_action: "Maschinenrisiken systematisch beurteilen"   # Verb+Objekt (capability-is-a-verb-Experiment)
+
+why: >
+  Die Maschinenverordnung (EU) 2023/1230 verlangt vor dem Inverkehrbringen eine Risikobeurteilung über
+  den GESAMTEN Lebenszyklus der Maschine (Transport, Montage, Inbetriebnahme, bestimmungsgemäßer Betrieb,
+  Reinigung, Wartung, Störungsbeseitigung, Demontage, Entsorgung). Sie ist die Grundlage, aus der sich
+  ALLE weiteren Schutzmaßnahmen und die Technische Dokumentation (Anhang IV) ableiten. ISO 12100 ist die
+  harmonisierte Methodik und verschafft Vermutungswirkung. Ohne dokumentierte Risikobeurteilung ist die
+  Auswahl von Schutzeinrichtungen, Not-Halt und Restrisiko-Hinweisen nicht begründbar.
+
+tools:
+  - "ISO 12100 (Risikobeurteilung + Risikominderung, Grundnorm)"
+  - "ISO/TR 14121-2 (praktische Beispiele für die Methodik)"
+  - "Gefährdungslisten ISO 12100 Anhang B (mechanisch, elektrisch, thermisch, Lärm, Vibration, Strahlung, Werkstoff, Ergonomie)"
+  - "Sistema (DGUV, PLr-/PL-Ermittlung für Schutzfunktionen)"
+  - "Risikograph-/Risikomatrix-Vorlagen (S x F x P bzw. S x E)"
+
+process_steps:
+  - title: "Grenzen der Maschine festlegen"
+    detail: "Verwendungs-, räumliche, zeitliche und Lebenszyklusgrenzen; bestimmungsgemäße Verwendung UND vernünftigerweise vorhersehbare Fehlanwendung."
+  - title: "Gefährdungen identifizieren"
+    detail: "Systematisch je Lebensphase und je Bereich anhand der ISO-12100-Anhang-B-Liste — nichts überspringen (gerade Wartung/Reinigung wird oft vergessen)."
+  - title: "Risiko einschätzen"
+    detail: "Je Gefährdung Schadensschwere x Eintrittswahrscheinlichkeit (Häufigkeit/Aufenthaltsdauer, Möglichkeit zur Vermeidung) bestimmen."
+  - title: "Risiko bewerten"
+    detail: "Entscheiden, ob Risikominderung erforderlich ist (akzeptables Restrisiko erreicht?)."
+  - title: "3-Stufen-Methode anwenden (in dieser Reihenfolge)"
+    detail: "1. inhärent sichere Konstruktion -> 2. technische Schutzmaßnahmen/ergänzende Schutzeinrichtungen -> 3. Benutzerinformation. Maßnahmen NICHT in Stufe 3 verlagern, was in Stufe 1/2 lösbar ist."
+  - title: "Iterieren"
+    detail: "Nach jeder Maßnahme Risiko neu bewerten; prüfen, ob neue Gefährdungen entstanden sind (z. B. eine Schutzhaube erzeugt eine Quetschstelle)."
+  - title: "Restrisiko dokumentieren"
+    detail: "Verbleibende Restrisiken festhalten und an die Betriebsanleitung übergeben (Schnittstelle zu operating_instructions_and_safety_information)."
+
+expected_evidence:
+  - "Risikobeurteilungsbericht über alle Lebensphasen (datiert, versioniert)"
+  - "Gefährdungsliste mit Risikoeinschätzung je Gefährdung"
+  - "Zuordnung Gefährdung -> gewählte Maßnahme -> verbleibendes Restrisiko"
+  - "Liste der Restrisiken (Eingang in die Betriebsanleitung)"
+
+typical_controls:                  # INDIKATIV — echte Control-Zuordnung kommt aus der Execution-Schicht
+  - "machine_risk_assessment_record"
+  - "three_step_risk_reduction"
+
+how_others_do_it: >
+  Verbreitete Praxis: Risikobeurteilung strikt nach ISO 12100 strukturieren, mit ISO/TR 14121-2 als
+  Beispiel-Steinbruch, und die ermittelten Schutzfunktionen über Sistema auf den erforderlichen
+  Performance Level (PLr) rechnen. Der Bericht wird unmittelbar Teil der Technischen Dokumentation
+  (Anhang IV) und wird bei jeder wesentlichen Veränderung der Maschine erneut gefahren.
+
+disclaimer: >
+  Kuratiertes Experten-Wissen (Erstentwurf, Maschinensicherheit), KEINE normative Anforderung. Werkzeug-
+  und Schrittempfehlungen sind Beispiele bewährter Praxis, kein Pflichtkatalog. Review durch eine:n
+  Maschinensicherheits-Expert:in ausstehend (status: draft).
diff --git a/backend-compliance/knowledge/implementation_playbooks/playbook_mechanical_safety_and_guards_v1.yaml b/backend-compliance/knowledge/implementation_playbooks/playbook_mechanical_safety_and_guards_v1.yaml
new file mode 100644
index 00000000..1df142af
--- /dev/null
+++ b/backend-compliance/knowledge/implementation_playbooks/playbook_mechanical_safety_and_guards_v1.yaml
@@ -0,0 +1,69 @@
+# Implementation Playbook — curated KNOWLEDGE (the "wie komme ich dort hin?" layer), not runtime code.
+# Capability: mechanical_safety_and_guards. Expert FIRST DRAFT (machinery-safety domain, IACE session).
+# NOT a normative requirement. Renderer = compliance/playbook.
+
+id: PB-mechanical_safety_and_guards-v1
+capability_id: mechanical_safety_and_guards
+status: draft                      # draft -> reviewed -> validated -> proven
+version: 1
+
+title: "Schutzeinrichtungen, Not-Halt und sichere Steuerung auslegen"
+canonical_action: "Gefahrstellen wirksam absichern"            # Verb+Objekt (capability-is-a-verb-Experiment)
+
+why: >
+  Die grundlegenden Sicherheits- und Gesundheitsschutzanforderungen der Maschinenverordnung (Anhang III)
+  verlangen Schutz vor mechanischen Gefährdungen (Quetschen, Scheren, Schneiden, Einziehen, Stoß),
+  funktionssichere Not-Halt-Einrichtungen, Schutz gegen unerwarteten Anlauf und Standsicherheit. Aus der
+  Risikobeurteilung (machine_safety_risk_assessment) ergibt sich, WO und mit WELCHER Zuverlässigkeit
+  (Performance Level / SIL) abgesichert werden muss. Trennende und nichttrennende Schutzeinrichtungen
+  setzen die zweite Stufe der 3-Stufen-Methode um.
+
+tools:
+  - "ISO 14120 (trennende Schutzeinrichtungen — Gestaltung)"
+  - "ISO 14119 (Verriegelungseinrichtungen mit/ohne Zuhaltung)"
+  - "ISO 13850 (Not-Halt-Funktion, Stopp-Kategorie 0/1)"
+  - "ISO 13857 (Sicherheitsabstände gegen Erreichen von Gefahrstellen)"
+  - "ISO 13849-1/-2 (sicherheitsbezogene Steuerungsteile, PL + Validierung)"
+  - "IEC 62061 (funktionale Sicherheit von Steuerungen, SIL)"
+  - "ISO 14118 (Vermeidung von unerwartetem Anlauf / LOTO)"
+
+process_steps:
+  - title: "Gefahrstellen übernehmen"
+    detail: "Aus der Risikobeurteilung die mechanischen Gefahrstellen + erforderlichen PLr/SIL je Schutzfunktion übernehmen."
+  - title: "Schutzeinrichtung wählen"
+    detail: "Feststehend trennend, wo im Betrieb kein Zugang nötig ist; beweglich trennend, wo regelmäßiger Zugang erforderlich ist; ergänzend nichttrennend (z. B. Lichtgitter), wo Materialfluss offen bleibt."
+  - title: "Bewegliche Schutzeinrichtungen verriegeln"
+    detail: "Nach ISO 14119 Verriegelung (mit Zuhaltung, wenn Nachlauf gefährlich ist); manipulationsarme Auslegung beachten."
+  - title: "Sicherheitsabstände einhalten"
+    detail: "Nach ISO 13857 Reichweiten nach oben/über/um Schutzeinrichtungen sicherstellen."
+  - title: "Not-Halt vorsehen"
+    detail: "ISO 13850: gut erreichbare Not-Halt-Befehlsgeräte, Stopp-Kategorie 0 oder 1, Rückstellung nur bewusst; Not-Halt ist ERGÄNZEND, ersetzt keine trennende Schutzeinrichtung."
+  - title: "Sichere Steuerung auslegen"
+    detail: "Sicherheitsbezogene Steuerungsteile auf den erforderlichen PL (ISO 13849-1) bzw. SIL (IEC 62061) bringen; Architektur, MTTFd, DC, CCF nachweisen (Sistema)."
+  - title: "Unerwarteten Anlauf verhindern"
+    detail: "ISO 14118 / sichere Energietrennung (LOTO) für Wartung und Störungsbeseitigung (Schnittstelle zur Wartungs-Lebensphase)."
+  - title: "Validieren"
+    detail: "Schutzfunktionen nach ISO 13849-2 verifizieren/validieren (Funktionstest + Nachweis)."
+
+expected_evidence:
+  - "Schutzkonzept (welche Gefahrstelle -> welche Schutzeinrichtung)"
+  - "PL-/SIL-Nachweis je Schutzfunktion (z. B. Sistema-Report)"
+  - "Funktionstest-Protokoll Not-Halt + Verriegelungen"
+  - "Validierungsbericht der Schutzeinrichtungen (ISO 13849-2)"
+
+typical_controls:                  # INDIKATIV — echte Control-Zuordnung kommt aus der Execution-Schicht
+  - "guard_design"
+  - "interlock_function"
+  - "emergency_stop_function"
+  - "safe_control_system"
+
+how_others_do_it: >
+  Verbreitete Praxis: feststehende Verkleidungen überall dort, wo kein betrieblicher Zugang nötig ist;
+  verriegelte bewegliche Schutztüren mit Zuhaltung an Stellen mit Nachlauf; der erforderliche Performance
+  Level wird per Risikograph bestimmt und mit Sistema nachgewiesen. Not-Halt wird als ergänzende, nicht
+  als primäre Maßnahme eingeplant. Validierung erfolgt dokumentiert vor der Konformitätserklärung.
+
+disclaimer: >
+  Kuratiertes Experten-Wissen (Erstentwurf, Maschinensicherheit), KEINE normative Anforderung.
+  Werkzeug- und Schrittempfehlungen sind Beispiele bewährter Praxis, kein Pflichtkatalog. Review durch
+  eine:n Maschinensicherheits-Expert:in ausstehend (status: draft).
diff --git a/backend-compliance/knowledge/implementation_playbooks/playbook_operating_instructions_and_safety_information_v1.yaml b/backend-compliance/knowledge/implementation_playbooks/playbook_operating_instructions_and_safety_information_v1.yaml
new file mode 100644
index 00000000..f823c566
--- /dev/null
+++ b/backend-compliance/knowledge/implementation_playbooks/playbook_operating_instructions_and_safety_information_v1.yaml
@@ -0,0 +1,63 @@
+# Implementation Playbook — curated KNOWLEDGE (the "wie komme ich dort hin?" layer), not runtime code.
+# Capability: operating_instructions_and_safety_information. Expert FIRST DRAFT (machinery-safety domain,
+# IACE session). NOT a normative requirement. Renderer = compliance/playbook.
+
+id: PB-operating_instructions_and_safety_information-v1
+capability_id: operating_instructions_and_safety_information
+status: draft                      # draft -> reviewed -> validated -> proven
+version: 1
+
+title: "Betriebsanleitung und Sicherheitsinformationen erstellen"
+canonical_action: "Sicherheitsinformationen bereitstellen"     # Verb+Objekt (capability-is-a-verb-Experiment)
+
+why: >
+  Information für die Benutzung ist die DRITTE Stufe der 3-Stufen-Methode (ISO 12100 6.4): Sie trägt das
+  Restrisiko, das durch Konstruktion und technische Schutzmaßnahmen nicht beseitigt werden konnte. Die
+  Maschinenverordnung (Anhang III 1.7) verlangt eine Betriebsanleitung in der/den Sprache(n) des
+  Verwenderlandes; die Verordnung erlaubt nun unter Bedingungen auch die digitale Bereitstellung. Eine
+  vollständige, verständliche Anleitung ist Voraussetzung für die Konformität — fehlende oder
+  unverständliche Sicherheitsinformationen sind ein häufiger Mangel bei der Marktüberwachung.
+
+tools:
+  - "ISO 12100 6.4 (Information für die Benutzung)"
+  - "ISO 20607 (Betriebsanleitung — allgemeine Gestaltungsgrundsätze für Maschinensicherheit)"
+  - "IEC/IEEE 82079-1 (Erstellung von Nutzungsinformationen)"
+  - "ANSI Z535.6 / ISO 3864 (Sicherheits- und Warnhinweise, Signalwörter)"
+  - "Structured-Authoring-Werkzeuge (z. B. DITA) für Mehrsprachigkeit/Versionierung"
+
+process_steps:
+  - title: "Restrisiken übernehmen"
+    detail: "Die Restrisikoliste aus der Risikobeurteilung (machine_safety_risk_assessment) ist der verbindliche Eingang — jedes Restrisiko braucht eine Information/Warnung."
+  - title: "Zielgruppen und Lebensphasen abdecken"
+    detail: "Transport, Montage, Inbetriebnahme, Bedienung, Reinigung, Wartung, Störungsbeseitigung, Demontage/Entsorgung — je mit benötigter Qualifikation."
+  - title: "Warnhinweise strukturieren"
+    detail: "Einheitlich Signalwort (Gefahr/Warnung/Vorsicht) + Art der Gefahr + Folge + Vermeidung (ANSI Z535/ISO 3864)."
+  - title: "Verwendung abgrenzen"
+    detail: "Bestimmungsgemäße Verwendung UND vernünftigerweise vorhersehbare Fehlanwendung beschreiben."
+  - title: "Sprache sicherstellen"
+    detail: "In der/den Amtssprache(n) des Verwenderlandes; Übersetzungen als Übersetzung kennzeichnen."
+  - title: "Format und Bereitstellung festlegen"
+    detail: "Papier oder — nach den Bedingungen der Maschinenverordnung — digital; Sicherheitsinformationen müssen auffindbar und über die Lebensdauer verfügbar bleiben; auf Verlangen Papierfassung."
+  - title: "Versionieren"
+    detail: "Anleitung an Maschinenversion koppeln; bei wesentlicher Veränderung aktualisieren."
+
+expected_evidence:
+  - "Betriebsanleitung je Maschine und Sprache (datiert, versioniert)"
+  - "Warnhinweis-Konzept (Signalwörter, Piktogramme)"
+  - "Matrix Restrisiko -> zugehörige Information/Warnung (Rückverfolgbarkeit zur Risikobeurteilung)"
+  - "Nachweis der Bereitstellungsform (digital + Papier-auf-Verlangen)"
+
+typical_controls:                  # INDIKATIV — echte Control-Zuordnung kommt aus der Execution-Schicht
+  - "safety_information_provision"
+  - "residual_risk_communication"
+
+how_others_do_it: >
+  Verbreitete Praxis: strukturierte Redaktion nach IEC/IEEE 82079-1 und ISO 20607, Warnhinweise nach
+  ANSI Z535/ISO 3864, und eine durchgängige Verknüpfung jedes Restrisikos aus der Risikobeurteilung mit
+  einer konkreten Information. Digitale Anleitungen werden über stabile URLs/QR bereitgestellt, mit
+  Papierfassung auf Verlangen, und mit der ausgelieferten Maschinenversion verknüpft.
+
+disclaimer: >
+  Kuratiertes Experten-Wissen (Erstentwurf, Maschinensicherheit), KEINE normative Anforderung.
+  Werkzeug- und Schrittempfehlungen sind Beispiele bewährter Praxis, kein Pflichtkatalog. Review durch
+  eine:n Technische-Redaktion-/Maschinensicherheits-Expert:in ausstehend (status: draft).
diff --git a/backend-compliance/knowledge/implementation_playbooks/playbook_protection_against_corruption_of_safety_functions_v1.yaml b/backend-compliance/knowledge/implementation_playbooks/playbook_protection_against_corruption_of_safety_functions_v1.yaml
new file mode 100644
index 00000000..4f914a0d
--- /dev/null
+++ b/backend-compliance/knowledge/implementation_playbooks/playbook_protection_against_corruption_of_safety_functions_v1.yaml
@@ -0,0 +1,71 @@
+# Implementation Playbook — curated KNOWLEDGE (the "wie komme ich dort hin?" layer), not runtime code.
+# Capability: protection_against_corruption_of_safety_functions. Expert FIRST DRAFT (machinery-safety +
+# cyber-safety bridge, IACE session). NOT a normative requirement. Renderer = compliance/playbook.
+#
+# CONVERGENCE NOTE: this capability is the CRA <-> MaschinenVO bridge. The same integrity + access
+# controls that satisfy the CRA (software integrity, signed updates, access control) also satisfy
+# Machinery Regulation Annex III 1.1.9. The renderer supplies closes_regulations/leverage from
+# covers_targets — one playbook, two regulations.
+
+id: PB-protection_against_corruption_of_safety_functions-v1
+capability_id: protection_against_corruption_of_safety_functions
+status: draft                      # draft -> reviewed -> validated -> proven
+version: 1
+
+title: "Sicherheitsfunktionen gegen (Software-)Korruption und Manipulation schützen"
+canonical_action: "Sicherheitsfunktionen gegen Manipulation schützen"   # Verb+Objekt (capability-is-a-verb)
+
+why: >
+  Maschinenverordnung Anhang III 1.1.9 verlangt, dass Hard- und Software sowie Daten, die für die
+  Sicherheit kritisch sind, gegen ZUFÄLLIGE und BEABSICHTIGTE Korruption geschützt werden. Eine
+  manipulierte oder fehlerhaft veränderte Sicherheitsfunktion (z. B. überbrückte Verriegelung,
+  verstellter Sicherheitsparameter, untergeschobenes Steuerungs-Update) wird unmittelbar zu einer
+  physischen Sicherheitsgefährdung. Genau hier treffen sich Maschinensicherheit und Cybersecurity:
+  dieselben Integritäts- und Zugriffsmaßnahmen, die der Cyber Resilience Act fordert, erfüllen auch
+  diese Maschinenpflicht (Konvergenz / Cyber-Safety-Brücke).
+
+tools:
+  - "IEC 62443 (industrielle Kommunikationsnetze / IACS-Security)"
+  - "IEC 61508 / ISO 13849 / IEC 62061 (funktionale Sicherheit der Steuerung)"
+  - "Code- und Update-Signierung (Secure Boot, signierte Firmware)"
+  - "Hardware-Vertrauensanker (TPM/Secure Element) für Integritätsprüfung"
+  - "Rollen-/Zugriffskonzept für sicherheitsrelevante Parameter (keine Default-Passwörter)"
+
+process_steps:
+  - title: "Sicherheitskritische Elemente identifizieren"
+    detail: "Welche Soft-/Hardware und welche Parameter/Daten tragen eine Sicherheitsfunktion? (Eingang aus der Risikobeurteilung + sicherer Steuerung.)"
+  - title: "Integrität schützen"
+    detail: "Signierte Firmware/Updates, Prüfsummen, sichere Bootkette; Veränderung sicherheitsrelevanten Codes nur mit verifizierter Signatur."
+  - title: "Zugriff kontrollieren"
+    detail: "Authentisierung für das Verstellen von Sicherheitsparametern; Rollentrennung; keine ab Werk gesetzten Standardpasswörter (secure-by-default)."
+  - title: "Safety und Standardsteuerung trennen"
+    detail: "Sicherheitsbezogene Steuerungsteile von der allgemeinen Steuerung entkoppeln, damit eine Kompromittierung der Standardseite die Safety-Funktion nicht aushebelt."
+  - title: "Manipulation erkennen -> sicherer Zustand"
+    detail: "Bei erkannter Integritätsverletzung definiert in den sicheren Zustand übergehen (fail-safe), nicht still weiterlaufen."
+  - title: "Updates sicher verteilen"
+    detail: "Sicherheitsrelevante Updates nur signiert und verifiziert einspielen (Schnittstelle zu sicheren Update-Capabilities des CRA)."
+  - title: "Sicherheitsrelevante Eingriffe protokollieren"
+    detail: "Änderungen an Sicherheitsparametern/-software nachvollziehbar loggen (Audit-Trail)."
+
+expected_evidence:
+  - "Konzept Integritätsschutz sicherheitskritischer Soft-/Hardware"
+  - "Nachweis Code-/Update-Signierung (Schlüsselverwaltung, Verifikation)"
+  - "Zugriffskontroll-/Rollenkonzept für Sicherheitsparameter"
+  - "Testprotokoll: Manipulationsversuch -> definierter sicherer Zustand"
+
+typical_controls:                  # INDIKATIV — echte Control-Zuordnung kommt aus der Execution-Schicht
+  - "safety_function_integrity"
+  - "secure_update_distribution"
+  - "access_control_safety_parameters"
+
+how_others_do_it: >
+  Verbreitete Praxis: die CRA-Maßnahmen (signierte Updates, Secure Boot, Integritätsprüfung,
+  Zugriffskontrolle ohne Default-Passwörter) werden EINMAL umgesetzt und decken zugleich
+  Maschinenverordnung Anhang III 1.1.9 ab — eine Maßnahme, zwei Regelwerke. Die Sicherheitssteuerung
+  wird nach IEC 62443 segmentiert, und bei Integritätsverletzung geht die Maschine kontrolliert in den
+  sicheren Zustand statt weiterzulaufen.
+
+disclaimer: >
+  Kuratiertes Experten-Wissen (Erstentwurf, Maschinensicherheit + Cyber-Safety), KEINE normative
+  Anforderung. Werkzeug- und Schrittempfehlungen sind Beispiele bewährter Praxis, kein Pflichtkatalog.
+  Review durch Product-Security- + Funktionale-Sicherheit-Expert:innen ausstehend (status: draft).
diff --git a/backend-compliance/reference_scenarios/customer_mission_1.md b/backend-compliance/reference_scenarios/customer_mission_1.md
index 88e62d42..99c1bbd8 100644
--- a/backend-compliance/reference_scenarios/customer_mission_1.md
+++ b/backend-compliance/reference_scenarios/customer_mission_1.md
@@ -26,7 +26,7 @@ _KEINE Demo, KEIN Reference Scenario — eine vollständige Simulation eines Ber
 - **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)_
-- 2 von 12 Maßnahmen haben ein Playbook; 10 brauchen Inhalt (Maschinensicherheits-Playbooks @IACE delegiert).
+- 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 …
diff --git a/backend-compliance/reference_scenarios/customer_mission_2.md b/backend-compliance/reference_scenarios/customer_mission_2.md
new file mode 100644
index 00000000..cb46eb22
--- /dev/null
+++ b/backend-compliance/reference_scenarios/customer_mission_2.md
@@ -0,0 +1,60 @@
+# Customer Mission #2 — „Wir haben SCHON viel. Was fehlt UNS noch für die CRA?"
+
+_Zweite Mission, bewusst ANDERS als #1: nicht „ein Zertifikat → ein Ziel", sondern ein hoch-zertifiziertes Unternehmen, das mit einem ganzen Profil ankommt. Test der einzigen offenen Naht aus Mission #1 (Scope → Journey). Synthetischer Kunde, keine echten Namen._
+
+## Der Kunde (synthetisch, hoch-zertifiziert)
+> **ISO 9001** · **ISO 27001** · **ISO 14001** · **TISAX** · **CE-Prozess** · **PSIRT** · vernetzte Maschinen · Export EU
+> **Eine Frage:** „Wir sind schon in vielem zertifiziert — was genau fehlt UNS noch, um CRA-konform zu sein?"
+
+## 0. Company Capability Profile — der eigentliche Startzustand
+> Das Unternehmen bringt **kein Zertifikat als Startpunkt**, sondern ein **Profil**. Jedes Zertifikat ist eine *Beobachtung*, die wahrscheinliche Fähigkeiten beisteuert; der Startzustand ist ihre **Aggregation**.
+
+| Zertifikat (Beobachtung) | steuert Fähigkeiten bei | Vertrauen |
+|---|---|---|
+| **ISO27001** — Informationssicherheit (ISMS) | `incident_management`, `technical_vulnerability_management`, `access_control_and_authentication`, `secure_development_lifecycle`, `security_logging_and_monitoring` | medium |
+| **TISAX** — Automotive-ISMS — verstärkt dieselben Infosec-Fähigkeiten | `incident_management`, `technical_vulnerability_management`, `access_control_and_authentication`, `secure_development_lifecycle`, `security_logging_and_monitoring` | medium |
+| **PSIRT** — Product-Security-Incident-Response — deckt ZWEI CRA-Delta-Fähigkeiten | `coordinated_vulnerability_disclosure`, `exploited_vuln_and_incident_reporting` | high |
+| **ISO9001** — QM-Dokumentendisziplin → CE-/Technische-Doku-Fähigkeit | `ce_conformity_assessment_and_technical_documentation` | medium |
+| **ISO14001** — Umweltmanagement — im Profil, aber für die CRA NICHT relevant | `environmental_management_documentation` | medium |
+
+→ **Evidence ist zielrelativ:** ISO 14001 liegt im Profil, hilft der CRA aber **nicht**; PSIRT (oft übersehen) deckt **zwei** CRA-kritische Delta-Fähigkeiten. Genau deshalb darf man **nicht ein Zertifikat** zur Journey machen — das ganze Profil zählt.
+
+## 1. Ziel _(Intent)_ — was wollen Sie erreichen?
+- Intent: **„CRA-konform werden"** → Ziel-Profil = **CRA** (die von der CRA geforderten Fähigkeiten).
+- Auswahl-Eingabe ist damit **(Company Profile, Ziel)** — **kein** Zertifikat, das auf eine Journey gemappt wird.
+
+## 2. Capability Delta — Profil → CRA _(das IST die „Journey")_
+> 17 zu klären, 0 bereits abgedeckt, 8 vermutlich vorhanden, 9 fehlt, 0 n/a, 0 nicht im Korpus.
+- **Delta dieses Profils:** 9 fehlende Fähigkeiten.
+- **Gegenprobe (nur ISO 27001):** 12 fehlende Fähigkeiten.
+- **Mehr Evidence → kleineres Delta:** die zusätzliche Zertifizierung schließt **3** Fähigkeiten *vorab*: `ce_conformity_assessment_and_technical_documentation`, `coordinated_vulnerability_disclosure`, `exploited_vuln_and_incident_reporting`.
+
+→ Es wurde **keine Journey ausgewählt**. Das Delta `(Profil, Ziel)` IST die Journey — berechnet, nicht gewählt. Die Journey ist nur die *Erklärung* dieses Deltas.
+
+## 3. Roadmap — was zuerst? _(gleicher Hebel-Engine wie Mission #1)_
+> 12 identifizierte Anforderungen aus 2 Regelwerken -> 9 Massnahmen (Ø Hebel 1.3).
+- Top-5 nach Hebel schließen **8 von 12** offenen Anforderungen (67%).
+
+## Selektions-Rationale — die 5 Fragen (pro Mission zu dokumentieren)
+
+**Welche Journey wurde gewählt?**  
+**Keine per-Zertifikat-Journey.** Die Journey ist `Company Capability Profile → CRA`. Gewählt wurde nur das **Ziel** (CRA); der Startzustand wurde aus ALLEN Zertifikaten aggregiert.
+
+**Warum?**  
+Bei 6 Zertifikaten würde „ISO 27001 → CRA" die Evidence aus PSIRT/ISO 9001 wegwerfen (= 3 Fähigkeiten, die sonst fälschlich als Delta erschienen). Nur das **ganze Profil** ergibt das korrekte Delta.
+
+**Welche Informationen waren für die Auswahl entscheidend?**  
+(a) das **Ziel/Intent** (CRA) und (b) die **vollständige Zertifikatsliste** als Profil — **nicht** ein einzelnes Zertifikat. Welche Evidence hilft, ist **zielrelativ** (ISO 14001 irrelevant, PSIRT hoch-relevant).
+
+**Musste das Journey-Modell erweitert werden?**  
+**Konzeptionell ja, strukturell nein.** `from → to` bleibt; aber `from` ist ein **Company Capability Profile** (Multi-Cert-Aggregat), kein Zertifikat. Die Engines (`build_company_profile` + `assess_transition`) tun das BEREITS — es war ein Benenn-/Framing-Fehler, kein fehlender Code.
+
+**Musste ein neuer Selektionsparameter eingeführt werden?**  
+**Ja — und er VEREINFACHT.** Eingabe ist `(Company Profile, Ziel)`, nicht `(Zertifikat, Ziel)`. Die Zertifikate kollabieren ins Profil → **keine 2^N Cert-Kombinationen**, nur Profil→Ziel. Der Selektor wird damit kleiner, nicht größer.
+
+## Was Mission #2 an Mission #1 verändert
+
+- Mission #1 nannte **Scope → Journey** einen Sprung („kein Selektor `certs × targets → journeys`"). Mission #2 zeigt: **diese Naht schrumpft.** Es gibt keinen Journey-Matcher zu bauen — die Journey ist das **berechnete Delta** `(Profil, Ziel)`. Was real fehlt, ist nur **Profil-Intake + Ziel-Wahl**, nicht eine Journey-Auswahl-Engine.
+- Bestätigt den Reframe: **Es gibt keine „ISO 27001 → CRA"-Transition — nur „Company Capability Profile → CRA".** Zertifikate sind **Beobachtungen/Evidence**, kein Journey-Startpunkt.
+- **Beobachtung für den (noch nicht gebauten) Selektor:** Eingabe = `(Company Profile, Ziel)`. Diversität über weitere Missionen muss zeigen, ob auch **Produktprofil** und **Intent-Klasse** als Parameter nötig werden — erst dann kanonisieren ([[rule-of-three-canonicalization]]).
+
diff --git a/backend-compliance/reference_scenarios/mission_multicert_cra.py b/backend-compliance/reference_scenarios/mission_multicert_cra.py
new file mode 100644
index 00000000..1c33f425
--- /dev/null
+++ b/backend-compliance/reference_scenarios/mission_multicert_cra.py
@@ -0,0 +1,157 @@
+# ruff: noqa
+# mypy: ignore-errors
+"""Customer Mission #2 — the company arrives with a PROFILE, not a journey.
+
+Mission #1 (Maschinenbauer) ended on one open seam: „Scope → Journey" — a consultant had to hand-pick
+„ISO 27001 → CRA". This mission deliberately STRESSES that seam with a multi-certified company (the
+ETO-archetype: many certs at once) and asks the reframe question: is the start a *certification* you map
+to a journey, or a *Company Capability Profile* you compute a delta from?
+
+Finding (proven below with the real engines): there is NO per-certificate journey. The start is the whole
+profile; certifications are OBSERVATIONS that feed it; more evidence = smaller delta (12 → 9). The
+„journey" is not selected — it is the delta `(Company Profile, Target)`. That shrinks Mission #1's jump:
+the seam is not a journey-matcher, it is profile-intake + target-pick.
+
+Synthetic multi-certified company (NO real names). Runs the REAL engines end-to-end.
+Run:  cd backend-compliance && PYTHONPATH=. python3 reference_scenarios/mission_multicert_cra.py
+Not product code; not imported by the app. Non-runtime -> no deploy.
+"""
+from __future__ import annotations
+
+import os
+import yaml
+
+from compliance.company import (
+    CompanyContext, Certification, CapabilityMappingEntry, build_company_profile,
+)
+from compliance.reasoning.enums import Confidence
+from compliance.transition_reasoning import (
+    TransitionContext, TransitionGoal, TargetRequirement, assess_transition, CoverageStatus,
+)
+from compliance.optimization import roadmap_from_delta, select_within_budget
+
+OUT = []
+RAT = []  # (question, answer) — the per-mission selection rationale the user asked to record
+
+
+def w(s=""):
+    OUT.append(s)
+
+
+def rationale(question, answer):
+    RAT.append((question, answer))
+
+
+_HERE = os.path.dirname(__file__)
+_K = os.path.join(_HERE, "..", "knowledge")
+CP = yaml.safe_load(open(os.path.join(_K, "transition_patterns",
+                   "transition_pattern_iso27001_to_cra_maschinenvo_v1.yaml"), encoding="utf-8"))
+
+w('# Customer Mission #2 — „Wir haben SCHON viel. Was fehlt UNS noch für die CRA?"')
+w("")
+w('_Zweite Mission, bewusst ANDERS als #1: nicht „ein Zertifikat → ein Ziel", sondern ein hoch-zertifiziertes Unternehmen, das mit einem ganzen Profil ankommt. Test der einzigen offenen Naht aus Mission #1 (Scope → Journey). Synthetischer Kunde, keine echten Namen._')
+w("")
+w("## Der Kunde (synthetisch, hoch-zertifiziert)")
+w("> **ISO 9001** · **ISO 27001** · **ISO 14001** · **TISAX** · **CE-Prozess** · **PSIRT** · vernetzte Maschinen · Export EU")
+w('> **Eine Frage:** „Wir sind schon in vielem zertifiziert — was genau fehlt UNS noch, um CRA-konform zu sein?"')
+w("")
+
+# ── 0. Company Capability Profile — DER Startzustand (nicht ein Zertifikat) ──
+# Each certification is an OBSERVATION yielding probable capabilities. The profile is their AGGREGATE.
+# Evidence is TARGET-RELATIVE: ISO 14001 is in the profile but irrelevant to the CRA (honest).
+infosec = [a["capability"] for a in CP["likely_covered"]]
+CERT_OBS = {
+    "ISO27001": (infosec, Confidence.MEDIUM, "Informationssicherheit (ISMS)"),
+    "TISAX":    (infosec, Confidence.MEDIUM, "Automotive-ISMS — verstärkt dieselben Infosec-Fähigkeiten"),
+    "PSIRT":    (["coordinated_vulnerability_disclosure", "exploited_vuln_and_incident_reporting"],
+                 Confidence.HIGH, "Product-Security-Incident-Response — deckt ZWEI CRA-Delta-Fähigkeiten"),
+    "ISO9001":  (["ce_conformity_assessment_and_technical_documentation"],
+                 Confidence.MEDIUM, "QM-Dokumentendisziplin → CE-/Technische-Doku-Fähigkeit"),
+    "ISO14001": (["environmental_management_documentation"],
+                 Confidence.MEDIUM, "Umweltmanagement — im Profil, aber für die CRA NICHT relevant"),
+}
+cmap = {k: CapabilityMappingEntry(capability_ids=v[0], confidence=v[1]) for k, v in CERT_OBS.items()}
+ctx = CompanyContext(company_id="mc", certifications=[Certification(certification_id=k) for k in CERT_OBS])
+profile = build_company_profile(ctx, cmap)
+w("## 0. Company Capability Profile — der eigentliche Startzustand")
+w("> Das Unternehmen bringt **kein Zertifikat als Startpunkt**, sondern ein **Profil**. Jedes Zertifikat ist eine *Beobachtung*, die wahrscheinliche Fähigkeiten beisteuert; der Startzustand ist ihre **Aggregation**.")
+w("")
+w("| Zertifikat (Beobachtung) | steuert Fähigkeiten bei | Vertrauen |")
+w("|---|---|---|")
+for k, (caps, conf, note) in CERT_OBS.items():
+    w("| **%s** — %s | %s | %s |" % (k, note, ", ".join("`%s`" % c for c in caps), conf.value))
+w("")
+w("→ **Evidence ist zielrelativ:** ISO 14001 liegt im Profil, hilft der CRA aber **nicht**; PSIRT (oft übersehen) deckt **zwei** CRA-kritische Delta-Fähigkeiten. Genau deshalb darf man **nicht ein Zertifikat** zur Journey machen — das ganze Profil zählt.")
+w("")
+
+# ── 1. Ziel (Intent) — was wollen SIE erreichen? ──────────────────────────
+# The selection input is NOT a certificate. It is (Company Profile, Target). Intent = „CRA-konform werden".
+TARGET = "CRA"
+w("## 1. Ziel _(Intent)_ — was wollen Sie erreichen?")
+w('- Intent: **„CRA-konform werden"** → Ziel-Profil = **CRA** (die von der CRA geforderten Fähigkeiten).')
+w("- Auswahl-Eingabe ist damit **(Company Profile, Ziel)** — **kein** Zertifikat, das auf eine Journey gemappt wird.")
+w("")
+
+# ── 2. Capability Delta — Profil → Ziel (das ist „die Journey") ────────────
+reqs = [TargetRequirement(capability_id=a["capability"]) for a in CP["likely_covered"]]
+reqs += [TargetRequirement(capability_id=d["capability"], question_intent=d.get("needed_information", "verify_existence"))
+         for d in CP["delta_requirements"]]
+assess = assess_transition(TransitionContext(company_id="mc", target=TransitionGoal(target_id=TARGET)), reqs, profile)
+missing = sorted({c.capability_id for c in assess.coverage if c.status == CoverageStatus.MISSING})
+
+# counterfactual: a single-certificate company (ISO 27001 only) — to show evidence shrinks the delta.
+single_prof = build_company_profile(
+    CompanyContext(company_id="s", certifications=[Certification(certification_id="ISO27001")]),
+    {"ISO27001": CapabilityMappingEntry(capability_ids=infosec, confidence=Confidence.MEDIUM)})
+single_missing = sorted({c.capability_id for c in
+    assess_transition(TransitionContext(company_id="s", target=TransitionGoal(target_id=TARGET)), reqs, single_prof).coverage
+    if c.status == CoverageStatus.MISSING})
+closed_by_evidence = sorted(set(single_missing) - set(missing))
+
+w('## 2. Capability Delta — Profil → CRA _(das IST die „Journey")_')
+w("> %s" % assess.summary.headline)
+w("- **Delta dieses Profils:** %d fehlende Fähigkeiten." % len(missing))
+w("- **Gegenprobe (nur ISO 27001):** %d fehlende Fähigkeiten." % len(single_missing))
+w("- **Mehr Evidence → kleineres Delta:** die zusätzliche Zertifizierung schließt **%d** Fähigkeiten *vorab*: %s." % (
+    len(closed_by_evidence), ", ".join("`%s`" % c for c in closed_by_evidence)))
+w("")
+w("→ Es wurde **keine Journey ausgewählt**. Das Delta `(Profil, Ziel)` IST die Journey — berechnet, nicht gewählt. Die Journey ist nur die *Erklärung* dieses Deltas.")
+w("")
+
+# ── 3. Roadmap — was zuerst? (gleicher Engine wie #1) ─────────────────────
+delta_t = {d["capability"]: d.get("covers_targets", []) for d in CP["delta_requirements"]}
+opt = roadmap_from_delta(assess, delta_t)
+bud = select_within_budget({m.capability_id: m.covers for m in opt.ranked_measures}, 5)
+w("## 3. Roadmap — was zuerst? _(gleicher Hebel-Engine wie Mission #1)_")
+w("> %s" % opt.headline)
+w("- Top-5 nach Hebel schließen **%d von %d** offenen Anforderungen (%d%%)." % (
+    bud.requirements_closed, bud.total_requirements, int(round(bud.coverage_ratio * 100))))
+w("")
+
+# ── Selektions-Rationale (die vom User geforderten 5 Fragen) ───────────────
+rationale("Welche Journey wurde gewählt?",
+          "**Keine per-Zertifikat-Journey.** Die Journey ist `Company Capability Profile → CRA`. Gewählt wurde nur das **Ziel** (CRA); der Startzustand wurde aus ALLEN Zertifikaten aggregiert.")
+rationale("Warum?",
+          'Bei 6 Zertifikaten würde „ISO 27001 → CRA" die Evidence aus PSIRT/ISO 9001 wegwerfen (= 3 Fähigkeiten, die sonst fälschlich als Delta erschienen). Nur das **ganze Profil** ergibt das korrekte Delta.')
+rationale("Welche Informationen waren für die Auswahl entscheidend?",
+          "(a) das **Ziel/Intent** (CRA) und (b) die **vollständige Zertifikatsliste** als Profil — **nicht** ein einzelnes Zertifikat. Welche Evidence hilft, ist **zielrelativ** (ISO 14001 irrelevant, PSIRT hoch-relevant).")
+rationale("Musste das Journey-Modell erweitert werden?",
+          "**Konzeptionell ja, strukturell nein.** `from → to` bleibt; aber `from` ist ein **Company Capability Profile** (Multi-Cert-Aggregat), kein Zertifikat. Die Engines (`build_company_profile` + `assess_transition`) tun das BEREITS — es war ein Benenn-/Framing-Fehler, kein fehlender Code.")
+rationale("Musste ein neuer Selektionsparameter eingeführt werden?",
+          "**Ja — und er VEREINFACHT.** Eingabe ist `(Company Profile, Ziel)`, nicht `(Zertifikat, Ziel)`. Die Zertifikate kollabieren ins Profil → **keine 2^N Cert-Kombinationen**, nur Profil→Ziel. Der Selektor wird damit kleiner, nicht größer.")
+w("## Selektions-Rationale — die 5 Fragen (pro Mission zu dokumentieren)")
+w("")
+for q, a in RAT:
+    w("**%s**  " % q)
+    w(a)
+    w("")
+
+# ── Was diese Mission über Mission #1 verändert ───────────────────────────
+w("## Was Mission #2 an Mission #1 verändert")
+w("")
+w('- Mission #1 nannte **Scope → Journey** einen Sprung („kein Selektor `certs × targets → journeys`"). Mission #2 zeigt: **diese Naht schrumpft.** Es gibt keinen Journey-Matcher zu bauen — die Journey ist das **berechnete Delta** `(Profil, Ziel)`. Was real fehlt, ist nur **Profil-Intake + Ziel-Wahl**, nicht eine Journey-Auswahl-Engine.')
+w('- Bestätigt den Reframe: **Es gibt keine „ISO 27001 → CRA"-Transition — nur „Company Capability Profile → CRA".** Zertifikate sind **Beobachtungen/Evidence**, kein Journey-Startpunkt.')
+w("- **Beobachtung für den (noch nicht gebauten) Selektor:** Eingabe = `(Company Profile, Ziel)`. Diversität über weitere Missionen muss zeigen, ob auch **Produktprofil** und **Intent-Klasse** als Parameter nötig werden — erst dann kanonisieren ([[rule-of-three-canonicalization]]).")
+w("")
+
+print("\n".join(OUT))
diff --git a/backend-compliance/tests/test_customer_mission_2.py b/backend-compliance/tests/test_customer_mission_2.py
new file mode 100644
index 00000000..39a79a21
--- /dev/null
+++ b/backend-compliance/tests/test_customer_mission_2.py
@@ -0,0 +1,70 @@
+"""Customer Mission #2 — the company arrives with a PROFILE, not a journey.
+
+Pins the reframe Mission #2 proves with the real engines: the start state is a Company Capability
+Profile (many certs aggregated), certifications are observations/evidence, and more evidence shrinks
+the delta (single-cert 12 → multi-cert 9). The „journey" is the computed delta `(Profile, Target)`,
+not a thing a selector picks — which shrinks Mission #1's one open seam.
+"""
+
+from __future__ import annotations
+
+import os
+import subprocess
+import sys
+
+
+def _run_mission():
+    root = os.path.join(os.path.dirname(__file__), "..")
+    r = subprocess.run(
+        [sys.executable, "reference_scenarios/mission_multicert_cra.py"],
+        cwd=root, env={**os.environ, "PYTHONPATH": "."}, capture_output=True, text=True,
+    )
+    assert r.returncode == 0, r.stderr
+    return r.stdout
+
+
+def test_mission_runs_end_to_end():
+    out = _run_mission()
+    assert "Customer Mission #2" in out
+    assert "Company Capability Profile — der eigentliche Startzustand" in out
+
+
+def test_more_evidence_shrinks_the_delta():
+    out = _run_mission()
+    # multi-cert profile (9) must beat the single-cert counterfactual (12) — evidence is additive.
+    assert "**Delta dieses Profils:** 9" in out
+    assert "**Gegenprobe (nur ISO 27001):** 12" in out
+    assert "Mehr Evidence → kleineres Delta" in out
+
+
+def test_reframe_no_per_certificate_journey():
+    out = _run_mission()
+    # the journey is the computed delta (Profile, Target), not a selected cert→target transition.
+    assert "Keine per-Zertifikat-Journey" in out
+    assert "Company Capability Profile → CRA" in out
+    assert "Es wurde **keine Journey ausgewählt**" in out
+
+
+def test_five_selection_rationale_questions_present():
+    out = _run_mission()
+    for q in [
+        "Welche Journey wurde gewählt?",
+        "Warum?",
+        "Welche Informationen waren für die Auswahl entscheidend?",
+        "Musste das Journey-Modell erweitert werden?",
+        "Musste ein neuer Selektionsparameter eingeführt werden?",
+    ]:
+        assert q in out
+
+
+def test_evidence_is_target_relative():
+    out = _run_mission()
+    # honest: ISO 14001 is in the profile but does not help the CRA; PSIRT covers two CRA-delta caps.
+    assert "ISO 14001" in out and "NICHT relevant" in out
+    assert "PSIRT" in out
+
+
+def test_no_real_company_names():
+    out = _run_mission().lower()
+    for name in ["eto", "owis", "winterhalter"]:
+        assert name not in out
diff --git a/obligations/PROPOSED_machinery_capability_linking_iace.json b/obligations/PROPOSED_machinery_capability_linking_iace.json
new file mode 100644
index 00000000..aff729ba
--- /dev/null
+++ b/obligations/PROPOSED_machinery_capability_linking_iace.json
@@ -0,0 +1,326 @@
+{
+  "schema_proposal": "machinery_obligation_capability_linking_v0",
+  "status": "PROPOSED",
+  "proposed_by": "iace-session",
+  "for_ratification_by": ["legal-knowledge-graph", "execution"],
+  "reference_scenario": "RS-004",
+  "regulation_code": "MaschVO_2023_1230",
+  "regulation_aliases": ["MaschinenVO", "Machinery Regulation (EU) 2023/1230"],
+  "authority_note": "IACE holds SAFETY-classification authority and offers these links as machinery-safety domain input. Obligation DEFINITIONS remain the Legal-KG's authority; capability/control MINTING and the canonical mapping FORMAT remain Execution's authority. Nothing here is asserted into either registry. cap.* ids on physical/process links are CANDIDATES (not minted) — ratify, rename, or remap before merging into the canonical mapping. See semantic-authority principle: propose, do not assert across authorities.",
+  "scope": {
+    "in_scope": "MaschVO obligation -> capability/control linking (RS-004 part A), from the machinery-safety side.",
+    "out_of_scope": [
+      "EMV (EMC Directive 2014/30/EU) obligation authoring (RS-004 part B): EMV obligations do not yet exist in the registry. Legal-KG to author via its clustering+synthesis methodology. IACE can supply EMC domain input on request, but will not hand-author obligations (bypasses the owning authority's method).",
+      "Regulation-ID normalization / scope-engine wiring so the map resolves regulation -> obligations (RS-004 part C): Reasoning/Execution consumer code. NOTE: regulation_code 'MaschVO_2023_1230' must alias to the scope-engine id 'MaschinenVO' for resolution to work (board TODO 'Regelwerk-ID-Normalisierung').",
+      "Minting MCAP-/control-ids: Execution authority."
+    ]
+  },
+  "confidence_legend": {
+    "high": "Link target already exists in the registry (cra_core obligation or minted capability). Immediately usable.",
+    "medium": "Link target likely exists but the exact id needs an owner check.",
+    "proposed": "Target capability is a CANDIDATE to be minted by Execution; the link is safety-expert input, not a wired reference.",
+    "non_capability": "Obligation is regulatory/applicability in nature and does NOT map to a capability — flagged so Execution does not force a link."
+  },
+  "links": [
+    {
+      "obligation_id": "access_control_safety_functions",
+      "subdomain": "cybersecurity",
+      "link_kind": "cyber_safety_bridge",
+      "confidence": "high",
+      "targets_existing": {
+        "cra_core_obligations": ["attack_surface_minimization"],
+        "capabilities": ["cap.multi_factor_authentication", "cap.session_management"]
+      },
+      "rationale": "MaschVO Anhang III 1.1.9: safety functions must be protected against unauthorized access/modification. Satisfied by the same access-control + attack-surface controls CRA already requires. Convergence link, not a new control.",
+      "convergence": "CRA <-> MaschinenVO: one control set satisfies both"
+    },
+    {
+      "obligation_id": "protection_against_corruption",
+      "subdomain": "cybersecurity",
+      "link_kind": "cyber_safety_bridge",
+      "confidence": "high",
+      "targets_existing": {
+        "cra_core_obligations": ["software_integrity_protection"],
+        "capabilities": ["cap.code_signing"]
+      },
+      "rationale": "MaschVO 1.1.9/1.2.1: protect control software and safety-relevant data against accidental or intentional corruption. Satisfied by CRA software-integrity + code/update signing.",
+      "convergence": "CRA <-> MaschinenVO: one control set satisfies both"
+    },
+    {
+      "obligation_id": "security_functions_default_free",
+      "subdomain": "cybersecurity",
+      "link_kind": "cyber_safety_bridge",
+      "confidence": "medium",
+      "targets_existing": {
+        "cra_core_obligations": ["secure_by_default"],
+        "capabilities": []
+      },
+      "rationale": "Security functions provided secure-by-default and without extra cost. Maps to CRA secure-by-default posture.",
+      "needs_owner_check": "Confirm a CRA 'secure_by_default' obligation id exists in cra_core; if not, propose one or link to the closest secure-configuration obligation."
+    },
+    {
+      "obligation_id": "ml_safety_components",
+      "subdomain": "ml_safety",
+      "link_kind": "cross_regulation_bridge",
+      "confidence": "proposed",
+      "proposed_capability": "cap.ml_safety_assurance",
+      "bridges": ["AI-Act (high-risk safety components)", "MaschVO Anhang III adaptive behaviour"],
+      "iace_grounding": "Adaptive/self-learning safety components: bounded behaviour, validation of learned states, fallback to safe state. IACE state-graph + failure-mode (FMEA) families apply.",
+      "rationale": "MaschVO treats ML-driven safety components as high-risk; same assurance obligations recur under the AI-Act. Strong convergence candidate."
+    },
+    {
+      "obligation_id": "long_term_availability_updates",
+      "subdomain": "maintenance",
+      "link_kind": "cross_regulation_bridge",
+      "confidence": "proposed",
+      "proposed_capability": "cap.update_availability",
+      "bridges": ["CRA vulnerability-handling / security updates"],
+      "rationale": "Long-term availability of (security) updates overlaps CRA's vulnerability-handling obligations — link once the CRA update obligation id is confirmed."
+    },
+    {
+      "obligation_id": "guards_protective_devices",
+      "subdomain": "protective_devices",
+      "link_kind": "physical_safety",
+      "confidence": "proposed",
+      "proposed_capability": "cap.guards_protective_devices",
+      "registry_candidate": true,
+      "iace_grounding": "ISO 14120 (fixed/movable guards), ISO 14119 (interlocking with/without guard locking). IACE hazard categories: mechanical, crushing, shearing, drawing-in.",
+      "rationale": "Already listed in cra_machinery capability_candidates_physical. Safety-expert grounding attached."
+    },
+    {
+      "obligation_id": "emergency_stop_interlocking",
+      "subdomain": "safety_functions",
+      "link_kind": "physical_safety",
+      "confidence": "proposed",
+      "proposed_capability": "cap.emergency_stop_interlocking",
+      "registry_candidate": true,
+      "iace_grounding": "ISO 13850 (emergency stop), ISO 14118 (prevention of unexpected start-up), ISO 14119 (interlocking).",
+      "rationale": "Already listed in cra_machinery capability_candidates_physical. Safety-expert grounding attached."
+    },
+    {
+      "obligation_id": "safety_functions_design",
+      "subdomain": "safety_functions",
+      "link_kind": "physical_safety",
+      "confidence": "proposed",
+      "proposed_capability": "cap.safety_functions_design",
+      "registry_candidate": true,
+      "iace_grounding": "ISO 13849-1 (PL, categories) / IEC 62061 (SIL) for safety-related parts of control systems (SRP/CS); validation per ISO 13849-2.",
+      "rationale": "Already listed in cra_machinery capability_candidates_physical. Safety-expert grounding attached."
+    },
+    {
+      "obligation_id": "safety_components_conformity",
+      "subdomain": "safety_components",
+      "link_kind": "physical_safety",
+      "confidence": "proposed",
+      "proposed_capability": "cap.safety_component_conformity",
+      "iace_grounding": "Listed safety components (MaschVO Anhang I) carry their own conformity duty; design validation per ISO 13849-2.",
+      "rationale": "Distinct from safety_functions_design: this is conformity of the COMPONENT placed on the market, not the integrated function."
+    },
+    {
+      "obligation_id": "residual_risk_management",
+      "subdomain": "residual_risk",
+      "link_kind": "physical_safety",
+      "confidence": "proposed",
+      "proposed_capability": "cap.residual_risk_reduction",
+      "iace_grounding": "ISO 12100 three-step method (inherently safe design -> safeguarding -> information for use); residual-risk warnings + instructions.",
+      "rationale": "Directly mirrors IACE's measure-hierarchy output."
+    },
+    {
+      "obligation_id": "blocking_release_procedure",
+      "subdomain": "protective_devices",
+      "link_kind": "physical_safety",
+      "confidence": "proposed",
+      "proposed_capability": "cap.energy_isolation_loto",
+      "iace_grounding": "ISO 14118 (unexpected start-up), lockout/tagout, safe isolation of energy sources for maintenance.",
+      "rationale": "Maintenance-state hazard control; IACE lifecycle-state = maintenance."
+    },
+    {
+      "obligation_id": "vibration_noise_emission",
+      "subdomain": "emissions",
+      "link_kind": "physical_safety",
+      "confidence": "proposed",
+      "proposed_capability": "cap.emission_reduction",
+      "iace_grounding": "EHSR on vibration + noise; emission reduction at source, declared emission values.",
+      "rationale": "Health-hazard category in IACE (vibration, noise)."
+    },
+    {
+      "obligation_id": "risk_assessment_machinery_lifecycle",
+      "subdomain": "risk_assessment",
+      "link_kind": "process",
+      "confidence": "proposed",
+      "proposed_capability": "cap.machinery_risk_assessment",
+      "iace_grounding": "ISO 12100 risk assessment across the full lifecycle. THIS IS IACE'S CORE OUTPUT — strongest provider-fact alignment of the set.",
+      "rationale": "IACE already produces lifecycle hazard logs; this obligation is the regulatory counterpart."
+    },
+    {
+      "obligation_id": "risk_assessment_documentation",
+      "subdomain": "risk_assessment",
+      "link_kind": "process",
+      "confidence": "proposed",
+      "proposed_capability": "cap.risk_assessment_record",
+      "iace_grounding": "Documented risk-assessment record feeding the technical file.",
+      "rationale": "IACE hazard-log export is the evidence artifact."
+    },
+    {
+      "obligation_id": "risk_assessment_methodology_competence",
+      "subdomain": "risk_assessment",
+      "link_kind": "process",
+      "confidence": "proposed",
+      "proposed_capability": "cap.risk_assessment_competence",
+      "tier": "BEST_PRACTICE",
+      "rationale": "Competence/methodology assurance for the assessor — organizational, not a machine control."
+    },
+    {
+      "obligation_id": "operating_instructions",
+      "subdomain": "operating_instructions",
+      "link_kind": "process",
+      "confidence": "proposed",
+      "proposed_capability": "cap.safety_information_instructions",
+      "iace_grounding": "ISO 12100 6.4 information for use; IEC/IEEE 82079-1 instructions.",
+      "rationale": "Carries IACE residual-risk warnings into the instructions."
+    },
+    {
+      "obligation_id": "conformity_assessment",
+      "subdomain": "conformity",
+      "link_kind": "process",
+      "confidence": "proposed",
+      "proposed_capability": "cap.conformity_assessment_procedure",
+      "iace_grounding": "MaschVO Anhang XI procedures (internal control vs notified-body routes).",
+      "rationale": "Procedure selection depends on Anhang I high-risk classification."
+    },
+    {
+      "obligation_id": "technical_documentation",
+      "subdomain": "documentation",
+      "link_kind": "process",
+      "confidence": "proposed",
+      "proposed_capability": "cap.technical_file",
+      "iace_grounding": "MaschVO Anhang IV technical file; risk assessment is a mandatory part.",
+      "rationale": "IACE hazard log is a required input to the technical file."
+    },
+    {
+      "obligation_id": "eu_declaration_ce_marking",
+      "subdomain": "conformity",
+      "link_kind": "process",
+      "confidence": "proposed",
+      "proposed_capability": "cap.ce_marking_declaration",
+      "iace_grounding": "MaschVO Anhang V EU declaration of conformity + CE marking affixing.",
+      "rationale": "Final conformity attestation step."
+    },
+    {
+      "obligation_id": "manufacturer_economic_operator_obligations",
+      "subdomain": "economic_operators",
+      "link_kind": "process",
+      "confidence": "proposed",
+      "proposed_capability": "cap.economic_operator_duties",
+      "rationale": "Manufacturer/importer/distributor duty chain — organizational."
+    },
+    {
+      "obligation_id": "essential_safety_requirements_compliance",
+      "subdomain": "ehsr",
+      "link_kind": "process",
+      "confidence": "proposed",
+      "proposed_capability": "cap.ehsr_compliance",
+      "iace_grounding": "MaschVO Anhang III essential health and safety requirements — the umbrella that the physical_safety capabilities collectively satisfy.",
+      "rationale": "Composite: satisfied via the physical_safety capabilities above; model as an aggregate rather than a single control."
+    },
+    {
+      "obligation_id": "harmonised_standards_selection",
+      "subdomain": "standards",
+      "link_kind": "process",
+      "confidence": "proposed",
+      "proposed_capability": "cap.harmonised_standards",
+      "tier": "BEST_PRACTICE",
+      "iace_grounding": "Use of harmonised standards grants presumption of conformity; IACE's ISO references (12100/13849/14120/13850) are the candidate set.",
+      "rationale": "Links the standards IACE already cites to the presumption-of-conformity mechanism."
+    },
+    {
+      "obligation_id": "notified_body_requirements",
+      "subdomain": "notified_body",
+      "link_kind": "process",
+      "confidence": "proposed",
+      "proposed_capability": "cap.notified_body_involvement",
+      "iace_grounding": "MaschVO Anhang I Part A high-risk machinery requires notified-body involvement.",
+      "rationale": "Triggered by Anhang I classification of the machine."
+    },
+    {
+      "obligation_id": "modification_substantial_change",
+      "subdomain": "modification",
+      "link_kind": "process",
+      "confidence": "proposed",
+      "proposed_capability": "cap.substantial_modification_assessment",
+      "iace_grounding": "Substantial modification can create a 'new' machine requiring fresh conformity; re-run risk assessment.",
+      "rationale": "IACE re-assessment is the trigger artifact."
+    },
+    {
+      "obligation_id": "autonomous_mobile_machinery",
+      "subdomain": "mobile_machinery",
+      "link_kind": "physical_safety",
+      "confidence": "proposed",
+      "proposed_capability": "cap.amr_safety",
+      "iace_grounding": "Mobile/autonomous machinery EHSR: travel functions, supervision, monitoring, safe stop in autonomous mode.",
+      "rationale": "Distinct hazard family (mobility) in IACE."
+    },
+    {
+      "obligation_id": "verification_inspection_maintenance",
+      "subdomain": "verification",
+      "link_kind": "process",
+      "confidence": "proposed",
+      "proposed_capability": "cap.in_service_verification",
+      "tier": "BEST_PRACTICE",
+      "rationale": "In-service inspection/maintenance regime — lifecycle-state = in_service/maintenance."
+    },
+    {
+      "obligation_id": "quality_management_system",
+      "subdomain": "quality_management",
+      "link_kind": "process",
+      "confidence": "proposed",
+      "proposed_capability": "cap.quality_management_system",
+      "tier": "BEST_PRACTICE",
+      "iace_grounding": "MaschVO Anhang IX full quality-assurance route.",
+      "rationale": "Organizational QA enabling the conformity route."
+    },
+    {
+      "obligation_id": "market_surveillance_safeguard",
+      "subdomain": "market_surveillance",
+      "link_kind": "non_capability",
+      "confidence": "non_capability",
+      "rationale": "Cooperation with market-surveillance authorities + safeguard procedure: a regulatory-interaction duty, not a machine/process capability. Flagged so Execution does not force a capability link.",
+      "owner_decision": "Legal-KG to decide whether to model as an obligation-only node."
+    },
+    {
+      "obligation_id": "sanctions",
+      "subdomain": "sanctions",
+      "link_kind": "non_capability",
+      "confidence": "non_capability",
+      "rationale": "Penalty regime — a legal consequence, not a capability. No control link.",
+      "owner_decision": "Legal-KG: obligation-only node."
+    },
+    {
+      "obligation_id": "scope_transition_application",
+      "subdomain": "scope",
+      "link_kind": "non_capability",
+      "confidence": "non_capability",
+      "rationale": "Applicability + transition dates (old Directive 2006/42/EC -> Regulation 2023/1230). This drives the SCOPE engine, not a capability. RS-004 part C (reg-ID/scope wiring) is the right home.",
+      "owner_decision": "Reasoning/scope-engine, not a capability."
+    },
+    {
+      "obligation_id": "specific_machine_types",
+      "subdomain": "specific_machinery",
+      "link_kind": "composite",
+      "confidence": "proposed",
+      "rationale": "Machine-type-specific EHSR (e.g. lifting, portable, wood/food machinery). Resolves to MULTIPLE physical_safety capabilities depending on machine type — model as a type-conditional set, not one control.",
+      "owner_decision": "Execution: expand per machine-type once the physical_safety capabilities are minted."
+    }
+  ],
+  "summary": {
+    "obligations_total": 31,
+    "cyber_safety_bridges_high_confidence": 2,
+    "cyber_safety_bridges_needs_check": 1,
+    "cross_regulation_bridges": 2,
+    "physical_safety_candidates": 7,
+    "process_candidates": 13,
+    "non_capability_flags": 3,
+    "composite": 1,
+    "headline": "The 2 high-confidence cyber-safety bridges are immediately wirable to existing CRA-core obligations + capabilities (the CRA<->MaschinenVO convergence USP). Everything else is safety-expert input for Execution to mint and Legal-KG to ratify."
+  }
+}