# 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_type`s (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 declares **`covers_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. `status` tracks 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_intent` is an intent (verify_existence / determine_duration / …); the rendered question text
  is produced later by RS-005.1, not stored here.
- `capability` ids 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`.
