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.
106 lines
5.0 KiB
YAML
106 lines
5.0 KiB
YAML
# Architecture Stability + Knowledge Velocity ledger — Phase Ω (Evidence of Generality).
|
|
#
|
|
# The question is no longer "can the architecture do this?" but "where does it fail under real domain
|
|
# knowledge?". Two KPIs almost nobody measures:
|
|
# - Architecture Stability : per integrated Requirement Source — new runtime classes? new pipeline?
|
|
# (target: 0 / 0)
|
|
# - Knowledge Velocity : can a DOMAIN EXPERT integrate a new source WITHOUT a software developer?
|
|
# (target: every source = data_only)
|
|
#
|
|
# HOW TO INTEGRATE A NEW SOURCE: add a ROW under `sources`. That is the whole point — a new domain is a
|
|
# DATA change here, never a code change. If you ever have to add a row under `pipeline_functions`, the
|
|
# stability claim broke and Phase Ω failed; record it honestly.
|
|
|
|
# --- Integrated Requirement Sources: each is DATA (a pattern / a Required set), run by the shared pipeline ---
|
|
# new_capability_types = distinct NEW capability ids the source introduced. NOT an architecture break —
|
|
# a FRÜHINDIKATOR for capability-model granularity: if a domain ever needs ~80 new types with 0 runtime
|
|
# change, the capability model is probably cut too coarse or too fine. Watch the number, not just 0/0.
|
|
sources:
|
|
- source: "Cyber Resilience Act (CRA)"
|
|
domain: industrial_automation
|
|
target_type: regulation
|
|
integrated_as: transition_pattern_data
|
|
new_runtime_classes: 0
|
|
new_pipeline: false
|
|
new_capability_types: 13
|
|
integration_kind: data_only
|
|
family: cyber
|
|
exercised_by: "customer_mission_1/2/3, journey_matcher_demo"
|
|
- source: "Maschinenverordnung (MaschinenVO)"
|
|
domain: industrial_automation
|
|
target_type: regulation
|
|
integrated_as: transition_pattern_data
|
|
new_runtime_classes: 0
|
|
new_pipeline: false
|
|
new_capability_types: 4
|
|
integration_kind: data_only
|
|
family: cyber
|
|
exercised_by: "customer_mission_1/3, journey_matcher_demo"
|
|
- source: "TISAX"
|
|
domain: automotive
|
|
target_type: certification
|
|
integrated_as: transition_pattern_data
|
|
new_runtime_classes: 0
|
|
new_pipeline: false
|
|
new_capability_types: 5
|
|
integration_kind: data_only
|
|
family: cyber
|
|
exercised_by: "customer_mission_3/5, journey_matcher_demo"
|
|
- source: "Public Tender (öffentliche Ausschreibung)"
|
|
domain: cross_industry
|
|
target_type: contract
|
|
integrated_as: injected_required_set
|
|
new_runtime_classes: 0
|
|
new_pipeline: false
|
|
new_capability_types: 3
|
|
integration_kind: data_only
|
|
family: cyber
|
|
exercised_by: "customer_mission_3/4"
|
|
- source: "OEM Specification (Lastenheft)"
|
|
domain: automotive
|
|
target_type: contract
|
|
integrated_as: injected_required_set
|
|
new_runtime_classes: 0
|
|
new_pipeline: false
|
|
new_capability_types: 4
|
|
integration_kind: data_only
|
|
family: cyber
|
|
exercised_by: "customer_mission_4"
|
|
- source: "ISO 14001 -> Environmental/Material (REACH/RoHS/Batterie/Wasser/Energie/Abfall)"
|
|
domain: environmental
|
|
target_type: regulation
|
|
integrated_as: transition_pattern_data
|
|
new_runtime_classes: 0
|
|
new_pipeline: false
|
|
new_capability_types: 16
|
|
integration_kind: data_only
|
|
family: non_cyber # FIRST non-cyber domain — the real generality test
|
|
exercised_by: "customer_mission_5, environmental_stress_test"
|
|
- source: "Automotive ECU for OEM X (CRA / UNECE R155+R156 / IATF 16949 / TISAX / ASPICE / OEM spec)"
|
|
domain: automotive
|
|
target_type: multi_source # 7 OVERLAPPING sources spanning regulation + certification + process + contract
|
|
integrated_as: multi_source_required_set
|
|
new_runtime_classes: 0
|
|
new_pipeline: false
|
|
new_capability_types: 14 # of 27 required caps, 13 reuse existing MCAPs (48% -> registry converging)
|
|
integration_kind: data_only
|
|
family: cyber # convergence test: same capability fed by many sources, model stayed stable
|
|
exercised_by: "automotive_convergence_stress_test"
|
|
|
|
# --- One-time, domain-AGNOSTIC pipeline functions (built once, now FROZEN per Phase Ω). ---
|
|
# Listed for honesty so the stability KPI cannot be gamed: these are NOT per-domain costs. The last
|
|
# one (journey_matcher) was the final architectural building block.
|
|
pipeline_functions:
|
|
- { fn: "transition_reasoning (RS-005)", maps: "Capability -> Delta", layer: transformation }
|
|
- { fn: "optimization", maps: "Delta -> Roadmap", layer: transformation }
|
|
- { fn: "journey_matcher (ADR-011)", maps: "Delta -> Journey", layer: transformation }
|
|
- { fn: "playbook", maps: "Capability -> Playbook", layer: production }
|
|
- { fn: "completeness", maps: "coverage audit", layer: production }
|
|
- { fn: "company (2A)", maps: "Evidence -> Capability", layer: descriptive }
|
|
|
|
# --- The architecture has settled into three non-overlapping knowledge layers (a good sign). ---
|
|
knowledge_layers:
|
|
descriptive: ["Requirements", "Capabilities", "Evidence"] # what IS
|
|
transformation: ["Delta", "Journey", "Roadmap"] # how to MOVE
|
|
production: ["Playbooks", "Verification", "Reference Scenarios"] # how to DO + PROVE
|