docs(knowledge): TKP 4-level lifecycle + 3 enrichments + ISMS->TISAX (genericity proof)

Transition KNOWLEDGE Patterns (renamed term -- curated knowledge, not an algorithm):
- 4 maturity levels: draft -> reviewed -> validated (domain expert) -> proven (field). "approved"
  dropped; target is validated. TP-ISO27001-CRA set to reviewed (L2).
- 3 enrichments per pattern: confidence_source: relationship (curated, not an LLM estimate ->
  computed-not-stored); why_asked (customer-facing: why the source does not suffice here); dropped_if
  (what makes the question unnecessary). Applied to TP-ISO27001-CRA.
- New TP-ISMS-TISAX (draft): different character -- info-security module mostly covered; delta is
  automotive-specific (prototype protection, TISAX labels, VDA ISA self-assessment, ENX assessment,
  Art. 28 data protection). Proves the architecture is GENERIC, not CRA-tailored.
- Reference scenario 4 generalized to loop over ALL patterns through RS-005: both carried (CRA
  17->17, TISAX 13->13) -> a living genericity + regression test for every future pattern.

Non-runtime knowledge + reference harness -> no deploy (ADR-001). Next: ISO9001->IATF16949.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

backend-compliance/knowledge/transition_patterns/README.md

@@ -1,54 +1,65 @@
-# Transition Patterns — curated knowledge base
+# Transition Knowledge Patterns (TKP) — curated knowledge base
 
-**Knowledge, not runtime code.** This directory holds the Reasoning session's *Knowledge
-Acquisition* output: versioned, reviewed expert patterns that describe how to move a company
-from an **Ausgangszustand** (e.g. ISO 27001) to a regulatory **Zielzustand** (e.g. CRA).
+**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 today — they are consumed later by the Transition Planning
-Engine (`compliance/transition_reasoning/`, RS-005) and the Question Renderer (RS-005.1).
-Adding/curating a pattern is therefore **non-runtime → no deploy** (see ADR-001).
+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. It separates:
-- `likely_covered_org_level` — what the source state probably already establishes (Welt 1 hint,
-  needs product-level confirmation; never auto-"erfüllt");
-- `delta_requirements` — what the target state adds that the source has no analogue for (ask first).
+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 same identity-machine discipline as Master Controls/Obligations/Capabilities).
+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` (draft → reviewed → approved) · `version` ·
-`transition_goal` ({from: standard/edition/nature, to: regulation/reference/applies_from/nature, one_line}) ·
-`provenance` (author/basis/reviewed_by/reviewed_at) · `disclaimer` ·
-`source_state_variants` (certified / isms_introduced / expired / limited_scope — how the start changes assumption strength) ·
-`likely_covered[]` ({capability, source_basis, target, **relationship** (supports|partially_supports, never equivalent),
-**verification** (required), expected_evidence, **rationale** (the *Warum* — why this relationship), **reviewable_claim**
-(an auditor can agree/disagree)}) ·
-`delta_requirements[]` ({capability, target_basis, **missing_because**, needed_information (intent),
-expected_evidence, priority, **reviewable_claim**}) ·
-`rejected_assumptions[]` (explicit "does NOT establish …") · `determinism_goal` · `review_checklist[]`.
+`id` · `status` (4 levels above) · `version` · `transition_goal` · `provenance` · `disclaimer` ·
+`source_state_variants` · `likely_covered[]` · `delta_requirements[]` · `rejected_assumptions[]` ·
+`determinism_goal` · `review_checklist[]`.
 
-**Gold-standard bar:** every line is auditor-checkable (agree/disagree, not "probably"); each assumption
-carries a typed `relationship` + a `rationale`; each delta maps to a missing capability + needed info;
-explicit `rejected_assumptions` keep the source certificate from being over-read; two auditors should
-arrive at the same delta questions (`determinism_goal`).
+**`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 draft, not a normative/legal proof.** A pattern is a consultant-grade heuristic; it must
-  be reviewed (and ideally auditor-checked) before customer use. `status` tracks that.
+- **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".
-- `question_intent` is an intent (verify_existence / determine_duration / request_evidence / …) — the
-  rendered question text is produced later by RS-005.1, not stored here.
+- **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 |
+| Pattern | from → to | status (level) |
 |---|---|---|
-| `transition_pattern_iso27001_to_cra_v1.yaml` | ISO 27001 → CRA | draft |
+| `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: `ISMS → TISAX`, `ISO 9001 → IATF 16949`, `ISO 14001 → CRA-Environmental`.
+Next candidates: `ISO 9001 → IATF 16949`, `ISO 14001 → environmental regulation`.