# Transition Reasoning — Spezifikation v1.2 (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).
- **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}`.
- **`GeneratedQuestion`** (DERIVAT, nicht gespeichert) — `Control × Template`: `{control_id, intent, rendered_text, verifies_capability (MCAP), supports_obligations, expected_information_gain, confidence_impact, follow_up}`.
- **`TransitionAssessment`** (Output, **KEINE** Prozentzahlen) — je Required Capability `status ∈ {already_covered, probably_covered, needs_confirmation, missing, not_applicable, unsupported}` + nächste priorisierte Fragen.

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