docs(knowledge): TP-ISO27001->CRA gold standard + reference scenario (RS-005 regression)

(1) Harden the first Transition Pattern to the gold-standard template per quality checklist:
versioned transition_goal (ISO27001:2022 -> CRA, applies 2027-12-11), source_state_variants
(certified/isms_introduced/expired/limited_scope), each likely_covered assumption with a typed
relationship (supports|partially_supports, never equivalent) + verification + rationale (the Warum)
+ an auditor-checkable reviewable_claim, delta as missing-capability + needed-info, an explicit
rejected_assumptions section, and a determinism_goal. README schema updated to match.

(2) New Reference-Suite scenario 4 (Transition): the generator READS the pattern YAML and runs it
through the RS-005 Planning Engine + Company 2A -> coverage + question requests. Proves the
architecture fully carries the pattern (17 caps -> 17 coverage + 17 requests; 9 HIGH delta = the
real CRA gaps, 8 probably-covered from the ISMS). Now a living regression test: every future pattern
runs through the same engine.

Non-runtime knowledge + reference harness -> no deploy (ADR-001). Next: ISMS->TISAX once approved.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

backend-compliance/knowledge/transition_patterns/README.md

@@ -20,11 +20,21 @@ not designed up front (the same identity-machine discipline as Master Controls/O
 
 ## File schema (per `transition_pattern_<from>_to_<to>_v<n>.yaml`)
 
-`id` · `from_state` · `to_state` · `version` · `status` (draft → reviewed → approved) ·
+`id` · `status` (draft → reviewed → approved) · `version` ·
+`transition_goal` ({from: standard/edition/nature, to: regulation/reference/applies_from/nature, one_line}) ·
 `provenance` (author/basis/reviewed_by/reviewed_at) · `disclaimer` ·
-`likely_covered_org_level[]` ({capability, source_basis, target_relevance, reuse_caveat,
+`source_state_variants` (certified / isms_introduced / expired / limited_scope — how the start changes assumption strength) ·
-confirm_question_intent, priority}) · `delta_requirements[]` ({capability, target_basis, why_delta,
+`likely_covered[]` ({capability, source_basis, target, **relationship** (supports|partially_supports, never equivalent),
-question_intent, expected_evidence, priority}) · `ask_order_rationale` · `review_required[]`.
+**verification** (required), expected_evidence, **rationale** (the *Warum* — why this relationship), **reviewable_claim**
+(an auditor can agree/disagree)}) ·
+`delta_requirements[]` ({capability, target_basis, **missing_because**, needed_information (intent),
+expected_evidence, priority, **reviewable_claim**}) ·
+`rejected_assumptions[]` (explicit "does NOT establish …") · `determinism_goal` · `review_checklist[]`.
+
+**Gold-standard bar:** every line is auditor-checkable (agree/disagree, not "probably"); each assumption
+carries a typed `relationship` + a `rationale`; each delta maps to a missing capability + needed info;
+explicit `rejected_assumptions` keep the source certificate from being over-read; two auditors should
+arrive at the same delta questions (`determinism_goal`).
 
 ## Hard rules
 

backend-compliance/knowledge/transition_patterns/transition_pattern_iso27001_to_cra_v1.yaml

@@ -1,182 +1,207 @@
 # Transition Pattern — ISO/IEC 27001 (ISMS)  ->  CRA (Cyber Resilience Act, Reg. (EU) 2024/2847)
-# Curated expert knowledge (NOT runtime code). Belongs to the Reasoning session's
+# GOLD-STANDARD structure (the template all future patterns adopt). Curated expert knowledge,
-# Knowledge Acquisition responsibility. Consumed later by the Transition Planning Engine
+# NOT runtime code. Consumed later by the Transition Planning Engine (RS-005) and Renderer (RS-005.1).
-# (RS-005) and the Question Renderer (RS-005.1); rendered into a Transition Interview.
 
 id: TP-ISO27001-CRA-v1
-from_state: ISO27001            # ISO/IEC 27001:2022 (organizational ISMS)
+status: draft                 # draft -> reviewed -> approved (auditor review pending)
-to_state: CRA                   # Regulation (EU) 2024/2847 (product cybersecurity)
 version: 1
-status: draft                   # draft -> reviewed -> approved (human/auditor review pending)
+
+transition_goal:
+  from:
+    standard: "ISO/IEC 27001"
+    edition: "2022"
+    nature: organizational_isms
+  to:
+    regulation: "Cyber Resilience Act"
+    reference: "Regulation (EU) 2024/2847"
+    applies_from: "2027-12-11"          # main obligations
+    nature: product_cybersecurity
+  one_line: "Move a manufacturer with a certified ISMS toward CRA conformity for a product with digital elements."
+
 provenance:
-  author: "Claude (Reasoning session) — first expert draft"
+  author: "Claude (Reasoning session) — first expert draft, gold-standard structure"
-  basis: "ISO/IEC 27001:2022 Annex A controls vs CRA Annex I (Part I security requirements,
+  basis: "ISO/IEC 27001:2022 Annex A vs CRA Annex I (Part I security requirements, Part II vulnerability handling), Art. 13 (support period), Art. 14 (reporting), conformity assessment + CE + technical documentation (Annex VII)."
-          Part II vulnerability handling) + reporting (Art. 14) + support period (Art. 13) +
-          conformity assessment / CE / technical documentation (Annex VII)."
   reviewed_by: null
   reviewed_at: null
 
 disclaimer: >
