# Automotive Convergence Stress Test — überlebt EINE Capability viele Quellen? (Phase Ω #2)

_Nicht noch eine Domäne, sondern eine andere Eigenschaft: bleibt das Modell stabil, wenn dieselbe Capability gleichzeitig aus vielen überlappenden Quellen gespeist wird? Realistisch: ein Zulieferer (ISO 9001 + IATF 16949 + TISAX + ASPICE + CSMS + SUMS) entwickelt ein Steuergerät für OEM X. Sieben Quellen, bewusste Überlappung. Data-only, keine echten Namen._

## 1. Sieben überlappende Quellen, eine Engine
- Quellen: `CRA`(regulation), `UNECE_R155_CSMS`(regulation), `UNECE_R156_SUMS`(regulation), `IATF_16949`(certification), `TISAX`(certification), `ASPICE`(process), `OEM_X_Spec`(contract).
- **27 distinct geforderte Capabilities** für „Steuergerät → OEM X" — über dieselbe `assess_transition`-Engine, 0 neue Runtime-Klassen.
- Delta (fehlt dem Profil): **7** Capabilities.

## 2. Capability Convergence — dieselbe Capability aus vielen Quellen
| Capability | Sources | Distinct Source Types | aus |
|---|---:|---:|---|
| `technical_vulnerability_management` | 4 | 3 | CRA, OEM_X_Spec, TISAX, UNECE_R155_CSMS |
| `secure_signed_update_distribution` | 4 | 2 | CRA, OEM_X_Spec, UNECE_R155_CSMS, UNECE_R156_SUMS |
| `access_control_and_authentication` | 3 | 2 | CRA, TISAX, UNECE_R155_CSMS |
| `incident_management` | 3 | 2 | CRA, TISAX, UNECE_R155_CSMS |
| `identify_software_versions_rxswin` | 2 | 2 | OEM_X_Spec, UNECE_R156_SUMS |
| `protect_prototypes` | 2 | 2 | OEM_X_Spec, TISAX |
| `supplier_security` | 2 | 2 | OEM_X_Spec, TISAX |
| `product_cyber_risk_assessment` | 2 | 1 | CRA, UNECE_R155_CSMS |

→ **`technical_vulnerability_management`** ist am konvergentesten: **4 Quellen** über **3 Quelltypen** — eine Maßnahme, viele Nachweiswelten. Genau hier entsteht der wirtschaftliche Nutzen (nicht „300 Gesetze", sondern „eine Capability ersetzt fünf Nachweiswelten").

## 3. Existing-vs-New — beginnt die Registry zu konvergieren?
- **Bereits vorhandene MCAPs (Reuse aus Cyber/Umwelt): 13/27 = 48%** — z. B. `access_control_and_authentication`, `coordinated_vulnerability_disclosure`, `document_and_change_control`, `incident_management`, `information_security_management` ….
- **Genuin neu (Automotive-spezifisch): 14** — z. B. `approve_production_parts_ppap`, `assess_software_process_capability`, `cybersecurity_management_system`, `document_update_campaigns`, `engineer_requirements_process` ….
- **Lesart:** Spürbare Wiederverwendung (48%) — der Kern beginnt sich zu bilden; der automotive-spezifische Rest (CSMS/SUMS/ASPICE/Funktionssicherheit) ist erwartbar neu. Kein Architekturbruch, sondern ein Hinweis auf den Reifegrad der Capability-Zerlegung.

## 4. Business Leverage — Märkte + Regulierung, nicht nur „Gesetze"
- `technical_vulnerability_management` erfüllt gleichzeitig **2 Regelwerke** (CRA, UNECE_R155_CSMS) **und** öffnet den **OEM-Markt** (OEM_X_Spec).
- Managementsatz: **„Diese eine Capability erfüllt 2 regulatorische Anforderungen UND ist Eintrittskarte zum OEM-Geschäft"** — überzeugender als „erfüllt 2 Gesetze". (Regulatory Leverage zählt Regelwerke; **Business Leverage** zählt Regelwerke + erschlossene Märkte/Kunden.)

## Befund

> **Eine Capability aus bis zu 4 Quellen über 3 Quelltypen — das Modell blieb stabil (0 neue Runtime-Klassen, 0 neue Pipeline; reine Daten).** Convergence ist messbar geworden, und 48% der Automotive-Anforderungen bilden auf BESTEHENDE MCAPs ab — die Registry beginnt zu konvergieren. Nächster Schritt ist bewusst KEINE neue Domäne, sondern **innehalten und die Registry analysieren**: welche MCAPs tauchen domänenübergreifend (CRA·MaschinenVO·OEM·TISAX·ASPICE·Umwelt) am häufigsten auf? Diese hochkonvergenten Capabilities sind der dauerhaft wertvollste Plattformkern.