Benjamin Admin
db2efe9f52
Aligns the spec with RS-005 v0: the Transition Planning Engine owns the INFORMATION GAPS (TransitionQuestionRequest), not the questions. Chain: Planning Engine -> TransitionQuestionRequest -> Question Renderer (RS-005.1) -> Interview. RS-005.1 (renderer/templates) deliberately deferred; GeneratedQuestion reframed as the renderer's output (a swappable policy layer), not part of the engine. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
162 lines
12 KiB
Markdown
162 lines
12 KiB
Markdown
# Transition Reasoning — Spezifikation v1.3 (zweiter Reasoning-Modus)
|
||
|
||
- **Status:** Proposal / Spec — 2026-06-27.
|
||
- **v1.1:** Interviewfragen werden **aus den Controls GENERIERT**, nicht als Bibliothek geschrieben.
|
||
- **v1.2:** **Wissensproduktion durch KI** — LLMs erzeugen den ersten Expertenentwurf (v. a. die
|
||
Priorisierung je Transition); BreakPilot **reviewt, versioniert und besitzt** die kanonische
|
||
Bibliothek. Plus die juristische Grenze (Expertenentwurf, kein Normbeweis).
|
||
- **v1.3 (Architektur präzisiert):** Die **Transition Planning Engine** besitzt die
|
||
**Informationslücken** (`TransitionQuestionRequest`), NICHT die Fragen. Kette:
|
||
`Planning Engine → TransitionQuestionRequest → Question Renderer (RS-005.1) → Interview`.
|
||
**RS-005 v0 (Planning Engine) GEBAUT** (`compliance/transition_reasoning/`, kein Endpoint,
|
||
konsumiert Company 2A + injizierte `TargetRequirement`). **RS-005.1 (Renderer/Templates) bewusst
|
||
VERSCHOBEN** — erst Wissensproduktion (kuratierte Transition Patterns in eigener Wissenssession),
|
||
dann der Renderer (ohne Inhalte wertlos; Inhalte ohne Renderer sofort wertvoll).
|
||
- **Scope:** erweitert die Reasoning-Session um einen zweiten Modus; ersetzt nichts.
|
||
- **Freeze-konform:** additiv, **kein** neuer Graph, **keine** Basisklasse, **keine** Meta-Model-Klasse. Nur ein neues Paket + Daten.
|
||
|
||
## Paradigmenwechsel
|
||
|
||
BreakPilot beantwortet **Migrationsfragen**, nicht Regelwerk-Fragen. Nicht `Regelwerk → Gap`,
|
||
sondern **`Ausgangszustand → Zielzustand → Delta`**. Ziel beliebig: `ISMS→TISAX`, `DSGVO→CRA`,
|
||
`ISO9001→IATF16949`, `MaschRL→MaschVO`, `CRA2025→CRA2028`. **Immer dieselbe Engine.**
|
||
|
||
## Kerneinsicht v1.1: Fragen sind ein DERIVAT, kein Bestand
|
||
|
||
Ihr besitzt bereits den teuren Teil: **~14.000 Master Controls** (aus ~400.000 atomaren Controls),
|
||
Legal Obligations, Capability Registry, Regulatory Map. Jedes Gesetz liefert deterministisch
|
||
`Gesetz → Obligation → Capability → Control → Evidence`. **Also dreht man die Richtung um:**
|
||
|
||
```text
|
||
Regelwerk → Obligation → Capability → Control → "welche Information fehlt, um diesen Control zu bewerten?"
|
||
```
|
||
|
||
Die Frage entsteht **aus dem Control**. Control `CTRL-712: „A documented vulnerability handling
|
||
process exists." (intent: verify_existence)` → automatisch „Gibt es einen dokumentierten
|
||
Vulnerability-Handling-Prozess?". Ingestiert ihr morgen die Abwasserverordnung, entstehen mit den
|
||
neuen Controls **automatisch** neue Interviewfragen. Passt zu *derived, not curated* + *computed, not stored*.
|
||
|
||
## Die drei Bausteine (statt einer „ISO-27001-Fragenbibliothek")
|
||
|
||
### 1. Control → Question Intent *(Corpus-/Control-Domäne — Compliance Execution / canonical_controls)*
|
||
Jeder kanonische Control trägt einen `question_intent`:
|
||
```yaml
|
||
CTRL-712: {statement: "A documented vulnerability handling process exists.", question_intent: verify_existence}
|
||
CTRL-145: {statement: "Security updates are provided for a defined period.", question_intent: determine_duration}
|
||
```
|
||
Annotation am Control, **kein** neuer Reasoning-Bestand.
|
||
|
||
### 2. Master Question Templates *(Reasoning — klein, ~30–40, versioniert)*
|
||
```yaml
|
||
verify_existence: "Gibt es einen dokumentierten {{subject}}?"
|
||
determine_duration: "Wie lange werden {{subject}} bereitgestellt?"
|
||
identify_owner: "Wer verantwortet {{subject}}?"
|
||
request_evidence: "Welchen Nachweis können Sie für {{subject}} bereitstellen?"
|
||
# ~30–40: existiert? / verantwortlich? / seit wann? / wie häufig? / wie dokumentiert? /
|
||
# welcher Nachweis? / wie lange? / wie geprüft? / wie gemessen? / wie freigegeben?
|
||
```
|
||
**Generierung:** `Control(statement + intent) × Template → Frage`. Die ~30–40 Templates **emergieren**
|
||
durch Clustern der Control-Statements nach Intent (dieselbe Dedup-Logik wie Master Controls). Das ist
|
||
die eigentliche „MDQ Registry": **kanonische Interview-Templates**, nicht handgeschriebene Fragen.
|
||
|
||
### 3. Transition-Priorisierung *(Reasoning — hier steckt das Expertenwissen)*
|
||
Zertifizierungen / Managementsysteme entscheiden, **welche** generierten Fragen noch gestellt werden:
|
||
```text
|
||
CRA → 217 Controls → 217 mögliche Fragen
|
||
ISO27001 → 165 „wahrscheinlich beantwortet" → 52 übrig
|
||
+ TISAX → 31 · + PSIRT → 24 · + SBOM → 19 ⟶ nur diese 19 werden gestellt.
|
||
```
|
||
Mechanik (**Wiederverwendung**): `Control → Capability` (Corpus) ∘ `Capability → wahrscheinlich-vorhanden`
|
||
(Cert→Capability-Mapping = Execution, Company 2A) → Control überspringen, wenn Capability `confirmed`/`probably`.
|
||
|
||
## Wissensproduktion (v1.2): KI erzeugt den Entwurf — BreakPilot besitzt die Bibliothek
|
||
|
||
Die Priorisierung (Baustein 3: „welche Bereiche deckt ISO 27001 für CRA typischerweise ab, wo sind die
|
||
Lücken?") ist **Expertenwissen**, keine Rechtsauslegung — genau das, was Berater heute leisten („Sie sind
|
||
ISO-27001-zertifiziert? Dann nehme ich ISMS/Incident/Lieferantenmgmt als gegeben an; reden wir über SBOM,
|
||
PSIRT, Security Updates."). **Das kann ein LLM als ersten Entwurf liefern.** Prozess umgedreht: nicht „LLM
|
||
beantwortet Compliance" — sondern „**LLM erstellt den Entwurf der Interview-/Priorisierungs-Bibliothek**".
|
||
|
||
**Offline-Workflow (NICHT zur Laufzeit):**
|
||
```text
|
||
LLM-A (z.B. "Du bist ISO27001 Lead Auditor") → Entwurf: skip-Liste + CRA-Delta-Fragen je Transition
|
||
LLM-B → kritisiert / findet Lücken LLM-C → ergänzt fehlende → Merge
|
||
→ BreakPilot-Review → versionierte MDQ/Transition Registry (Git) → Kundenfeedback → v2 → v3
|
||
```
|
||
Multi-Modell (Draft / Kritik / Ergänzung), dann menschlicher Review. **In Git landet die Bibliothek,
|
||
nicht die KI.** Das ist die *deterministisch-first*-Disziplin (LLM offline-propose, nie online-mutate).
|
||
|
||
**Eigentumswechsel:** nach ~50 Kunden ist die Bibliothek **kein Modellwissen mehr**, sondern euer
|
||
**kuratiertes, versioniertes Unternehmenswissen**. Die Engine arbeitet gegen `MDQ-00127 · Version 4 ·
|
||
reviewed 2026-09-18 · Freigabe BreakPilot` — **modell-unabhängig** (egal was GPT-7/Claude-6 morgen sagen).
|
||
Dieselbe Identitätsmaschine + Provenance wie Controls/Obligations/Capabilities.
|
||
|
||
**Initiative (Vorschlag): „1000 Master Delta Questions in 30 Tagen"** — strukturiert: (1) Zielregelwerk
|
||
wählen · (2) Ausgangszustände wählen (ISO27001/TISAX/ISO9001/ISO14001/IEC62443) · (3) LLM erstellt
|
||
Delta-Katalog · (4) zweites Modell prüft Lücken/Redundanz · (5) Review + Versionierung · (6) Kundenfeedback.
|
||
KI erzeugt den ersten Entwurf; **BreakPilot besitzt + pflegt die kanonische versionierte Bibliothek.**
|
||
|
||
## ⚠️ Grenze: Expertenentwurf, KEIN Normbeweis (durable)
|
||
|
||
Die Bibliothek ist ein **plausibler Expertenentwurf** (Berater-Heuristik), **NICHT** ein juristischer/
|
||
normativer Beweis, dass die Fragen exakt die Norm repräsentieren. Die Priorisierung „Zertifizierung deckt
|
||
X wahrscheinlich ab" ist **Welt 1** (`ClaimCoverage` — potenziell, mit Confidence + Verifikationsbedarf),
|
||
**nie** „erfüllt"/Norm-Abdeckungs-Beweis (Welt 2). Muss so gelabelt sein — sonst genau das
|
||
Compliance-Theater, das `anti-fake-evidence` verhindert. Eine `inferred`-Annahme aus „ISO27001 vorhanden"
|
||
wird erst durch echten Nachweis `confirmed`.
|
||
|
||
## Kernobjekte (`compliance/transition_reasoning/`)
|
||
|
||
- **`TransitionContext`** — `start_state` {company_context, product_profile, known_regulations/certifications, capabilities (2A)} + `target_state` {target_regulation | target_certification | target_framework}.
|
||
- **`TransitionGoal`** — Ziel (nicht regelwerk-beschränkt); auflösbar zu Obligations → Controls → Required Capabilities.
|
||
- **`MasterQuestionTemplate`** — `{intent, template_text, answer_type, expected_evidence, version, status, lifecycle}`.
|
||
- **`TargetRequirement`** (INJIZIERT, Execution-owned) — `{capability_id (MCAP), question_intent, expected_evidence, source_control_id, supports_obligations, unsupported}`. v0: injiziert; später aus `Obligation → Control → Required Capability` + `Control → question_intent`.
|
||
- **`TransitionQuestionRequest`** (das **OWNED Output** der Planning Engine — eine Informationslücke, **KEINE** Frage) — `{capability_id, control_id, reason, question_intent, expected_evidence, priority, information_gain}`. **Kein gerenderter Fragetext.**
|
||
- **`TransitionAssessment`** (Output, **KEINE** Prozentzahlen) — je Required Capability `CoverageStatus ∈ {already_covered, probably_covered, needs_confirmation, missing, not_applicable, unsupported}` + die priorisierten `TransitionQuestionRequest`s.
|
||
- **`GeneratedQuestion`** *(RS-005.1 Question Renderer — VERSCHOBEN, nicht in v0)* — `Request × (Control/Template) → {rendered_text, …}`. Das Rendern ist eine **austauschbare Policy-Schicht**, nicht Teil der Engine.
|
||
|
||
## Algorithmus — Delta-Interview als Optimierung
|
||
|
||
1. `TransitionGoal` → Obligations → Controls → Required Capabilities (MCAP).
|
||
2. `have` = Company Capability Profile (confirmed ∪ inferred ∪ declared) — 2A.
|
||
3. **Priorisierung/Skip** (Baustein 3): Controls überspringen, deren Capability wahrscheinlich vorhanden ist.
|
||
4. Übrige Controls: Frage via `Control × Template` **generieren** (Baustein 1+2), durch Product Map filtern.
|
||
5. **Nicht sequenziell** — iterativ die Frage mit dem **höchsten erwarteten Informationsgewinn** (Entropy Reduction) wählen; Antwort → `confidence_impact` → Profil aktualisiert → neu priorisieren. Abbruch, wenn nichts mehr nennenswert reduziert (**Ziel: 10–20**).
|
||
6. Ergebnis: aktualisiertes Capability Profile → `TransitionAssessment`.
|
||
|
||
**Information Gain** deterministisch + erklärbar (v1 `HIGH/MEDIUM/LOW`; v2 aus `observed`-Statistik
|
||
asked/changed/useless — Statistik gespeichert, Score abgeleitet; kein opaker ML-Score). **Confidence
|
||
Impact**: eine Antwort liefert Relation+Evidence → bestehende `evaluate_relation`-Policy (2C) berechnet den
|
||
Status neu (`inferred→confirmed`); die Frage speichert keine Confidence.
|
||
|
||
## Ownership (Freeze- und Domänen-konform)
|
||
|
||
| Domäne | besitzt |
|
||
|---|---|
|
||
| **Legal Knowledge** | Ziel-Regelwerke + Obligations |
|
||
| **Compliance Execution / canonical_controls** | (Master) Controls + `Control→question_intent`, `Control/Obligation→Required Capability`, MCAP, Cert→Capability-Mapping |
|
||
| **Reasoning (dieser Modus)** | Transition Engine, **Master Question Templates**, Fragen-Generierung, **Priorisierung/Skip**, Information Gain, Delta Interview, Assessment, kuratierte/versionierte **MDQ/Transition Registry** |
|
||
|
||
Reasoning **konsumiert** Controls + Required Capabilities + Cert→Capability-Mapping (injiziert; keine
|
||
Corpus-/Mapping-Daten im Produktcode). Keine neuen Mappings/Regelwerke/Controls, keine Meta-Model-Klasse.
|
||
|
||
## Akzeptanzkriterien (Demos → neue Reference-Suite-Szenarien)
|
||
|
||
- **ISMS → TISAX:** < 20 Fragen. · **DSGVO → CRA:** erkennt Datenschutz, fragt SBOM / Vuln Handling / Security Updates / Product Security. · **ISO9001 → IATF16949:** nur Delta-Fragen. · **CRA2025 → CRA2028:** RCI liefert Delta, Engine formuliert Interview. Jede Demo = Coverage-Zeile in der [[reference-scenario-suite]].
|
||
|
||
## Architektur-Invariante (→ [ADR-002](adr/ADR-002-transition-is-data-not-architecture.md))
|
||
|
||
1. **Keine vollständigen Regelwerke als Interviews — nur der minimale Informationsgewinn vom Ausgangs- in den Zielzustand.**
|
||
2. **Jede neue Transition entsteht AUSSCHLIESSLICH durch Daten** (Controls + question_intent, Cert→Capability-Priorisierung, ggf. neue Templates); Engine + Metamodell werden NICHT erweitert. → Interview-Engine wächst automatisch mit jedem Corpus; Handarbeit nur bei der Priorisierung.
|
||
|
||
## Naming & Sequenzierung
|
||
|
||
„Onboarding-Fragen" → **Transition Interview**. Abhängigkeit: `Control→question_intent` + `Control/Obligation→Capability`
|
||
+ Cert→Capability-Mapping (Execution/canonical_controls). Baubar als **v0** mit injizierten Controls/Mappings +
|
||
den ~30–40 Templates; v2 (computed Information Gain + Lern-Statistik) folgt. = Epic **RS-005** (verwandt mit RS-003).
|
||
**Spec jetzt, Bau pro Go; die MDQ-Bibliothek ist Wissensproduktion (Workflow), kein Code-Build.**
|
||
|
||
## Anhang
|
||
|
||
- 100 Beispiel-Fragen (v1) = Validierungsset + Quelle für Template-/Intent-Extraktion (nicht die Bibliothek): [`transition-reasoning/master-delta-questions-v1.md`](transition-reasoning/master-delta-questions-v1.md).
|