-  Expert DRAFT, not a normative or legal proof that these points exactly represent either
+  Expert DRAFT, not a normative or legal proof. KEY ASYMMETRY: ISO 27001 is ORGANIZATIONAL (an ISMS);
-  standard. KEY ASYMMETRY: ISO 27001 is ORGANIZATIONAL (an ISMS); the CRA is PRODUCT-level
+  the CRA is PRODUCT-level. Every assumption below is Welt-1 — a hint that requires PRODUCT-level
-  (security of products with digital elements). Therefore an existing ISO 27001 capability
+  evidence, never automatically "erfüllt". Each line is phrased so an auditor can explicitly AGREE or
-  is at most a Welt-1 hint ("probably covered, organizationally") and ALWAYS needs PRODUCT-
+  DISAGREE (not "probably").
-  level evidence before it counts for the CRA — it is never automatically "erfüllt".
 
-# ──────────────────────────────────────────────────────────────────────────
+# How the starting point changes how strongly the assumptions transfer.
-# A) LIKELY COVERED at the organizational level by a mature ISMS.
+source_state_variants:
-#    -> status "probably_covered"; each still needs a PRODUCT-level confirmation question.
+  certified:       "ISO 27001 certificate valid AND scope covers the product's development/operations -> assumptions hold at the stated relationship."
-# ──────────────────────────────────────────────────────────────────────────
+  isms_introduced: "ISMS implemented but not certified -> downgrade every 'supports' to needs_confirmation."
-likely_covered_org_level:
+  expired:         "Certificate lapsed -> re-verify; treat all assumptions as needs_confirmation."
+  limited_scope:   "Certified scope excludes the product or its dev unit -> assumptions do NOT transfer; treat as missing until scope is confirmed."
+
+# ── A) LIKELY COVERED (org level). relationship + verification + rationale + reviewable claim. ──
+# relationship vocabulary aligns with the Capability Registry (2C): supports | partially_supports
+# (never "equivalent" here — an org control is never product-equivalent on its own).
+likely_covered:
   - capability: incident_management
     iso27001_basis: [A.5.24, A.5.25, A.5.26, A.5.27, A.5.28]
