Benjamin Admin
90c3fe16b5
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.
59 lines
3.6 KiB
YAML
59 lines
3.6 KiB
YAML
# Automotive multi-source capability data — the CONVERGENCE stress test (Phase Ω, test #2).
|
|
#
|
|
# Not another domain to validate domain-agnosticism (Environmental already proved that). This tests a
|
|
# DIFFERENT property: can the SAME capability be fed by MANY different Requirement Sources at once
|
|
# without the model becoming unstable? Realistic setup: a supplier developing an ECU for OEM X, who
|
|
# already holds ISO 9001 + IATF 16949 + TISAX + ASPICE (L2/3) + CSMS + SUMS.
|
|
#
|
|
# Each source lists the capabilities it REQUIRES. Overlap is deliberate and realistic — that overlap is
|
|
# exactly where the economic value lives ("one capability replaces five evidence worlds"). Capabilities
|
|
# are VERBS / stable ids reused from the cyber + environmental patterns where they recur, so the
|
|
# existing-vs-new (registry convergence) measurement is honest. Data only — no runtime code.
|
|
|
|
goal: "Develop a new ECU (Steuergerät) and supply OEM X."
|
|
|
|
sources:
|
|
- id: CRA
|
|
type: regulation
|
|
requires: [secure_signed_update_distribution, technical_vulnerability_management,
|
|
coordinated_vulnerability_disclosure, sbom_creation, access_control_and_authentication,
|
|
incident_management, secure_development_lifecycle, product_cyber_risk_assessment]
|
|
- id: UNECE_R155_CSMS
|
|
type: regulation
|
|
requires: [secure_signed_update_distribution, technical_vulnerability_management,
|
|
product_cyber_risk_assessment, incident_management, access_control_and_authentication,
|
|
cybersecurity_management_system, threat_analysis_and_risk_assessment]
|
|
- id: UNECE_R156_SUMS
|
|
type: regulation
|
|
requires: [secure_signed_update_distribution, software_update_management_system,
|
|
identify_software_versions_rxswin, document_update_campaigns]
|
|
- id: IATF_16949
|
|
type: certification
|
|
requires: [document_and_change_control, supplier_evaluation, release_and_approval_process,
|
|
approve_production_parts_ppap, plan_product_quality_apqp]
|
|
- id: TISAX
|
|
type: certification
|
|
requires: [information_security_management, access_control_and_authentication, incident_management,
|
|
technical_vulnerability_management, supplier_security, protect_prototypes]
|
|
- id: ASPICE
|
|
type: process
|
|
requires: [assess_software_process_capability, engineer_requirements_process,
|
|
verify_software_process, manage_configuration_process]
|
|
- id: OEM_X_Spec
|
|
type: contract
|
|
requires: [secure_signed_update_distribution, technical_vulnerability_management,
|
|
provide_functional_safety_evidence, protect_prototypes, supplier_security,
|
|
identify_software_versions_rxswin, provide_dedicated_security_contact]
|
|
|
|
# The company's certificates/processes -> the capabilities they make probably-present (Welt-1).
|
|
# (Management/process discipline + the security baseline an automotive supplier with these certs has.)
|
|
company_profile_capabilities:
|
|
ISO9001: [document_and_change_control, supplier_evaluation, release_and_approval_process]
|
|
IATF16949: [approve_production_parts_ppap, plan_product_quality_apqp]
|
|
TISAX: [information_security_management, access_control_and_authentication, incident_management,
|
|
technical_vulnerability_management, supplier_security, protect_prototypes]
|
|
ASPICE: [assess_software_process_capability, engineer_requirements_process,
|
|
verify_software_process, manage_configuration_process]
|
|
CSMS: [cybersecurity_management_system, threat_analysis_and_risk_assessment, product_cyber_risk_assessment]
|
|
SUMS: [software_update_management_system, document_update_campaigns]
|