Benjamin Admin
fbbd0957bd
First NON-cyber stress test. Every prior journey was cyber (infosec/software/product security).
Environmental brings a completely different mental model (substance flows, emissions, water,
chemicals, energy, circularity). The claim under test: RS-005 carries it UNCHANGED — only new DATA,
zero runtime code.
ISO 14001 (an EMS) is modelled as a Company Profile and run through the SAME engines as ISO 27001 ->
CRA (new pattern transition_pattern_iso14001_to_environmental_v1.yaml, capabilities as VERBS):
- ISO 14001 yields 5 environmental MANAGEMENT capabilities (Welt-1, probably present)
- the concrete substance/emission/water/material EVIDENCE is the 11-capability delta
- rejected_assumptions state what ISO 14001 does NOT produce (substance lists, REACH, emissions,
battery passports, water analyses) — preserving the Welt-1/Welt-2 separation
- the Journey Matcher stays domain-agnostic: ISO14001->Environmental 100%, cyber journeys 0%
Result: a non-cyber domain ran through Reality -> ... -> Journey with 0 new runtime classes and 0
new pipeline — a stronger generality proof than ten more cyber regulations.
Also extends the Architecture Stability ledger with the third KPI column the user requested — "new
capability types" — as a granularity Frühindikator (a domain needing ~80 new types at 0 runtime would
flag a too-coarse/too-fine capability model). Environmental = 16 types (5 mgmt + 11 evidence), in
range. Ledger now flags cyber vs non_cyber family. Non-runtime -> no deploy. 19 tests pass, check-loc 0.
96 lines
4.4 KiB
YAML
96 lines
4.4 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"
|
|
|
|
# --- 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
|