-    cra_relevance: [Annex_I_Part_II_handling, Art_14_reporting]
+    cra_target: [Annex_I_Part_II, Art_14_reporting]
-    reuse_caveat: "An incident process exists organizationally. The CRA delta is PRODUCT incident
+    relationship: supports
-      handling AND mandatory reporting of actively exploited vulnerabilities / severe incidents to
+    verification: required
-      the CSIRT/ENISA (Art. 14) — that authority-reporting duty has no ISO 27001 analogue."
+    expected_evidence: [incident_response_procedure]
-    confirm_question_intent: verify_product_scope
+    rationale: "ISO 27001 covers ORGANIZATIONAL incident management; the CRA additionally demands PRODUCT vulnerability handling and statutory reporting to CSIRT/ENISA. Hence 'supports', not 'equivalent'."
-    priority: medium
+    reviewable_claim: "A certified ISMS provides an incident-management foundation but does NOT by itself satisfy CRA product incident handling or Art. 14 reporting."
 
   - capability: technical_vulnerability_management
     iso27001_basis: [A.8.8]
-    cra_relevance: [Annex_I_Part_II_2]
+    cra_target: [Annex_I_Part_II_2]
-    reuse_caveat: "Internal vulnerability management is likely in place. The CRA delta is a PRODUCT-
+    relationship: supports
-      facing process: PSIRT + coordinated vulnerability disclosure + advisories (below)."
+    verification: required
-    confirm_question_intent: verify_product_scope
+    expected_evidence: [vulnerability_management_procedure]
-    priority: medium
+    rationale: "Internal vulnerability management exists; the CRA needs a PRODUCT-facing process (PSIRT, coordinated disclosure). Hence 'supports'."
+    reviewable_claim: "Internal vulnerability management does NOT establish a product PSIRT or CVD."
 
   - capability: supplier_security
     iso27001_basis: [A.5.19, A.5.20, A.5.21, A.5.22]
-    cra_relevance: [Annex_I_Part_II_1_components]
+    cra_target: [Annex_I_Part_II_1_components]
-    reuse_caveat: "Supplier security exists; the CRA delta is component-level transparency (SBOM)
+    relationship: supports
-      and tracking vulnerabilities in third-party / open-source components."
+    verification: required
-    confirm_question_intent: verify_product_scope
+    expected_evidence: [supplier_security_policy]
-    priority: medium
+    rationale: "Supplier security exists; the CRA needs component-level transparency (SBOM) and tracking third-party/OSS vulnerabilities. Hence 'supports'."
+    reviewable_claim: "Supplier security does NOT establish an SBOM or component vulnerability tracking."
 
   - capability: access_control_and_authentication
-    iso27001_basis: [A.5.15, A.5.16, A.5.17, A.5.18, A.8.2, A.8.5]
+    iso27001_basis: [A.5.15, A.5.16, A.5.17, A.5.18, A.8.5]
-    cra_relevance: [Annex_I_Part_I_4]
+    cra_target: [Annex_I_Part_I_4]
-    reuse_caveat: "Org access control is mature; the CRA delta is product authentication, no default
+    relationship: supports
-      credentials, and protection of the product against unauthorized access."
+    verification: required
-    confirm_question_intent: verify_existence
+    expected_evidence: [access_control_policy]
-    priority: medium
+    rationale: "Org access control is mature; the CRA needs product authentication and no default credentials. Hence 'supports'."
+    reviewable_claim: "Org access control does NOT guarantee product authentication or absence of default credentials."
 
   - capability: cryptography
     iso27001_basis: [A.8.24]
-    cra_relevance: [Annex_I_Part_I_5, Annex_I_Part_I_6]
+    cra_target: [Annex_I_Part_I_5, Annex_I_Part_I_6]
-    reuse_caveat: "Crypto policy exists; the CRA delta is product-level confidentiality (encryption)
+    relationship: partially_supports
-      and integrity of data, commands, configuration and code."
+    verification: required
-    confirm_question_intent: verify_existence
+    expected_evidence: [cryptography_policy]
-    priority: low
+    rationale: "A crypto policy exists; whether the PRODUCT actually encrypts data and protects integrity is unproven. Hence 'partially_supports'."
+    reviewable_claim: "A crypto policy does NOT prove product-level confidentiality/integrity."
 
   - capability: security_logging_and_monitoring
     iso27001_basis: [A.8.15, A.8.16]
