From f78e03bd0aea44c37f0c4009c43dfdd338272444 Mon Sep 17 00:00:00 2001 From: Benjamin Admin Date: Sat, 27 Jun 2026 08:46:20 +0200 Subject: [PATCH] docs(knowledge): Reference Transition Scenarios (RTS-001..003) + ISO9001->CRA pattern Three ANONYMIZED reference transition scenarios (no real company names stored) = canonical regression scenarios that test the KNOWLEDGE, not just the engine. Each pins an Expected Outcome (expected_likely_covered + expected_delta); every commit must reproduce it (identical or better). - RTS-001 automotive supplier (TISAX+ISO27001) -> CRA: mature ISMS, standard CRA delta. - RTS-002 classic machine builder (ISO9001) -> CRA: only process discipline -> MUCH larger delta (10 missing vs 3 covered). New TP-ISO9001-CRA-v1 pattern (different shape). - RTS-003 networked machine builder (ISMS) -> CRA: highlights the Data Act. Data Act is modelled as UNCERTAIN (a hypothesis), never a fixed gilt/gilt-nicht: the generator checks the engine SURFACES the uncertainty + the deciding question (generates_usage_data) and never wrongly ASSERTS applicability. All three RTS PASS. Non-runtime knowledge + reference harness -> no deploy (ADR-001). Names deliberately absent. Co-Authored-By: Claude Opus 4.7 --- .../RTS-001.yaml | 53 +++++++++++ .../RTS-002.yaml | 50 ++++++++++ .../RTS-003.yaml | 54 +++++++++++ .../transition_pattern_iso9001_to_cra_v1.yaml | 95 +++++++++++++++++++ .../reference_scenarios/generate.py | 59 +++++++++++- .../reference_scenario_suite_v1.md | 41 +++++++- 6 files changed, 349 insertions(+), 3 deletions(-) create mode 100644 backend-compliance/knowledge/reference_transition_scenarios/RTS-001.yaml create mode 100644 backend-compliance/knowledge/reference_transition_scenarios/RTS-002.yaml create mode 100644 backend-compliance/knowledge/reference_transition_scenarios/RTS-003.yaml create mode 100644 backend-compliance/knowledge/transition_patterns/transition_pattern_iso9001_to_cra_v1.yaml diff --git a/backend-compliance/knowledge/reference_transition_scenarios/RTS-001.yaml b/backend-compliance/knowledge/reference_transition_scenarios/RTS-001.yaml new file mode 100644 index 00000000..ee8d1cca --- /dev/null +++ b/backend-compliance/knowledge/reference_transition_scenarios/RTS-001.yaml @@ -0,0 +1,53 @@ +# Reference Transition Scenario — canonical regression scenario (NOT a test fixture). +# ANONYMIZED ARCHETYPE ONLY — no real company names are stored in the system; illustrative. +# Each RTS pins an Expected Outcome so every commit must reproduce it (identical or better). + +id: RTS-001 +archetype: "Automotive supplier with a mature ISMS — embedded electronics + software, CE products, OEM supply chain" +note: "Anonymized typical starting situation; illustrative only." + +reference_company: + sector: automotive_supply + known_certifications: [TISAX, ISO27001] + product_traits: + is_machine: false # component / embedded supplier + is_component: true + has_embedded_software: true + connected_to_internet: true + has_remote_access: true + generates_usage_data: null # UNKNOWN -> a deciding question, not an assertion + market: [EU] + +transition_goal: + from: [TISAX, ISO27001] + to: + - target: CRA + pattern: TP-ISO27001-CRA-v1 # executed through RS-005 below + - target: MaschinenVO + pattern: null + note: pattern_pending # no MaschinenVO pattern yet + +expected_outcome: + cra: + pattern: TP-ISO27001-CRA-v1 + # The mature ISMS reduces effort here (most info-security capabilities probably covered). + expected_likely_covered_at_least: + - incident_management + - supplier_security + - secure_development_lifecycle + - asset_and_configuration_management + - security_logging_and_monitoring + - access_control_and_authentication + # ... but the CRA product-cyber delta remains. + expected_delta_at_least: + - sbom_creation + - coordinated_vulnerability_disclosure + - security_update_support_period + - secure_signed_update_distribution + - exploited_vuln_and_incident_reporting + - product_cyber_risk_assessment + - ce_conformity_assessment_and_technical_documentation + data_act: + expectation: uncertain # NEVER a fixed gilt/gilt-nicht + deciding_questions: [generates_usage_data, connected_product, data_act_scope] + rationale: "A connected component MAY fall under the Data Act; applicability depends on usage-data generation + scope. The engine must SURFACE this uncertainty and ask, not assert." diff --git a/backend-compliance/knowledge/reference_transition_scenarios/RTS-002.yaml b/backend-compliance/knowledge/reference_transition_scenarios/RTS-002.yaml new file mode 100644 index 00000000..d1736019 --- /dev/null +++ b/backend-compliance/knowledge/reference_transition_scenarios/RTS-002.yaml @@ -0,0 +1,50 @@ +# Reference Transition Scenario — ANONYMIZED ARCHETYPE ONLY (no real company names stored). +id: RTS-002 +archetype: "Classic machine builder with only a QMS — precision systems, CE products, no ISMS" +note: "Anonymized typical starting situation; illustrative only. Contrast to RTS-001: a much LARGER delta." + +reference_company: + sector: mechanical_engineering + known_certifications: [ISO9001] + product_traits: + is_machine: true + is_component: false + has_embedded_software: true + connected_to_internet: false # often not connected -> Data Act less likely, still a question + has_remote_access: null + generates_usage_data: null + market: [EU] + +transition_goal: + from: [ISO9001] + to: + - target: CRA + pattern: TP-ISO9001-CRA-v1 + - target: MaschinenVO + pattern: null + note: pattern_pending + +expected_outcome: + cra: + pattern: TP-ISO9001-CRA-v1 + # A QMS gives only process discipline... + expected_likely_covered_at_least: + - document_and_change_control + - supplier_evaluation + - release_and_approval_process + # ...so the CRA delta is LARGE — nearly the whole security set. + expected_delta_at_least: + - product_cyber_risk_assessment + - secure_development_lifecycle + - technical_vulnerability_management + - coordinated_vulnerability_disclosure + - sbom_creation + - security_update_support_period + - secure_signed_update_distribution + - exploited_vuln_and_incident_reporting + - ce_conformity_assessment_and_technical_documentation + expected_delta_much_larger_than: RTS-001 # regression: ISO9001 leaves more open than ISO27001 + data_act: + expectation: uncertain + deciding_questions: [connected_product, generates_usage_data, data_act_scope] + rationale: "Often not a connected product, but applicability is not assumed either way — the engine must ask." diff --git a/backend-compliance/knowledge/reference_transition_scenarios/RTS-003.yaml b/backend-compliance/knowledge/reference_transition_scenarios/RTS-003.yaml new file mode 100644 index 00000000..629eb578 --- /dev/null +++ b/backend-compliance/knowledge/reference_transition_scenarios/RTS-003.yaml @@ -0,0 +1,54 @@ +# Reference Transition Scenario — ANONYMIZED ARCHETYPE ONLY (no real company names stored). +id: RTS-003 +archetype: "Machine builder with an ISMS and networked products — connected machines that may generate usage data" +note: "Anonymized typical starting situation; illustrative only. Highlights the Data-Act uncertainty." + +reference_company: + sector: mechanical_engineering + known_certifications: [ISO27001] # ISMS ~ ISO 27001 + product_traits: + is_machine: true + is_component: false + has_embedded_software: true + connected_to_internet: true + has_remote_access: true + generates_usage_data: null # UNKNOWN -> the Data-Act deciding question + market: [EU] + +transition_goal: + from: [ISO27001] + to: + - target: CRA + pattern: TP-ISO27001-CRA-v1 + - target: MaschinenVO + pattern: null + note: pattern_pending + - target: DataAct + pattern: null + note: uncertain_hypothesis # NOT asserted — see expected_outcome.data_act + +expected_outcome: + cra: + pattern: TP-ISO27001-CRA-v1 + expected_likely_covered_at_least: + - incident_management + - technical_vulnerability_management + - secure_development_lifecycle + - access_control_and_authentication + - security_logging_and_monitoring + expected_delta_at_least: + - sbom_creation + - coordinated_vulnerability_disclosure + - security_update_support_period + - secure_signed_update_distribution + - exploited_vuln_and_incident_reporting + - product_cyber_risk_assessment + - ce_conformity_assessment_and_technical_documentation + data_act: + expectation: uncertain # the core correction: a connected machine MAY fall under the Data Act + deciding_questions: [generates_usage_data, connected_product, data_act_scope] + rationale: > + A networked machine is MORE likely to fall under the Data Act than a pure component, but it is NOT + a settled fact — it depends on usage-data generation, user access, and scope. The Reference Suite + checks that the engine recognises the RIGHT uncertainty and asks the deciding question, NOT that it + writes a fixed gilt/gilt-nicht. diff --git a/backend-compliance/knowledge/transition_patterns/transition_pattern_iso9001_to_cra_v1.yaml b/backend-compliance/knowledge/transition_patterns/transition_pattern_iso9001_to_cra_v1.yaml new file mode 100644 index 00000000..75205806 --- /dev/null +++ b/backend-compliance/knowledge/transition_patterns/transition_pattern_iso9001_to_cra_v1.yaml @@ -0,0 +1,95 @@ +# Transition KNOWLEDGE Pattern (TKP) — ISO 9001 (QMS) -> CRA (Reg. (EU) 2024/2847) +# Curated regulatory KNOWLEDGE. Different character again: ISO 9001 gives PROCESS discipline +# (document/change control, supplier evaluation, release approval) but almost NOTHING product-cyber. +# Therefore the CRA delta is LARGE — the opposite shape of ISMS->TISAX. Used by RTS-002. + +id: TP-ISO9001-CRA-v1 +status: draft # levels: draft(L1) -> reviewed(L2) -> validated(L3, expert) -> proven(L4) +version: 1 + +transition_goal: + from: + standard: "ISO 9001" + edition: "2015" + nature: organizational_qms + to: + regulation: "Cyber Resilience Act" + reference: "Regulation (EU) 2024/2847" + applies_from: "2027-12-11" + nature: product_cybersecurity + one_line: "Move a manufacturer whose only management system is a QMS toward CRA conformity for a product with digital elements." + +provenance: + author: "Claude (Reasoning session) — AI first draft (L1)" + basis: "ISO 9001:2015 (7.5 documented information, 8.4 external providers, 8.5.6 control of changes, 8.6 release) vs CRA Annex I." + reviewed_by: null + reviewed_at: null + validated_by: null + +disclaimer: > + Curated expert knowledge, NOT a normative proof. KEY INSIGHT: ISO 9001 is a QUALITY management + system — it provides process discipline but no information-security or product-cybersecurity + capability. The CRA delta for an ISO-9001-only manufacturer is therefore LARGE (nearly the whole + CRA security + vulnerability-handling + conformity set). Welt-1; confidence from the curated relationship. + +source_state_variants: + certified: "ISO 9001 certified -> the process-discipline assumptions hold; security substance is still missing." + qms_introduced: "QMS implemented but not certified -> downgrade 'partially_supports' to needs_confirmation." + +# ── A) LIKELY COVERED — only process discipline (partially_supports), NOT security. ── +likely_covered: + - capability: document_and_change_control + iso9001_basis: ["7.5", "8.5.6"] + cra_target: [Annex_VII_technical_documentation, Annex_I_Part_II_2_updates] + relationship: partially_supports + confidence_source: relationship + verification: required + expected_evidence: [document_control_procedure] + rationale: "ISO 9001 document/change control gives the discipline to MAINTAIN technical documentation and controlled updates — but no security content. Hence 'partially_supports'." + reviewable_claim: "Document/change control helps maintain CRA technical documentation but does not produce it." + + - capability: supplier_evaluation + iso9001_basis: ["8.4"] + cra_target: [Annex_I_Part_II_1_components] + relationship: partially_supports + confidence_source: relationship + verification: required + expected_evidence: [supplier_evaluation_records] + rationale: "Supplier evaluation gives a basis for supply-chain control — but ISO 9001 evaluates QUALITY, not security/components. Hence 'partially_supports'." + reviewable_claim: "Quality supplier evaluation does not establish component security or an SBOM." + + - capability: release_and_approval_process + iso9001_basis: ["8.6"] + cra_target: [Annex_I_Part_II_8_distribution] + relationship: partially_supports + confidence_source: relationship + verification: required + expected_evidence: [release_procedure] + rationale: "A release/approval gate gives release discipline — but not secure, signed update distribution. Hence 'partially_supports'." + reviewable_claim: "A quality release gate does not establish signed secure update distribution." + +# ── B) DELTA — nearly the whole CRA security + vulnerability-handling + conformity set. ── +delta_requirements: + - {capability: product_cyber_risk_assessment, cra_basis: "Annex I + technical documentation", missing_because: "ISO 9001 has no security risk assessment.", why_asked: "The CRA needs a product cyber risk assessment; a QMS has none.", dropped_if: ["A product cyber risk assessment exists."], needed_information: verify_existence, expected_evidence: [product_risk_assessment], priority: high, reviewable_claim: "ISO 9001 establishes no product cyber risk assessment."} + - {capability: secure_development_lifecycle, cra_basis: "Annex I Part I (1), Part II (3)", missing_because: "ISO 9001 has no secure development.", why_asked: "The CRA requires secure-by-design development + security testing; a QMS does not address security.", dropped_if: ["A documented secure development lifecycle exists."], needed_information: verify_existence, expected_evidence: [secure_development_policy], priority: high, reviewable_claim: "ISO 9001 does not establish a secure development lifecycle."} + - {capability: technical_vulnerability_management, cra_basis: "Annex I Part II (2)", missing_because: "ISO 9001 has no vulnerability management.", why_asked: "The CRA requires handling product vulnerabilities; a QMS has no such process.", dropped_if: ["A vulnerability management process exists."], needed_information: verify_existence, expected_evidence: [vulnerability_management_procedure], priority: high, reviewable_claim: "ISO 9001 does not establish vulnerability management."} + - {capability: coordinated_vulnerability_disclosure, cra_basis: "Annex I Part II (5,6)", missing_because: "No CVD in a QMS.", why_asked: "The CRA requires a way to receive product vulnerability reports (CVD/PSIRT).", dropped_if: ["A published CVD policy + contact exists."], needed_information: verify_existence, expected_evidence: [cvd_policy], priority: high, reviewable_claim: "ISO 9001 does not establish coordinated vulnerability disclosure."} + - {capability: sbom_creation, cra_basis: "Annex I Part II (1)", missing_because: "No SBOM in a QMS.", why_asked: "The CRA requires a software bill of materials.", dropped_if: ["A machine-readable SBOM is produced per release."], needed_information: determine_sbom_maturity, expected_evidence: [sbom], priority: high, reviewable_claim: "ISO 9001 does not produce an SBOM."} + - {capability: security_update_support_period, cra_basis: "Art. 13(8) + Annex I", missing_because: "No support period in a QMS.", why_asked: "The CRA requires a defined security-update support period.", dropped_if: ["A product support/lifecycle policy defines the period."], needed_information: determine_duration, expected_evidence: [support_policy], priority: high, reviewable_claim: "ISO 9001 does not define a security-update support period."} + - {capability: secure_signed_update_distribution, cra_basis: "Annex I Part II (8)", missing_because: "No signed updates in a QMS.", why_asked: "The CRA requires authenticity/integrity-protected updates.", dropped_if: ["Updates are cryptographically signed and verified."], needed_information: verify_existence, expected_evidence: [config_export], priority: high, reviewable_claim: "ISO 9001 does not establish signed update distribution."} + - {capability: exploited_vuln_and_incident_reporting, cra_basis: "Art. 14", missing_because: "No Art. 14 reporting in a QMS.", why_asked: "The CRA imposes 24h/72h reporting of exploited vulnerabilities to authorities.", dropped_if: ["A documented Art. 14 reporting procedure exists."], needed_information: verify_existence, expected_evidence: [reporting_procedure], priority: high, reviewable_claim: "ISO 9001 does not establish CRA Art. 14 reporting."} + - {capability: access_control_and_authentication, cra_basis: "Annex I Part I (4)", missing_because: "No security access control in a QMS.", why_asked: "The CRA requires product authentication / no default credentials.", dropped_if: ["Product authentication is documented + tested."], needed_information: verify_existence, expected_evidence: [access_control_policy], priority: medium, reviewable_claim: "ISO 9001 does not establish product authentication."} + - {capability: ce_conformity_assessment_and_technical_documentation, cra_basis: "Annex VII + CE", missing_because: "No CRA conformity in a QMS.", why_asked: "CRA conformity needs a product conformity assessment + CE + technical documentation + DoC.", dropped_if: ["A CRA conformity assessment + technical documentation exist."], needed_information: request_evidence, expected_evidence: [technical_documentation, declaration_of_conformity], priority: high, reviewable_claim: "ISO 9001 does not satisfy CRA conformity assessment."} + +rejected_assumptions: + - "ISO 9001 does NOT establish information security or product cybersecurity." + - "ISO 9001 does NOT establish secure development, vulnerability management, SBOM, CVD, or Art. 14 reporting." + - "An ISO 9001 certificate does NOT satisfy CRA conformity assessment." + +determinism_goal: > + Two independent auditors should agree that an ISO-9001-only manufacturer needs almost the whole CRA + security set; the QMS reduces effort only on documentation/change/release discipline. + +review_checklist: + - "Confirm the (deliberately large) delta with a CRA expert." + - "Replace capability ids with Capability Registry MCAP ids once assigned." diff --git a/backend-compliance/reference_scenarios/generate.py b/backend-compliance/reference_scenarios/generate.py index 4cb305fc..bce39754 100644 --- a/backend-compliance/reference_scenarios/generate.py +++ b/backend-compliance/reference_scenarios/generate.py @@ -35,7 +35,7 @@ from compliance.capability import ( ) from compliance.reasoning.enums import Confidence from compliance.transition_reasoning import ( - TransitionContext, TransitionGoal, TargetType, TargetRequirement, assess_transition, + TransitionContext, TransitionGoal, TargetType, TargetRequirement, assess_transition, CoverageStatus, ) import os import yaml @@ -279,6 +279,63 @@ for _pf in _pat_files: _t_rows.append(("RS-005.1 Renderer (Fragetext)", "TODO", "verschoben — Engine liefert nur Requests")) coverage_table(_t_rows) +# ── Reference Transition Scenarios (RTS) — canonical regression (Soll/Ist + knowledge) ─── +w("## Reference Transition Scenarios (RTS) — kanonische Regression (Soll/Ist)") +w("") +w('_Anonymisierte Archetypen (KEINE Firmennamen). Jeder RTS pinnt ein Expected Outcome; jeder Commit muss es reproduzieren (identisch oder besser). Data Act = `uncertain`, nie fix „gilt/gilt-nicht"._') +w("") +_rts_dir = os.path.join(os.path.dirname(__file__), "..", "knowledge", "reference_transition_scenarios") +_pat_d2 = os.path.join(os.path.dirname(__file__), "..", "knowledge", "transition_patterns") +_pat_by_id = {} +for _pf in sorted(os.listdir(_pat_d2)): + if _pf.startswith("transition_pattern_") and _pf.endswith(".yaml"): + with open(os.path.join(_pat_d2, _pf), encoding="utf-8") as _h: + _pp = yaml.safe_load(_h) + _pat_by_id[_pp["id"]] = _pp +_rts_rows: List[Row] = [] +for _rf in sorted(f for f in os.listdir(_rts_dir) if f.startswith("RTS-") and f.endswith(".yaml")): + with open(os.path.join(_rts_dir, _rf), encoding="utf-8") as _f: + RTS = yaml.safe_load(_f) + _cra = RTS["expected_outcome"]["cra"] + _pat = _pat_by_id[_cra["pattern"]] + _src = RTS["reference_company"]["known_certifications"][0] + _have = [a["capability"] for a in _pat["likely_covered"]] + _map = {_src: CapabilityMappingEntry(capability_ids=_have, confidence=Confidence.MEDIUM)} + _profile = build_company_profile( + CompanyContext(company_id="rts", certifications=[Certification(certification_id=_src)]), _map) + _reqs = [TargetRequirement(capability_id=a["capability"]) for a in _pat["likely_covered"]] + _reqs += [TargetRequirement(capability_id=d["capability"], question_intent=d.get("needed_information", "verify_existence")) + for d in _pat["delta_requirements"]] + _a = assess_transition(TransitionContext(company_id="rts", target=TransitionGoal(target_id="CRA")), _reqs, _profile) + _actual_missing = {c.capability_id for c in _a.coverage if c.status == CoverageStatus.MISSING} + _exp_delta = set(_cra["expected_delta_at_least"]) + _exp_cov = set(_cra["expected_likely_covered_at_least"]) + _delta_ok = _exp_delta <= _actual_missing + _cov_ok = _exp_cov <= set(_a.summary.probably_covered) + # Data Act: the engine must SURFACE uncertainty, never ASSERT "applies". + _tr = RTS["reference_company"]["product_traits"] + _P = P(name="rts", product_type=PT.MACHINERY if _tr.get("is_machine") else PT.HARDWARE, + markets=_tr.get("market", ["EU"]), economic_operator_role=Role.MANUFACTURER, + lifecycle_phase=LP.PLACING_ON_MARKET, is_machine=_tr.get("is_machine"), + is_component=_tr.get("is_component"), has_embedded_software=_tr.get("has_embedded_software"), + connected_to_internet=_tr.get("connected_to_internet"), has_remote_access=_tr.get("has_remote_access"), + generates_usage_data=_tr.get("generates_usage_data")) + _rmap = render_regulatory_map(_P) + _appl = {v.regulation_id for v in _rmap.applicable_regulations} + _unc = {v.regulation_id for v in _rmap.uncertain_regulations} + _da = "applicable" if "DataAct" in _appl else ("uncertain" if "DataAct" in _unc else "excluded/absent") + _da_ok = "DataAct" not in _appl # never wrongly asserted as applicable + _ok = _delta_ok and _cov_ok and _da_ok + w("**%s** — %s" % (RTS["id"], RTS["archetype"])) + w("> Start %s → CRA. %s" % ("+".join(RTS["reference_company"]["known_certifications"]), _a.summary.headline)) + w("- Expected Delta erfüllt: **%s** (%d/%d Soll-Delta in der Ist-Lücke)" % ("ja" if _delta_ok else "NEIN", len(_exp_delta & _actual_missing), len(_exp_delta))) + w("- Expected likely_covered erfüllt: **%s**" % ("ja" if _cov_ok else "NEIN")) + w("- Data Act: Engine sagt **%s** (Soll: uncertain; nie asserted) → %s" % (_da, "ok" if _da_ok else "FEHLER (asserted!)")) + w("") + _rts_rows.append(("%s (%s→CRA)" % (RTS["id"], _src), "PASS" if _ok else "PARTIAL", + "%d/%d Delta-Soll · likely_covered %s · DataAct=%s" % (len(_exp_delta & _actual_missing), len(_exp_delta), "ok" if _cov_ok else "NEIN", _da))) +coverage_table(_rts_rows) + # ── Epics + roll-up ─────────────────────────────────────────────────────── w("## Gaps → Epics (Backlog — nur erfasst, NICHT implementiert)") w("") diff --git a/backend-compliance/reference_scenarios/reference_scenario_suite_v1.md b/backend-compliance/reference_scenarios/reference_scenario_suite_v1.md index 95102c0a..3dcfd6e3 100644 --- a/backend-compliance/reference_scenarios/reference_scenario_suite_v1.md +++ b/backend-compliance/reference_scenarios/reference_scenario_suite_v1.md @@ -161,14 +161,51 @@ _Genericity-Beweis: derselbe Algorithmus trägt jeden Transition Knowledge Patte - vermutlich abgedeckt: incident_management, technical_vulnerability_management, supplier_security, access_control_and_authentication, cryptography, security_logging_and_monitoring, secure_development_lifecycle, asset_and_configuration_management - Pattern getragen: **ja** (17 caps → 17 coverage + 17 requests) +**ISO 9001 → Cyber Resilience Act** _(TP-ISO9001-CRA-v1, status=draft)_ +> 13 zu klären, 0 bereits abgedeckt, 3 vermutlich vorhanden, 10 fehlt, 0 n/a, 0 nicht im Korpus. +- Delta zuerst (HIGH): access_control_and_authentication, ce_conformity_assessment_and_technical_documentation, coordinated_vulnerability_disclosure, exploited_vuln_and_incident_reporting, product_cyber_risk_assessment, sbom_creation, secure_development_lifecycle, secure_signed_update_distribution, security_update_support_period, technical_vulnerability_management +- vermutlich abgedeckt: document_and_change_control, supplier_evaluation, release_and_approval_process +- Pattern getragen: **ja** (13 caps → 13 coverage + 13 requests) + **Architecture Coverage** | Layer | Status | Hinweis | |---|---|---| | Transition ISOIEC27001→TISAX | **PASS** | draft · 5 HIGH-Delta + 8 zu bestätigen | | Transition ISOIEC27001→Cyber Resilience Act | **PASS** | reviewed · 9 HIGH-Delta + 8 zu bestätigen | +| Transition ISO9001→Cyber Resilience Act | **PASS** | draft · 10 HIGH-Delta + 3 zu bestätigen | | RS-005.1 Renderer (Fragetext) | **TODO** | verschoben — Engine liefert nur Requests | +## Reference Transition Scenarios (RTS) — kanonische Regression (Soll/Ist) + +_Anonymisierte Archetypen (KEINE Firmennamen). Jeder RTS pinnt ein Expected Outcome; jeder Commit muss es reproduzieren (identisch oder besser). Data Act = `uncertain`, nie fix „gilt/gilt-nicht"._ + +**RTS-001** — Automotive supplier with a mature ISMS — embedded electronics + software, CE products, OEM supply chain +> Start TISAX+ISO27001 → CRA. 17 zu klären, 0 bereits abgedeckt, 8 vermutlich vorhanden, 9 fehlt, 0 n/a, 0 nicht im Korpus. +- Expected Delta erfüllt: **ja** (7/7 Soll-Delta in der Ist-Lücke) +- Expected likely_covered erfüllt: **ja** +- Data Act: Engine sagt **uncertain** (Soll: uncertain; nie asserted) → ok + +**RTS-002** — Classic machine builder with only a QMS — precision systems, CE products, no ISMS +> Start ISO9001 → CRA. 13 zu klären, 0 bereits abgedeckt, 3 vermutlich vorhanden, 10 fehlt, 0 n/a, 0 nicht im Korpus. +- Expected Delta erfüllt: **ja** (9/9 Soll-Delta in der Ist-Lücke) +- Expected likely_covered erfüllt: **ja** +- Data Act: Engine sagt **uncertain** (Soll: uncertain; nie asserted) → ok + +**RTS-003** — Machine builder with an ISMS and networked products — connected machines that may generate usage data +> Start ISO27001 → CRA. 17 zu klären, 0 bereits abgedeckt, 8 vermutlich vorhanden, 9 fehlt, 0 n/a, 0 nicht im Korpus. +- Expected Delta erfüllt: **ja** (7/7 Soll-Delta in der Ist-Lücke) +- Expected likely_covered erfüllt: **ja** +- Data Act: Engine sagt **uncertain** (Soll: uncertain; nie asserted) → ok + +**Architecture Coverage** + +| Layer | Status | Hinweis | +|---|---|---| +| RTS-001 (TISAX→CRA) | **PASS** | 7/7 Delta-Soll · likely_covered ok · DataAct=uncertain | +| RTS-002 (ISO9001→CRA) | **PASS** | 9/9 Delta-Soll · likely_covered ok · DataAct=uncertain | +| RTS-003 (ISO27001→CRA) | **PASS** | 7/7 Delta-Soll · likely_covered ok · DataAct=uncertain | + ## Gaps → Epics (Backlog — nur erfasst, NICHT implementiert) | Epic | Titel | schliesst Coverage-Luecke | @@ -180,6 +217,6 @@ _Genericity-Beweis: derselbe Algorithmus trägt jeden Transition Knowledge Patte ## Suite-Status (Roll-up) -- Coverage-Zellen gesamt: **23** -- PASS: **15** · PARTIAL: 3 · UNSUPPORTED: 1 · TODO: 3 · N/A: 1 · NEEDS_FACTS: 0 +- Coverage-Zellen gesamt: **27** +- PASS: **19** · 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).