Files

T

Benjamin Admin 66be23f0c4 feat(convergence): first Regulatory Convergence Pattern (ISO27001 -> CRA + MaschinenVO)

The first multi-regulation pattern: each capability declares `covers_targets`, so we
can answer the convergence USP — "which capability satisfies CRA AND MaschinenVO at once?"

- knowledge: transition_pattern_iso27001_to_cra_maschinenvo_v1.yaml (pattern_type:
  regulatory_convergence, status draft). The cyber-safety bridge = MaschinenVO Annex III
  1.1.9 "protection against corruption" overlapping CRA integrity. 4 convergence
  capabilities cover BOTH; 5 CRA-only; 3 MaschinenVO-only.
- product: compliance/transition_reasoning/convergence.py — regulatory_convergence()
  pure/deterministic/computed-not-stored, no new graph/class (freeze v1.0 untouched).
  No app caller yet -> non-runtime, no deploy (ADR-001).
- reference suite: Cross-Regulation Capability Mapping section renders the customer
  sentence "von N neuen Massnahmen erfuellen M gleichzeitig CRA und MaschinenVO".
- README: term -> Regulatory Transition / Convergence Pattern; covers_targets documented.
- tests: test_regulatory_convergence (18 transition+company pass), mypy --strict clean.

Curated expert knowledge, AI first draft (L1/draft) — Annex/Article refs indicative,
review_required by a machinery-safety expert.

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

2026-06-27 09:12:30 +02:00

4.7 KiB

Raw Blame History

Regulatory Transition / Convergence Patterns — curated knowledge base

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).

Two pattern_types (the term evolves with the scope):

regulatory_transition — one source → ONE target regulation (e.g. ISO 27001 → CRA).
regulatory_convergence — one source → MULTIPLE targets at once (e.g. ISO 27001 → CRA + MaschinenVO). Here each capability declares covers_targets (which regulations it satisfies SIMULTANEOUSLY). This is the USP: a capability covering >= 2 regulations is convergence — compliance/transition_reasoning/regulatory_convergence() counts them, yielding the customer sentence „von N neuen Maßnahmen erfüllen M gleichzeitig CRA und MaschinenVO".

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:

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 identity-machine discipline of Master Controls/Obligations/Capabilities).

File schema (per `transition_pattern_<from>_to_<to>_v<n>.yaml`)

id · status (4 levels above) · version · transition_goal · provenance · disclaimer · source_state_variants · likely_covered[] · delta_requirements[] · rejected_assumptions[] · determinism_goal · review_checklist[].

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 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".
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 (level)
`transition_pattern_iso27001_to_cra_v1.yaml`	ISO 27001 → CRA	`reviewed` (L2) · transition
`transition_pattern_isms_to_tisax_v1.yaml`	ISMS → TISAX	`draft` (L1) · transition
`transition_pattern_iso9001_to_cra_v1.yaml`	ISO 9001 → CRA	`draft` (L1) · transition
`transition_pattern_iso27001_to_cra_maschinenvo_v1.yaml`	ISO 27001 → CRA + MaschinenVO	`draft` (L1) · convergence

Next: CRA + MaschinenVO + Data Act (3-target) · ISO 14001 → environmental regulation · ISO 9001 → IATF 16949.

4.7 KiB Raw Blame History