-    cra_relevance: [Annex_I_Part_I_12]
+    cra_target: [Annex_I_Part_I_12]
-    reuse_caveat: "Logging/monitoring exists organizationally; the CRA delta is recording security-
+    relationship: supports
-      relevant events ON the product (with an opt-out)."
+    verification: required
-    confirm_question_intent: verify_existence
+    expected_evidence: [logging_concept]
-    priority: low
+    rationale: "Org logging exists; the CRA needs security-relevant events recorded ON the product (with opt-out). Hence 'supports'."
+    reviewable_claim: "Org logging does NOT prove product security-event logging."
 
   - capability: secure_development_lifecycle
     iso27001_basis: [A.8.25, A.8.27, A.8.28, A.8.29]
-    cra_relevance: [Annex_I_Part_I_1, Annex_I_Part_II_3]
+    cra_target: [Annex_I_Part_I_1, Annex_I_Part_II_3]
-    reuse_caveat: "Secure development exists; the CRA delta is demonstrating secure-by-design product
+    relationship: supports
-      properties and regular security tests/reviews of the product."
+    verification: required
-    confirm_question_intent: verify_existence
+    expected_evidence: [secure_development_policy]
-    priority: medium
+    rationale: "Secure development exists; the CRA needs demonstrated secure-by-design product properties + regular product security tests. Hence 'supports'."
+    reviewable_claim: "A secure-development policy does NOT prove CRA secure-by-design product properties."
 
   - capability: asset_and_configuration_management
     iso27001_basis: [A.5.9, A.5.10, A.5.11, A.8.9]
-    cra_relevance: [Annex_I_Part_II_1_SBOM]
+    cra_target: [Annex_I_Part_II_1_SBOM]
-    reuse_caveat: "Asset/config management underpins an SBOM but is NOT an SBOM. The SBOM itself is a
+    relationship: partially_supports
-      delta item (below)."
+    verification: required
-    confirm_question_intent: verify_existence
+    expected_evidence: [asset_inventory]
-    priority: low
+    rationale: "Asset/config management UNDERPINS an SBOM but is not one. Hence 'partially_supports'; the SBOM itself is a delta item."
+    reviewable_claim: "Asset/config management does NOT constitute an SBOM."
 
-# ──────────────────────────────────────────────────────────────────────────
+# ── B) DELTA — CRA-specific, NO ISO 27001 analogue. missing for an ISO-only company; ask first. ──
-# B) DELTA — CRA-specific requirements with NO ISO 27001 analogue.
-#    -> status "missing" for an ISO-27001-only company; ask these FIRST.
-# ──────────────────────────────────────────────────────────────────────────
 delta_requirements:
   - capability: sbom_creation
-    cra_basis: "Annex I, Part II (1) — identify and document components, incl. a software bill of materials."
+    cra_basis: "Annex I, Part II (1) — document components incl. a software bill of materials."
-    why_delta: "ISO 27001 has no SBOM requirement."
+    missing_because: "ISO 27001 contains no SBOM requirement."
-    question_intent: determine_sbom_maturity     # enum: never / manual / automatic / continuous
+    needed_information: determine_sbom_maturity      # enum: never / manual / automatic / continuous
     expected_evidence: [sbom]
     priority: high
+    reviewable_claim: "An ISO-27001-only manufacturer typically has no SBOM."
 
   - capability: security_update_support_period
-    cra_basis: "Art. 13(8) support period (default >= 5 years) + Annex I Part I (3) / Part II (2,7) — provide security updates."
+    cra_basis: "Art. 13(8) support period (default >= 5 years) + Annex I Part I (3) / Part II (2,7)."
-    why_delta: "ISO 27001 defines no product support period or update-provision duty."
+    missing_because: "ISO 27001 defines no product support period or update-provision duty."
-    question_intent: determine_duration
+    needed_information: determine_duration
     expected_evidence: [support_policy, product_lifecycle_policy]
     priority: high
+    reviewable_claim: "ISO 27001 does not define a product security-update support period."
 
   - capability: secure_signed_update_distribution
