Benjamin Admin
0da093c046
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>
66 lines
3.8 KiB
Markdown
66 lines
3.8 KiB
Markdown
# 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`.
|