feat: Capability Convergence Explanation — why the registry converges + Core/Domain (Phase Ω)

The mature step after Medical is not the next domain but understanding WHY the registry converges.
Three derived views over existing data (no ML, no new architecture):
  1. Why converge? — a domain matrix per cross-domain MCAP + a curated REASON (the moat: not "MCAP-X
     exists" but "why MCAP-X must exist": software product / supply chain / product operation /
     universal process).
  2. Capability Families — ~75 MCAPs collapse to ~15 curated families (knowledge/capability_families/
     families.yaml), each with the reason it is universal or domain-specific.
  3. Core vs Domain — a COMPUTED property (not a new class): Core recurs across >=2 independent domains
     AND source types; Domain stays in one. Medical made it obvious (new medical caps are nearly all
     Domain; update/SBOM/access/logging are Core).

Non-runtime -> no deploy. 4 tests pass, check-loc 0.

backend-compliance/reference_scenarios/capability_convergence_explanation.md

@@ -0,0 +1,49 @@
+# Capability Convergence Explanation — WARUM konvergieren diese Capabilities?
+
+_Nicht „welche MCAPs?", sondern „warum verlangen völlig verschiedene Welten immer wieder DIESELBEN?". Drei abgeleitete Sichten über vorhandene Daten (kein ML, keine neue Architektur). Der eigentliche Burggraben ist nicht „MCAP-X existiert", sondern „warum MCAP-X existieren MUSS"._
+
+## 1. Warum konvergieren sie? — Domänen-Matrix + Grund
+| Capability | Industrial | Automotive | Medical | Environmental | Grund (Familie) |
+|---|---|---|---|---||---|
+| `access_control_and_authentication` | ✓ | ✓ | ✓ | – | Wer/was darf — Identität und Zugriff. |
+| `sbom_creation` | ✓ | ✓ | ✓ | – | Lieferkette/Stoffstrom — was steckt im Produkt? (SBOM = Software, Stoffliste = Material). |
+| `secure_signed_update_distribution` | ✓ | ✓ | ✓ | – | Softwareprodukt — jedes vernetzte Produkt muss sicher aktualisierbar sein. |
+| `technical_vulnerability_management` | ✓ | ✓ | ✓ | – | Produktbetrieb — Schwächen über die Lebensdauer behandeln. |
+| `asset_and_configuration_management` | ✓ | ✓ | – | – | Konfiguration und Asset-Kontrolle. |
+| `coordinated_vulnerability_disclosure` | ✓ | ✓ | – | – | Produktbetrieb — Schwächen über die Lebensdauer behandeln. |
+| `cryptography` | ✓ | ✓ | – | – | — |
+| `document_and_change_control` | ✓ | ✓ | – | – | Nachweisführung — Konformität dokumentieren. |
+| `incident_management` | ✓ | ✓ | – | – | Vorfälle erkennen, behandeln und melden. |
+| `product_cyber_risk_assessment` | ✓ | ✓ | – | – | Universeller Prozess — jede Regulierung verlangt eine Risikobeurteilung. |
+
+→ Das ist keine Statistik mehr, sondern **Erkenntnis**: dieselbe Fähigkeit kehrt wieder, weil ein universelles Prinzip dahinter steht (Softwareprodukt · Lieferkette · Produktbetrieb · universeller Prozess).
+
+## 2. Capability Families — 75 MCAPs reduzieren sich auf 15 Familien
+| Familie | Art | MCAPs | Domänen | Warum universell / spezifisch |
+|---|---|---:|---:|---|
+| **Risk** | core | 6 | 3 | Universeller Prozess — jede Regulierung verlangt eine Risikobeurteilung. |
+| **Update** | core | 4 | 3 | Softwareprodukt — jedes vernetzte Produkt muss sicher aktualisierbar sein. |
+| **Vulnerability** | core | 3 | 3 | Produktbetrieb — Schwächen über die Lebensdauer behandeln. |
+| **Identity & Access** | core | 3 | 3 | Wer/was darf — Identität und Zugriff. |
+| **Inventory & Composition** | core | 6 | 4 | Lieferkette/Stoffstrom — was steckt im Produkt? (SBOM = Software, Stoffliste = Material). |
+| **Supplier** | core | 3 | 3 | Lieferantensteuerung — Verantwortung über die Kette. |
+| **Incident & Reporting** | core | 2 | 2 | Vorfälle erkennen, behandeln und melden. |
+| **Monitoring & Audit** | core | 3 | 3 | Beobachtung — Betrieb und Umfeld überwachen. |
+| **Lifecycle & Development** | core | 3 | 3 | Produkt-/Software-Lebenszyklus. |
+| **Documentation & Evidence** | core | 6 | 4 | Nachweisführung — Konformität dokumentieren. |
+| **Configuration & Asset** | core | 2 | 2 | Konfiguration und Asset-Kontrolle. |
+| **Environmental/Material** | domain | 9 | 1 | Umwelt-/Stoff-spezifisch. |
+| **Medical** | domain | 7 | 3 | Medizin-/Patientensicherheit-spezifisch. |
+| **Automotive** | domain | 4 | 1 | Automotive-/Funktionssicherheit-spezifisch. |
+| **Process & QMS** | domain | 4 | 3 | QM-/Prozessdisziplin. |
+| _(nicht zugeordnet)_ | — | 10 | — | Review: Familie fehlt oder Name untypisch |
+
+→ Die Familien **erklären** die Konvergenz: unterschiedliche Regelwerke brauchen dieselben MCAPs, weil sie dieselbe FAMILIE adressieren. Vermutete Langzeit-Reduktion: ~15 Familien statt 75 Einzel-MCAPs.
+
+## 3. Core vs Domain — eine BERECHNETE Eigenschaft (keine neue Klasse, keine Architektur)
+- **Core (6):** kehren über ≥2 unabhängige Domänen UND ≥2 Quelltypen wieder — z. B. `access_control_and_authentication`, `incident_management`, `secure_development_lifecycle`, `secure_signed_update_distribution`, `supplier_security`, `technical_vulnerability_management` ….
+- **Domain (61):** überwiegend EINE Fachdomäne — z. B. `account_energy_consumption`, `analyze_water_discharge`, `approve_production_parts_ppap`, `assess_software_process_capability`, `assign_unique_device_identification`, `ce_conformity_assessment_and_technical_documentation` ….
+- **Bridging (8):** dazwischen (mehrere Domänen, aber 1 Quelltyp).
+
+> **Befund:** Medical machte es offensichtlich — die neuen medizinischen Capabilities sind fast alle **Domain**, während Update/SBOM/Access/Logging **Core** sind. Die Zweiteilung ist eine **abgeleitete Eigenschaft** aus (Domänen × Quelltypen), kein neues Modell. Der eigentliche Burggraben ist die Erklärung, WARUM die Core-Familien existieren: sie sind die wenigen universellen Prinzipien (Risiko · Update · Identität · Inventar · Nachweis · Lieferant · Lebenszyklus), auf die sehr unterschiedliche Anforderungswelten immer wieder zurückfallen. Reine Aggregation, 0 Runtime, 0 neue Architektur.
+