-    cra_basis: "Annex I, Part II (8) — ensure security updates are disseminated securely (authenticity/integrity)."
+    cra_basis: "Annex I, Part II (8) — disseminate updates securely (authenticity/integrity)."
-    why_delta: "ISO integrity controls exist, but signed product update distribution is product-specific."
+    missing_because: "Signed PRODUCT update distribution is product-specific, beyond ISO integrity controls."
-    question_intent: verify_existence
+    needed_information: verify_existence
     expected_evidence: [config_export, test_report]
     priority: high
+    reviewable_claim: "ISO 27001 does not require signed product update distribution."
 
   - capability: coordinated_vulnerability_disclosure
-    cra_basis: "Annex I, Part II (5,6) — CVD policy + a contact address for reporting vulnerabilities."
+    cra_basis: "Annex I, Part II (5,6) — CVD policy + a reporting contact address."
-    why_delta: "ISO vulnerability management is internal; a product-facing CVD policy / PSIRT is the delta."
+    missing_because: "ISO vulnerability management is internal, not a product-facing CVD/PSIRT."
-    question_intent: verify_existence
+    needed_information: verify_existence
-    expected_evidence: [policy]
+    expected_evidence: [cvd_policy]
     priority: high
+    reviewable_claim: "ISO 27001 does not require a coordinated vulnerability disclosure policy."
 
   - capability: public_security_advisories
-    cra_basis: "Annex I, Part II (4,7) — publicly disclose information about fixed vulnerabilities; provide advisories."
+    cra_basis: "Annex I, Part II (4,7) — disclose fixed vulnerabilities; provide advisories."
-    why_delta: "No ISO 27001 obligation to publish product security advisories."
+    missing_because: "No ISO obligation to publish product security advisories."
-    question_intent: verify_existence
+    needed_information: verify_existence
-    expected_evidence: [policy]
+    expected_evidence: [advisory_process]
     priority: medium
+    reviewable_claim: "ISO 27001 does not require public product security advisories."
 
   - capability: exploited_vuln_and_incident_reporting
-    cra_basis: "Art. 14 — report actively exploited vulnerabilities and severe incidents to CSIRT/ENISA (24h early warning, 72h notification, final report)."
+    cra_basis: "Art. 14 — report actively exploited vulnerabilities + severe incidents to CSIRT/ENISA (24h early warning, 72h notification, final report)."
-    why_delta: "No ISO 27001 analogue; this is a statutory authority-reporting duty with fixed deadlines."
+    missing_because: "Statutory authority-reporting with fixed deadlines; no ISO 27001 analogue."
-    question_intent: verify_existence
+    needed_information: verify_existence
-    expected_evidence: [policy, ticket]
+    expected_evidence: [reporting_procedure]
     priority: high
+    reviewable_claim: "ISO 27001 does not establish CRA Art. 14 authority reporting."
 
   - capability: secure_by_default_no_default_credentials
-    cra_basis: "Annex I, Part I (2,4) — secure default configuration; no default passwords / forced change."
+    cra_basis: "Annex I, Part I (2,4) — secure default configuration; no default passwords."
-    why_delta: "A product property, not an ISMS control."
+    missing_because: "A product property, not an ISMS control."
-    question_intent: verify_existence
+    needed_information: verify_existence
     expected_evidence: [config_export, test_report]
     priority: medium
-
+    reviewable_claim: "ISO 27001 does not guarantee secure-by-default product configuration."
-  - capability: attack_surface_minimization
-    cra_basis: "Annex I, Part I (10,11) — limit attack surfaces; mitigate exploitation."
-    why_delta: "Product hardening property; not an ISO 27001 control."
-    question_intent: verify_existence
-    expected_evidence: [test_report, pentest]
-    priority: medium
 
   - capability: product_cyber_risk_assessment
-    cra_basis: "Annex I + technical documentation — cybersecurity risk assessment of the PRODUCT."
+    cra_basis: "Annex I + technical documentation — cybersecurity risk assessment OF THE PRODUCT."
-    why_delta: "ISO 27001 risk assessment is organizational; the CRA needs a product cyber risk assessment."
+    missing_because: "ISO 27001 risk assessment is organizational, not a product cyber risk assessment."
-    question_intent: verify_existence
+    needed_information: verify_existence
-    expected_evidence: [test_report, audit_log]
+    expected_evidence: [product_risk_assessment]
     priority: high
