Benjamin Admin
80f2e2f619
Medical before Payment: the harder scientific test (safety AND security coupled, full lifecycle, deep risk/evidence demands). ISO 13485 runs through the SAME engine as ISO 27001 -> CRA, only new data, 0 runtime. The key result: IEC 81001-5-1 (health-software security) pulls in the SAME security MCAPs as the CRA, so Medical REUSES cyber capabilities (the safety/security coupling appears as capability reuse) while adding 7 genuinely new medical caps (clinical evaluation, software safety classification, ISO 14971 risk file, benefit-risk). rejected_assumptions intact. Effect on the convergence core: secure_signed_update_distribution 18 -> 24 and technical_vulnerability_management 17 -> 23, now spanning 3 domains (cyber + industrial + medical) — the core visibly GROWS, exactly the convergence signal. New 5th report: MISSING CONVERGENCE — deterministic (no ML) token-cluster detector for potential structural duplications: a name token shared by >=3 MCAPs across >=2 distinct sources is flagged for EXPERT REVIEW (never auto-merged). Surfaces e.g. the `risk` cluster (6 risk MCAPs across 6 sources) and `security`/`software`; single-source decompositions are filtered out. Complements Suspicious by looking at cross-source duplication, not single MCAPs. Also records the durable modelling rule extracted from the frequency fix: evidence is attributed to its ORIGIN; its value against a target is computed later (relevance(evidence,target)). Ledger now 8 sources, Architecture Stability 8/8 = 100%. Non-runtime -> no deploy. 29 tests pass, check-loc 0.
116 lines
5.5 KiB
YAML
116 lines
5.5 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"
|
|
- source: "ISO 13485 -> Medical device (MDR / IEC 62304 / ISO 14971 / IEC 81001-5-1)"
|
|
domain: medical
|
|
target_type: regulation
|
|
integrated_as: transition_pattern_data
|
|
new_runtime_classes: 0
|
|
new_pipeline: false
|
|
new_capability_types: 7 # of 11 delta caps, 4 REUSE cyber MCAPs (IEC 81001-5-1 = CRA security coupling)
|
|
integration_kind: data_only
|
|
family: non_cyber # safety/clinical domain WITH a security coupling — the harder joint test
|
|
exercised_by: "medical_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
|