breakpilot-compliance/docs-src/architecture/transition-reasoning-spec-v1.md

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:

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:

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)

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:

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

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

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.