Files

T

Benjamin Admin 0da093c046 docs(knowledge): TKP 4-level lifecycle + 3 enrichments + ISMS->TISAX (genericity proof)

Transition KNOWLEDGE Patterns (renamed term -- curated knowledge, not an algorithm):
- 4 maturity levels: draft -> reviewed -> validated (domain expert) -> proven (field). "approved"
  dropped; target is validated. TP-ISO27001-CRA set to reviewed (L2).
- 3 enrichments per pattern: confidence_source: relationship (curated, not an LLM estimate ->
  computed-not-stored); why_asked (customer-facing: why the source does not suffice here); dropped_if
  (what makes the question unnecessary). Applied to TP-ISO27001-CRA.
- New TP-ISMS-TISAX (draft): different character -- info-security module mostly covered; delta is
  automotive-specific (prototype protection, TISAX labels, VDA ISA self-assessment, ENX assessment,
  Art. 28 data protection). Proves the architecture is GENERIC, not CRA-tailored.
- Reference scenario 4 generalized to loop over ALL patterns through RS-005: both carried (CRA
  17->17, TISAX 13->13) -> a living genericity + regression test for every future pattern.

Non-runtime knowledge + reference harness -> no deploy (ADR-001). Next: ISO9001->IATF16949.

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

2026-06-27 08:29:30 +02:00

3.8 KiB

Raw Blame History

Transition Knowledge Patterns (TKP) — 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).

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_pattern_isms_to_tisax_v1.yaml`	ISMS → TISAX	`draft` (L1)

Next candidates: ISO 9001 → IATF 16949, ISO 14001 → environmental regulation.

3.8 KiB Raw Blame History