# 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.