Benjamin Admin
cefacb87af
The focus has shifted: no more architecture epics (the Journey Matcher was the last building block). The question is no longer "can the architecture do this?" but "where does it fail under real domain knowledge?". This operationalises the two KPIs almost nobody measures, as a non- runtime, auditable ledger: - Architecture Stability : per integrated Requirement Source — new runtime classes? new pipeline? - Knowledge Velocity : can a domain EXPERT integrate a source data-only, without a developer? A new domain is a ROW in knowledge/architecture_stability/integration_ledger.yaml (data), never a code change — so the KPI improves by adding data, which IS the proof. Current state: 6 sources across 5 target types (CRA, MaschinenVO, TISAX, Tender, OEM, Environmental) = 6/6 = 100% stability and 100% data-only. The pipeline functions are listed honestly as one-time, domain-agnostic infrastructure (now frozen), so the KPI cannot be gamed. The test is a LIVING GUARDRAIL: it fails the day a source needs runtime code, surfacing the exact moment generality breaks. Non-runtime -> no deploy. 5 tests pass, check-loc 0.
81 lines
3.7 KiB
YAML
81 lines
3.7 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 ---
|
|
sources:
|
|
- source: "Cyber Resilience Act (CRA)"
|
|
domain: industrial_automation
|
|
target_type: regulation
|
|
integrated_as: transition_pattern_data
|
|
new_runtime_classes: 0
|
|
new_pipeline: false
|
|
integration_kind: data_only
|
|
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
|
|
integration_kind: data_only
|
|
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
|
|
integration_kind: data_only
|
|
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
|
|
integration_kind: data_only
|
|
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
|
|
integration_kind: data_only
|
|
exercised_by: "customer_mission_4"
|
|
- source: "Environmental / Material evidence target"
|
|
domain: environmental
|
|
target_type: environmental
|
|
integrated_as: injected_required_set
|
|
new_runtime_classes: 0
|
|
new_pipeline: false
|
|
integration_kind: data_only
|
|
exercised_by: "customer_mission_5"
|
|
|
|
# --- 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
|