Benjamin Admin
f78e03bd0a
Three ANONYMIZED reference transition scenarios (no real company names stored) = canonical regression scenarios that test the KNOWLEDGE, not just the engine. Each pins an Expected Outcome (expected_likely_covered + expected_delta); every commit must reproduce it (identical or better). - RTS-001 automotive supplier (TISAX+ISO27001) -> CRA: mature ISMS, standard CRA delta. - RTS-002 classic machine builder (ISO9001) -> CRA: only process discipline -> MUCH larger delta (10 missing vs 3 covered). New TP-ISO9001-CRA-v1 pattern (different shape). - RTS-003 networked machine builder (ISMS) -> CRA: highlights the Data Act. Data Act is modelled as UNCERTAIN (a hypothesis), never a fixed gilt/gilt-nicht: the generator checks the engine SURFACES the uncertainty + the deciding question (generates_usage_data) and never wrongly ASSERTS applicability. All three RTS PASS. Non-runtime knowledge + reference harness -> no deploy (ADR-001). Names deliberately absent. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Transition Knowledge Patterns (TKP) — 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).
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_pattern_isms_to_tisax_v1.yaml |
ISMS → TISAX | draft (L1) |
Next candidates: ISO 9001 → IATF 16949, ISO 14001 → environmental regulation.