+    reviewable_claim: "An organizational risk assessment is not a CRA product cyber risk assessment."
 
   - capability: ce_conformity_assessment_and_technical_documentation
     cra_basis: "Conformity assessment + CE marking + EU Declaration of Conformity + technical documentation (Annex VII)."
-    why_delta: "An ISO 27001 certificate is NOT a CRA conformity assessment; the product-compliance dossier is the delta."
+    missing_because: "An ISO 27001 certificate is NOT a CRA conformity assessment."
-    question_intent: request_evidence
+    needed_information: request_evidence
-    expected_evidence: [test_report, audit_log]
+    expected_evidence: [technical_documentation, declaration_of_conformity]
     priority: high
+    reviewable_claim: "An ISO 27001 certificate does not satisfy CRA conformity assessment."
 
-# Suggested ask-order for an ISO-27001-only manufacturer moving to the CRA:
+# ── C) Explicit rejections — keep the certificate from being over-read. ──
-ask_order_rationale: >
+rejected_assumptions:
-  Ask the delta first — SBOM, support period + secure updates, coordinated vulnerability disclosure,
+  - "ISO 27001 does NOT establish a software bill of materials (SBOM)."
-  authority reporting (Art. 14), product cyber risk assessment, and CE conformity / technical
+  - "ISO 27001 does NOT establish a PSIRT or a coordinated vulnerability disclosure process for the product."
-  documentation. These have no ISO 27001 analogue and are where the real CRA work sits. The
+  - "ISO 27001 does NOT define a product security-update support period."
-  org-level capabilities above reduce effort but must each be re-scoped and re-evidenced at the
+  - "ISO 27001 does NOT produce CRA conformity assessment / CE marking / technical documentation."
-  PRODUCT level — never assumed "erfüllt" from the certificate alone.
+  - "ISO 27001 does NOT cover Art. 14 reporting of exploited vulnerabilities to CSIRT/ENISA."
+  - "ISO 27001 does NOT guarantee secure-by-default product configuration or absence of default credentials."
 
-review_required:
+determinism_goal: >
-  - "Validate CRA Annex/Article references with counsel before customer use (indicative here)."
+  Two independent ISO 27001 lead auditors reading this pattern should arrive at the SAME set of delta
-  - "Confirm the MCAP capability ids once the Capability Registry assigns them (placeholders here)."
+  questions for the same product. If they do not, the pattern is not yet gold standard.
-  - "Have an ISO 27001 lead auditor sanity-check the likely_covered vs delta split."
+
+review_checklist:
+  - "Validate every CRA Annex/Article reference with counsel before customer use (indicative here)."
+  - "Replace capability ids with the Capability Registry MCAP ids once assigned (placeholders here)."
+  - "Have an ISO 27001 lead auditor confirm the likely_covered vs delta split + each rationale."
+  - "Confirm each likely_covered item's relationship (supports vs partially_supports) and verification need."

backend-compliance/reference_scenarios/generate.py

@@ -34,6 +34,11 @@ from compliance.capability import (
     EvidenceKind, mint_capability, evaluate_relation,
 )
 from compliance.reasoning.enums import Confidence
+from compliance.transition_reasoning import (
+    TransitionContext, TransitionGoal, TargetType, TargetRequirement, assess_transition,
+)
+import os
+import yaml
 
 Row = Tuple[str, str, str]
 OUT: List[str] = []
@@ -235,6 +240,55 @@ coverage_table([
     ("cap ↔ MCAP Linking", "TODO", "zwei Vokabulare unverbunden → RS-003"),
 ])
 
