Files

T

Benjamin Admin 4bfd552da7 docs(knowledge): TP-ISO27001->CRA gold standard + reference scenario (RS-005 regression)

(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>

2026-06-27 08:11:42 +02:00

3.3 KiB

Raw Blame History

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.

3.3 KiB Raw Blame History