Benjamin Admin
4bfd552da7
(1) Harden the first Transition Pattern to the gold-standard template per quality checklist: versioned transition_goal (ISO27001:2022 -> CRA, applies 2027-12-11), source_state_variants (certified/isms_introduced/expired/limited_scope), each likely_covered assumption with a typed relationship (supports|partially_supports, never equivalent) + verification + rationale (the Warum) + an auditor-checkable reviewable_claim, delta as missing-capability + needed-info, an explicit rejected_assumptions section, and a determinism_goal. README schema updated to match. (2) New Reference-Suite scenario 4 (Transition): the generator READS the pattern YAML and runs it through the RS-005 Planning Engine + Company 2A -> coverage + question requests. Proves the architecture fully carries the pattern (17 caps -> 17 coverage + 17 requests; 9 HIGH delta = the real CRA gaps, 8 probably-covered from the ISMS). Now a living regression test: every future pattern runs through the same engine. Non-runtime knowledge + reference harness -> no deploy (ADR-001). Next: ISMS->TISAX once approved. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
55 lines
3.3 KiB
Markdown
55 lines
3.3 KiB
Markdown
# 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` · `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[]`.
|
|
|
|
**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`).
|
|
|
|
## 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`.
|