+# ── Scenario 4 — Transition (RS-005 Planning Engine + Knowledge Pattern) ───
+w("## Szenario 4 — Transition ISO27001 → CRA (RS-005 + Pattern TP-ISO27001-CRA-v1)")
+w("")
+w('_Frage: „Ich bin ISO27001-zertifiziert — was fehlt mir für den CRA?"_')
+w("")
+_pat_path = os.path.join(os.path.dirname(__file__), "..", "knowledge", "transition_patterns",
+                         "transition_pattern_iso27001_to_cra_v1.yaml")
+with open(_pat_path, encoding="utf-8") as _f:
+    PAT = yaml.safe_load(_f)
+# „habe": ISO27001 -> the pattern's likely_covered capabilities become INFERRED via Company 2A
+_iso_caps = [a["capability"] for a in PAT["likely_covered"]]
+_iso_map = {"ISO27001": CapabilityMappingEntry(capability_ids=_iso_caps, confidence=Confidence.MEDIUM)}
+_profile = build_company_profile(
+    CompanyContext(company_id="iso-kunde", certifications=[Certification(certification_id="ISO27001")]), _iso_map)
+# „required": likely_covered + delta -> TargetRequirements (here read from the pattern)
+_reqs = [TargetRequirement(capability_id=a["capability"], question_intent="verify_existence",
+                           expected_evidence=a.get("expected_evidence", [])) for a in PAT["likely_covered"]]
+_reqs += [TargetRequirement(capability_id=d["capability"], question_intent=d.get("needed_information", "verify_existence"),
+                            expected_evidence=d.get("expected_evidence", [])) for d in PAT["delta_requirements"]]
+_tc = TransitionContext(company_id="iso-kunde", known_certifications=["ISO27001"],
+                        target=TransitionGoal(target_id="CRA", target_type=TargetType.REGULATION,
+                                              label=PAT["transition_goal"]["to"]["regulation"]))
+_a = assess_transition(_tc, _reqs, _profile)
+w("**Input:** ISO27001-zertifiziert (Pattern TP-ISO27001-CRA-v1) → %d ISMS-Capabilities inferred; Ziel CRA." % len(_iso_caps))
+w("")
+w("**Expected Transition Assessment (RS-005 v0 gegen den Pattern):**")
+w("> Ziel %s · %s" % (_a.target_id, _a.summary.headline))
+w("")
+w("**Delta zuerst (HIGH — fehlt einem ISO-27001-only-Hersteller):**")
+for _r in _a.question_requests:
+    if _r.priority.value == "high":
+        w("- `%s` — intent=%s, Nachweis=%s" % (_r.capability_id, _r.question_intent, _r.expected_evidence))
+w("")
+w("**Aus ISO27001 vermutlich abgedeckt (Produkt-Nachweis bestätigen):** %s" % ", ".join(_a.summary.probably_covered))
+w("")
+_carried = len(_a.coverage) == len(_reqs) and len(_a.question_requests) > 0
+_n_high = sum(1 for _r in _a.question_requests if _r.priority.value == "high")
+w("**Architektur-Test — trägt RS-005 den Pattern vollständig?** %d Pattern-Capabilities → %d Coverage + %d Question-Requests → **%s**."
+  % (len(_reqs), len(_a.coverage), len(_a.question_requests), "ja, vollständig getragen" if _carried else "NICHT vollständig"))
+w("")
+coverage_table([
+    ("Pattern-Load (YAML)", "PASS", "TP-ISO27001-CRA-v1 (draft, gold-standard)"),
+    ("Company 2A (habe)", "PASS", "ISO27001 → %d inferred caps" % len(_a.summary.probably_covered)),
+    ("RS-005 Planning Engine", "PASS" if _carried else "PARTIAL", "Pattern → TransitionQuestionRequests"),
+    ("Transition ISO27001→CRA", "PASS" if _carried else "PARTIAL",
+     "%d Delta-Fragen (HIGH) + %d zu bestätigen" % (_n_high, len(_a.summary.probably_covered))),
+    ("RS-005.1 Renderer (Fragetext)", "TODO", "verschoben — Engine liefert nur Requests"),
+])
+
 # ── Epics + roll-up ───────────────────────────────────────────────────────
 w("## Gaps → Epics (Backlog — nur erfasst, NICHT implementiert)")
 w("")

backend-compliance/reference_scenarios/reference_scenario_suite_v1.md

