Files

T

Benjamin Admin bea8559f78 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

2.5 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 · 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.

2.5 KiB Raw Blame History