Files

T

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

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.

2026-06-28 11:30:30 +02:00

3.7 KiB

Raw Blame History

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.

3.7 KiB Raw Blame History