@@ -145,6 +145,40 @@ _ILLUSTRATIVES Mapping: ISO27001 -> incident_response, supplier_management, asse
 | Master Capability Registry | **PASS** | computed confidence, policy-versioniert |
 | cap ↔ MCAP Linking | **TODO** | zwei Vokabulare unverbunden → RS-003 |
 
+## Szenario 4 — Transition ISO27001 → CRA (RS-005 + Pattern TP-ISO27001-CRA-v1)
+
+_Frage: „Ich bin ISO27001-zertifiziert — was fehlt mir für den CRA?"_
+
+**Input:** ISO27001-zertifiziert (Pattern TP-ISO27001-CRA-v1) → 8 ISMS-Capabilities inferred; Ziel CRA.
+
+**Expected Transition Assessment (RS-005 v0 gegen den Pattern):**
+> Ziel CRA · 17 zu klären, 0 bereits abgedeckt, 8 vermutlich vorhanden, 9 fehlt, 0 n/a, 0 nicht im Korpus.
+
+**Delta zuerst (HIGH — fehlt einem ISO-27001-only-Hersteller):**
+- `ce_conformity_assessment_and_technical_documentation` — intent=request_evidence, Nachweis=['technical_documentation', 'declaration_of_conformity']
+- `coordinated_vulnerability_disclosure` — intent=verify_existence, Nachweis=['cvd_policy']
+- `exploited_vuln_and_incident_reporting` — intent=verify_existence, Nachweis=['reporting_procedure']
+- `product_cyber_risk_assessment` — intent=verify_existence, Nachweis=['product_risk_assessment']
+- `public_security_advisories` — intent=verify_existence, Nachweis=['advisory_process']
+- `sbom_creation` — intent=determine_sbom_maturity, Nachweis=['sbom']
+- `secure_by_default_no_default_credentials` — intent=verify_existence, Nachweis=['config_export', 'test_report']
+- `secure_signed_update_distribution` — intent=verify_existence, Nachweis=['config_export', 'test_report']
+- `security_update_support_period` — intent=determine_duration, Nachweis=['support_policy', 'product_lifecycle_policy']
+
+**Aus ISO27001 vermutlich abgedeckt (Produkt-Nachweis bestätigen):** incident_management, technical_vulnerability_management, supplier_security, access_control_and_authentication, cryptography, security_logging_and_monitoring, secure_development_lifecycle, asset_and_configuration_management
+
+**Architektur-Test — trägt RS-005 den Pattern vollständig?** 17 Pattern-Capabilities → 17 Coverage + 17 Question-Requests → **ja, vollständig getragen**.
+
+**Architecture Coverage**
+
+| Layer | Status | Hinweis |
+|---|---|---|
+| Pattern-Load (YAML) | **PASS** | TP-ISO27001-CRA-v1 (draft, gold-standard) |
+| Company 2A (habe) | **PASS** | ISO27001 → 8 inferred caps |
+| RS-005 Planning Engine | **PASS** | Pattern → TransitionQuestionRequests |
+| Transition ISO27001→CRA | **PASS** | 9 Delta-Fragen (HIGH) + 8 zu bestätigen |
+| RS-005.1 Renderer (Fragetext) | **TODO** | verschoben — Engine liefert nur Requests |
+
 ## Gaps → Epics (Backlog — nur erfasst, NICHT implementiert)
 
 | Epic | Titel | schliesst Coverage-Luecke |
@@ -156,6 +190,6 @@ _ILLUSTRATIVES Mapping: ISO27001 -> incident_response, supplier_management, asse
 
 ## Suite-Status (Roll-up)
 
-- Coverage-Zellen gesamt: **20**
+- Coverage-Zellen gesamt: **25**
-- PASS: **13** · PARTIAL: 3 · UNSUPPORTED: 1 · TODO: 2 · N/A: 1 · NEEDS_FACTS: 0
+- PASS: **17** · PARTIAL: 3 · UNSUPPORTED: 1 · TODO: 3 · N/A: 1 · NEEDS_FACTS: 0
 - Fortschritt = PASS-Anteil steigt, wenn Epics RS-001…004 landen (objektiver Maßstab, kein LOC).