Benjamin_Boenisch/breakpilot-compliance
1
1
Fork 0
Code Issues 24 Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Automotive convergence stress test — same capability from many sources (Phase Ω #2)

Browse Source 
Not another domain to prove agnosticism (Environmental did that) but a DIFFERENT property: can the
SAME capability be fed by many overlapping Requirement Sources at once without the model becoming
unstable? Realistic setup — a supplier with ISO 9001 + IATF 16949 + TISAX + ASPICE + CSMS + SUMS
developing an ECU for OEM X. Seven sources (CRA, UNECE R155/CSMS, R156/SUMS, IATF, TISAX, ASPICE,
OEM X) with deliberate overlap, run through the SAME engine (0 runtime code, data only).

Three new measurements (user-requested):
  - Capability Convergence: technical_vulnerability_management = 4 sources across 3 source TYPES
    (regulation + certification + contract); secure_signed_update_distribution = 4 sources. The
    overlap is where the economic value lives ("one capability replaces five evidence worlds").
  - Existing-vs-New: 13/27 required caps reuse existing cyber/environmental MCAPs (48%) -> the
    registry is starting to converge; the automotive-specific rest (CSMS/SUMS/ASPICE/functional
    safety) is expectedly new (a maturity hint, not an architecture break).
  - Business Leverage: a convergent capability satisfies N regulations AND unlocks the OEM market —
    more convincing to a GF than "satisfies five laws". (Regulatory Leverage counts regulations;
    Business Leverage counts regulations + markets/customers.)

Ledger gains the automotive row (0/0, 14 new types, data_only); stability stays 7/7 = 100%. The
verdict recommends the user's next step: NOT a new domain but PAUSE and analyse the registry for the
cross-domain high-convergence core MCAPs. Non-runtime -> no deploy. 12 tests pass, check-loc 0.
This commit is contained in:
Benjamin Admin
2026-06-28 11:30:30 +02:00
parent e0d9816c99
commit 90c3fe16b5
6 changed files with 300 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
backend-compliance/reference_scenarios/automotive_convergence_stress_test.md
+36
View File
@@ -0,0 +1,36 @@
# 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.