docs(knowledge): first Transition Pattern ISO27001 -> CRA (curated knowledge base)

Reasoning session's new Knowledge Acquisition responsibility (re-charter): build and curate the Transition Knowledge Base under backend-compliance/knowledge/transition_patterns/ (beside reasoning/, not under it -- it is knowledge, not an engine). First professional pattern TP-ISO27001-CRA-v1 (status: draft): separates what a mature ISMS likely covers at the ORG level (probably_covered, needs product-level confirmation, never auto-"erfuellt") from the CRA-specific delta with no ISO 27001 analogue (SBOM, support period + secure signed updates, coordinated vulnerability disclosure, Art. 14 authority reporting, product cyber risk assessment, CE conformity / technical documentation). Expert draft, not a normative proof; review_required before customer use. Non-runtime knowledge -> no deploy (ADR-001). Next: ISMS->TISAX. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-27 07:50:42 +02:00
parent 81f8b56b48
commit bea8559f78
2 changed files with 226 additions and 0 deletions
@@ -0,0 +1,44 @@
+# Transition Patterns — 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).
+
+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).
+
+## 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).
+
+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).
+
+## File schema (per `transition_pattern_<from>_to_<to>_v<n>.yaml`)
+
+`id` · `from_state` · `to_state` · `version` · `status` (draft → reviewed → approved) ·
+`provenance` (author/basis/reviewed_by/reviewed_at) · `disclaimer` ·
+`likely_covered_org_level[]` ({capability, source_basis, target_relevance, reuse_caveat,
+confirm_question_intent, priority}) · `delta_requirements[]` ({capability, target_basis, why_delta,
+question_intent, expected_evidence, priority}) · `ask_order_rationale` · `review_required[]`.
+
+## 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.
+- **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.
+- `capability` ids reference the (Execution-owned) Capability Registry MCAP ids once assigned.
+
+## Catalogue
+
+| Pattern | from → to | status |
+|---|---|---|
+| `transition_pattern_iso27001_to_cra_v1.yaml` | ISO 27001 → CRA | draft |
+
+Next candidates: `ISMS → TISAX`, `ISO 9001 → IATF 16949`, `ISO 14001 → CRA-Environmental`.