feat: Medical stress test (safety+security coupled) + Missing Convergence report (Phase Ω #3)

Medical before Payment: the harder scientific test (safety AND security coupled, full lifecycle,
deep risk/evidence demands). ISO 13485 runs through the SAME engine as ISO 27001 -> CRA, only new
data, 0 runtime. The key result: IEC 81001-5-1 (health-software security) pulls in the SAME security
MCAPs as the CRA, so Medical REUSES cyber capabilities (the safety/security coupling appears as
capability reuse) while adding 7 genuinely new medical caps (clinical evaluation, software safety
classification, ISO 14971 risk file, benefit-risk). rejected_assumptions intact.

Effect on the convergence core: secure_signed_update_distribution 18 -> 24 and
technical_vulnerability_management 17 -> 23, now spanning 3 domains (cyber + industrial + medical) —
the core visibly GROWS, exactly the convergence signal.

New 5th report: MISSING CONVERGENCE — deterministic (no ML) token-cluster detector for potential
structural duplications: a name token shared by >=3 MCAPs across >=2 distinct sources is flagged for
EXPERT REVIEW (never auto-merged). Surfaces e.g. the `risk` cluster (6 risk MCAPs across 6 sources)
and `security`/`software`; single-source decompositions are filtered out. Complements Suspicious by
looking at cross-source duplication, not single MCAPs.

Also records the durable modelling rule extracted from the frequency fix: evidence is attributed to
its ORIGIN; its value against a target is computed later (relevance(evidence,target)). Ledger now 8
sources, Architecture Stability 8/8 = 100%. Non-runtime -> no deploy. 29 tests pass, check-loc 0.

backend-compliance/knowledge/architecture_stability/integration_ledger.yaml

@@ -86,6 +86,16 @@ sources:
     integration_kind: data_only
     family: cyber               # convergence test: same capability fed by many sources, model stayed stable
     exercised_by: "automotive_convergence_stress_test"
+  - source: "ISO 13485 -> Medical device (MDR / IEC 62304 / ISO 14971 / IEC 81001-5-1)"
+    domain: medical
+    target_type: regulation
+    integrated_as: transition_pattern_data
+    new_runtime_classes: 0
+    new_pipeline: false
+    new_capability_types: 7     # of 11 delta caps, 4 REUSE cyber MCAPs (IEC 81001-5-1 = CRA security coupling)
+    integration_kind: data_only
+    family: non_cyber           # safety/clinical domain WITH a security coupling — the harder joint test
+    exercised_by: "medical_stress_test"
 
 # --- One-time, domain-AGNOSTIC pipeline functions (built once, now FROZEN per Phase Ω). ---
 # Listed for honesty so the stability KPI cannot be gamed: these are NOT per-domain costs. The last

backend-compliance/knowledge/transition_patterns/transition_pattern_iso13485_to_medical_v1.yaml

@@ -0,0 +1,82 @@
+# Transition KNOWLEDGE Pattern (TKP) — ISO 13485 (Medical QMS)  ->  Medical device compliance
+# The HARDER scientific test (Phase Ω, test #3). Medical brings, at once, properties not yet jointly
+# tested: safety and security TIGHTLY COUPLED, a full product lifecycle, very strong risk-management +
+# evidence demands, and high regulatory depth. Sources: MDR, IEC 62304 (software lifecycle),
+# ISO 14971 (risk management), IEC 81001-5-1 (health-software security).
+#
+# KEY for the convergence analysis: IEC 81001-5-1 (health-software security) REQUIRES the same security
+# capabilities the CRA does (secure update, vulnerability management, access control, SBOM). So Medical
+# REUSES the cyber MCAPs — the safety/security coupling shows up as capability reuse, growing the core
+# into a 3rd domain. Alongside that, Medical adds genuinely new caps (clinical evaluation, software
+# safety classification, the ISO 14971 risk file, benefit-risk). Capabilities are VERBS. Expert L1 draft.
+
+id: TP-ISO13485-MEDICAL-v1
+status: draft
+version: 1
+
+transition_goal:
+  from:
+    standard: "ISO 13485"
+    edition: "2016"
+    nature: organizational_medical_qms
+  to:
+    domain: "Medical device compliance (software-containing device)"
+    nature: product_safety_and_security
+    sources: ["MDR", "IEC_62304", "ISO_14971", "IEC_81001_5_1"]
+  one_line: "Move a manufacturer whose management system is ISO 13485 toward placing a software-containing medical device on the EU market."
+
+provenance:
+  author: "Claude (Reasoning session) — AI first draft (L1)"
+  basis: "ISO 13485:2016 (4.2 documentation, 7.3 design, 7.1/risk, 8.2.1 feedback/PMS, 8.5 CAPA) vs MDR + IEC 62304 + ISO 14971 + IEC 81001-5-1."
+  reviewed_by: null
+  validated_by: null
+
+disclaimer: >
+  Curated expert knowledge, NOT a normative proof. KEY INSIGHT: ISO 13485 is a medical QUALITY
+  management system — it gives QMS + design-control + risk-process + PMS discipline, but not the
+  concrete clinical, software-lifecycle, risk-file or product-security EVIDENCE. Safety and security
+  are coupled: IEC 81001-5-1 pulls in the SAME security capabilities the CRA requires. Welt-1.
+
+source_state_variants:
+  certified:       "ISO 13485 certified -> QMS/design/risk-process assumptions hold; concrete evidence still missing."
+  qms_introduced:  "QMS implemented but not certified -> downgrade 'partially_supports' to needs_confirmation."
+
+# ── A) LIKELY COVERED — medical QMS management discipline (partially_supports), NOT evidence. ──
+likely_covered:
+  - {capability: manage_document_control, iso13485_basis: "4.2", relationship: partially_supports, confidence_source: relationship, verification: required, expected_evidence: [document_control_procedure], rationale: "ISO 13485 document control maintains records but creates no clinical/safety content.", reviewable_claim: "Document control maintains, not creates, medical evidence."}
+  - {capability: operate_capa_process, iso13485_basis: "8.5", relationship: partially_supports, confidence_source: relationship, verification: required, expected_evidence: [capa_procedure], rationale: "CAPA gives corrective/preventive discipline, not product safety evidence.", reviewable_claim: "CAPA does not establish device safety."}
+  - {capability: conduct_design_controls, iso13485_basis: "7.3", relationship: partially_supports, confidence_source: relationship, verification: required, expected_evidence: [design_history_file], rationale: "Design controls structure development but do not by themselves produce IEC 62304 software-lifecycle records.", reviewable_claim: "Design controls do not produce the IEC 62304 lifecycle records."}
+  - {capability: run_risk_management_process, iso13485_basis: "7.1", relationship: partially_supports, confidence_source: relationship, verification: required, expected_evidence: [risk_management_procedure], rationale: "ISO 13485 requires a risk-management PROCESS, but the ISO 14971 risk FILE with concrete analyses is separate.", reviewable_claim: "A risk-management process is not a completed ISO 14971 risk file."}
+  - {capability: control_suppliers_medical, iso13485_basis: "7.4", relationship: partially_supports, confidence_source: relationship, verification: required, expected_evidence: [supplier_controls], rationale: "Supplier controls give purchasing discipline, not component security.", reviewable_claim: "Medical supplier control does not establish component security."}
+  - {capability: operate_post_market_surveillance, iso13485_basis: "8.2.1", relationship: partially_supports, confidence_source: relationship, verification: required, expected_evidence: [pms_procedure], rationale: "Feedback/PMS process exists, but MDR PMS + vigilance reporting evidence is separate.", reviewable_claim: "A feedback process is not MDR post-market surveillance evidence."}
+
+# ── B) DELTA — concrete medical evidence + (coupled) product security. ──
+delta_requirements:
+  # B1) safety/security COUPLING — IEC 81001-5-1 reuses the SAME cyber MCAPs as the CRA:
+  - {capability: secure_signed_update_distribution, missing_because: "QMS has no secure update.", why_asked: "IEC 81001-5-1 requires authenticity/integrity-protected health-software updates (= CRA).", dropped_if: ["Updates are signed and verified."], needed_information: verify_existence, covers_targets: [IEC_81001_5_1, MDR], expected_evidence: [config_export], priority: high, reviewable_claim: "ISO 13485 does not establish signed update distribution."}
+  - {capability: technical_vulnerability_management, missing_because: "QMS has no vulnerability management.", why_asked: "IEC 81001-5-1 requires handling health-software vulnerabilities (= CRA).", dropped_if: ["A vulnerability management process exists."], needed_information: verify_existence, covers_targets: [IEC_81001_5_1, MDR], expected_evidence: [vulnerability_management_procedure], priority: high, reviewable_claim: "ISO 13485 does not establish vulnerability management."}
+  - {capability: access_control_and_authentication, missing_because: "QMS has no product access control.", why_asked: "IEC 81001-5-1 requires authentication/access control for health software (= CRA).", dropped_if: ["Authentication is documented + tested."], needed_information: verify_existence, covers_targets: [IEC_81001_5_1], expected_evidence: [access_control_policy], priority: medium, reviewable_claim: "ISO 13485 does not establish product authentication."}
+  - {capability: sbom_creation, missing_because: "QMS produces no SBOM.", why_asked: "IEC 81001-5-1 expects a software bill of materials (= CRA).", dropped_if: ["A machine-readable SBOM is produced per release."], needed_information: determine_sbom_maturity, covers_targets: [IEC_81001_5_1], expected_evidence: [sbom], priority: high, reviewable_claim: "ISO 13485 does not produce an SBOM."}
+  # B2) genuinely NEW medical-specific evidence:
+  - {capability: conduct_clinical_evaluation, missing_because: "QMS produces no clinical evidence.", why_asked: "The MDR requires a clinical evaluation / clinical evidence.", dropped_if: ["A clinical evaluation report exists."], needed_information: request_evidence, covers_targets: [MDR], expected_evidence: [clinical_evaluation_report], priority: high, reviewable_claim: "ISO 13485 does not produce clinical evidence."}
+  - {capability: classify_software_safety_iec62304, missing_because: "QMS does not classify software safety.", why_asked: "IEC 62304 requires a software safety classification (Class A/B/C) driving the lifecycle.", dropped_if: ["A software safety classification exists."], needed_information: request_evidence, covers_targets: [IEC_62304], expected_evidence: [software_safety_classification], priority: high, reviewable_claim: "ISO 13485 does not classify software safety per IEC 62304."}
+  - {capability: maintain_risk_management_file_iso14971, missing_because: "QMS has a process, not the file.", why_asked: "ISO 14971 requires a maintained risk management file with concrete analyses + controls.", dropped_if: ["An ISO 14971 risk management file exists."], needed_information: request_evidence, covers_targets: [ISO_14971, MDR], expected_evidence: [risk_management_file], priority: high, reviewable_claim: "An ISO 13485 risk process is not a completed ISO 14971 risk file."}
+  - {capability: perform_benefit_risk_analysis, missing_because: "QMS does not weigh benefit vs risk.", why_asked: "The MDR + ISO 14971 require a documented benefit-risk determination.", dropped_if: ["A benefit-risk analysis exists."], needed_information: request_evidence, covers_targets: [MDR, ISO_14971], expected_evidence: [benefit_risk_analysis], priority: medium, reviewable_claim: "ISO 13485 does not document a benefit-risk analysis."}
+  - {capability: implement_software_lifecycle_iec62304, missing_because: "QMS has design controls, not the IEC 62304 lifecycle.", why_asked: "IEC 62304 requires a defined software development + maintenance lifecycle.", dropped_if: ["IEC 62304 lifecycle records exist."], needed_information: request_evidence, covers_targets: [IEC_62304], expected_evidence: [software_lifecycle_records], priority: high, reviewable_claim: "ISO 13485 does not produce IEC 62304 lifecycle records."}
+  - {capability: assign_unique_device_identification, missing_because: "QMS has no UDI.", why_asked: "The MDR requires UDI assignment + registration.", dropped_if: ["UDI is assigned and registered."], needed_information: verify_existence, covers_targets: [MDR], expected_evidence: [udi_record], priority: medium, reviewable_claim: "ISO 13485 does not assign UDI."}
+  - {capability: compile_medical_technical_documentation, missing_because: "QMS has no MDR technical documentation.", why_asked: "The MDR (Annex II/III) requires complete technical documentation + DoC.", dropped_if: ["MDR technical documentation exists."], needed_information: request_evidence, covers_targets: [MDR], expected_evidence: [technical_documentation, declaration_of_conformity], priority: high, reviewable_claim: "ISO 13485 does not satisfy MDR technical documentation."}
+
+rejected_assumptions:
+  - "ISO 13485 does NOT produce clinical evidence or a clinical evaluation."
+  - "ISO 13485 does NOT produce the ISO 14971 risk management FILE (only the process)."
+  - "ISO 13485 does NOT produce IEC 62304 software-lifecycle records or a software safety classification."
+  - "ISO 13485 does NOT establish health-software security (IEC 81001-5-1 = the same security caps as the CRA)."
+
+determinism_goal: >
+  Two independent auditors should agree that an ISO-13485-only manufacturer has medical QMS discipline
+  but is missing the clinical, software-lifecycle, risk-file and product-security evidence — and that the
+  security part is the SAME capability set as the CRA (safety/security coupling).
+
+review_checklist:
+  - "Confirm delta + rejected_assumptions with a medical regulatory expert."
+  - "Replace capability ids with Capability Registry MCAP ids once assigned."