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.
Regulatory Transition / Convergence Patterns — curated knowledge base
Curated regulatory KNOWLEDGE in machine-readable form — not an algorithm, not runtime code. This directory holds the Reasoning session's Knowledge Acquisition output: versioned, expert-reviewed patterns describing how to move a company from an Ausgangszustand (e.g. ISO 27001) to a regulatory Zielzustand (e.g. CRA).
Two pattern_types (the term evolves with the scope):
regulatory_transition— one source → ONE target regulation (e.g. ISO 27001 → CRA).regulatory_convergence— one source → MULTIPLE targets at once (e.g. ISO 27001 → CRA + MaschinenVO). Here each capability declarescovers_targets(which regulations it satisfies SIMULTANEOUSLY). This is the USP: a capability covering >= 2 regulations is convergence —compliance/transition_reasoning/regulatory_convergence()counts them, yielding the customer sentence „von N neuen Maßnahmen erfüllen M gleichzeitig CRA und MaschinenVO".
Nothing imports these at runtime — they are consumed later by the Transition Planning Engine
(compliance/transition_reasoning/, RS-005) and the Question Renderer (RS-005.1). Adding or
curating a pattern is therefore non-runtime → no deploy (ADR-001).
Maturity levels (replace draft → reviewed → "approved")
| Level | status |
Meaning |
|---|---|---|
| 1 | draft |
AI first draft; no human review. |
| 2 | reviewed |
Internally reviewed by BreakPilot: architecture consistent, no obvious contradictions, references plausible, reference scenario runs. |
| 3 | validated |
At least one domain expert (e.g. ISO 27001 lead auditor / CRA expert) checked it; all review_required points closed. |
| 4 | proven |
Applied in multiple real customer projects; the delta questions proved correct and sufficient; feedback incorporated. |
"approved" is intentionally NOT used — the target is validated (expert-checked), then proven (field-tested).
Why patterns instead of a question list
A pattern captures the difference between two states, not a full standard:
likely_covered— what the source state probably already establishes (Welt-1 hint, needs product-level confirmation; never auto-"erfüllt");delta_requirements— what the target adds that the source has no analogue for (ask first).
After ~5 patterns the repeated delta items converge into Master Delta Questions — emergent, not designed up front (the identity-machine discipline of Master Controls/Obligations/Capabilities).
File schema (per transition_pattern_<from>_to_<to>_v<n>.yaml)
id · status (4 levels above) · version · transition_goal · provenance · disclaimer ·
source_state_variants · likely_covered[] · delta_requirements[] · rejected_assumptions[] ·
determinism_goal · review_checklist[].
likely_covered[] item: {capability, source_basis, target, relationship (supports|partially_supports,
never equivalent), verification (required), confidence_source (relationship — NOT an LLM estimate;
fits computed-not-stored), expected_evidence, rationale (the Warum), reviewable_claim}.
delta_requirements[] item: {capability, target_basis, missing_because, why_asked (customer-facing:
why the source does NOT suffice here → why BreakPilot asks), dropped_if (what makes the question
unnecessary — e.g. a named document/process), needed_information (intent), expected_evidence, priority, reviewable_claim}.
Hard rules
- Expert knowledge, not a normative/legal proof. A pattern is a consultant-grade heuristic; it must
reach
validated(expert-checked) before customer use.statustracks this. - Welt-1 only. „probably covered" is a hint with confidence + verification need, never „erfüllt".
- Confidence comes from the curated
relationship, not a model (confidence_source: relationship). question_intentis an intent (verify_existence / determine_duration / …); the rendered question text is produced later by RS-005.1, not stored here.capabilityids reference the (Execution-owned) Capability Registry MCAP ids once assigned.
Catalogue
| Pattern | from → to | status (level) |
|---|---|---|
transition_pattern_iso27001_to_cra_v1.yaml |
ISO 27001 → CRA | reviewed (L2) · transition |
transition_pattern_isms_to_tisax_v1.yaml |
ISMS → TISAX | draft (L1) · transition |
transition_pattern_iso9001_to_cra_v1.yaml |
ISO 9001 → CRA | draft (L1) · transition |
transition_pattern_iso27001_to_cra_maschinenvo_v1.yaml |
ISO 27001 → CRA + MaschinenVO | draft (L1) · convergence |
Next: CRA + MaschinenVO + Data Act (3-target) · ISO 14001 → environmental regulation · ISO 9001 → IATF 16949.