docs(spec): Transition Reasoning v1.2 — questions generated from controls + AI-drafted curated library

v1.1: interview questions are GENERATED from the existing (Master) Controls, not
hand-written. Three building blocks: Control->question_intent (corpus/Execution),
~30-40 Master Question Templates (Reasoning), Transition-Prioritization (certs decide
which generated questions can be skipped; 217->19 funnel, reuses Company 2A + cert map).

v1.2: knowledge production. LLMs produce the first expert DRAFT (the prioritization per
transition); BreakPilot reviews + versions + OWNS the canonical library (in Git, not the
AI; model-independent, MDQ-00127 v4). Offline multi-model workflow, NOT runtime
(deterministic-first: LLM offline-propose, never online-mutate). Hard boundary: the
library is an expert DRAFT, not a normative/legal proof -- "cert probably covers X" is
Welt-1 (ClaimCoverage), never "erfuellt" (anti-fake-evidence).

Reframes the 100 seed questions as validation/template-extraction set. Spec only, no
code; non-runtime docs -> no deploy (ADR-001).

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

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

@@ -1,139 +1,152 @@
-# Transition Reasoning — Spezifikation v1 (zweiter Reasoning-Modus)
+# Transition Reasoning — Spezifikation v1.2 (zweiter Reasoning-Modus)
 
-- **Status:** Proposal / Spec v1 — 2026-06-27
+- **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`**. Der Kunde sagt nicht „Hilf mir beim CRA",
+sondern **`Ausgangszustand → Zielzustand → Delta`**. Ziel beliebig: `ISMS→TISAX`, `DSGVO→CRA`,
-sondern „Hilf mir von meinem heutigen Zustand zu meinem regulatorischen Zielzustand". Das Ziel ist
+`ISO9001→IATF16949`, `MaschRL→MaschVO`, `CRA2025→CRA2028`. **Immer dieselbe Engine.**
-beliebig: `ISMS→TISAX`, `DSGVO→CRA`, `ISO9001→IATF16949`, `MaschRL→MaschVO`, `CRA2025→CRA2028`.
-**Immer dieselbe Engine.**
 
-Die Fragenbibliothek enthält **kein** ISO27001-Wissen, sondern **Wissen über die Differenz**:
+## Kerneinsicht v1.1: Fragen sind ein DERIVAT, kein Bestand
-nicht `ISO27001 → 100 Fragen`, sondern `ISO27001 → CRA → 12 Delta-Fragen`. Das ist viel kleiner.
 
-## Verhältnis zur bestehenden Architektur (erweitern, NICHT ersetzen)
+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:**
 
-- Zweiter Modus **neben** Compliance Reasoning (`Produkt → Applicable → Obligations → Interpretation → Gap`). Neues Paket `backend-compliance/compliance/transition_reasoning/`.
+```text
-- **Transition Reasoning ist RCI verallgemeinert.** RCI ist der Spezialfall „start = heute, target = heute + Änderung". Demo `CRA2025→CRA2028` **ist** RCI. `assess_transition` ist Geschwister von `assess_change`.
+Regelwerk → Obligation → Capability → Control → "welche Information fehlt, um diesen Control zu bewerten?"
-- **Wiederverwendung (kein neuer Kern):** Company Capability Profile (Phase 2A) = „habe" · Master Capability Registry (Phase 2C, `MCAP`) = stabile Identitäten + computed status · RCI = Delta-Mechanik · Reference Scenario Suite = Demos/Coverage **und** Lern-Signal für Information Gain.
+```
+
+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, known_certifications, declared/inferred/confirmed capabilities (aus Company 2A)} + `target_state` {target_regulation | target_certification | target_framework}.
+- **`TransitionContext`** — `start_state` {company_context, product_profile, known_regulations/certifications, capabilities (2A)} + `target_state` {target_regulation | target_certification | target_framework}.
-- **`TransitionGoal`** — das Ziel; **nicht** regelwerk-beschränkt. Auflösbar zu **Required Capabilities** (Execution-owned, injiziert).
+- **`TransitionGoal`** — Ziel (nicht regelwerk-beschränkt); auflösbar zu Obligations → Controls → Required Capabilities.
-- **`TransitionAssessment`** (Output, **KEINE** Prozentzahlen) — je Required Capability `status ∈ {already_covered, probably_covered, needs_confirmation, missing, not_applicable, unsupported}` + die nächsten priorisierten MDQs.
+- **`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}`.
-## MDQ Registry — das Herzstück (4. Identitätsmaschine-Instanz)
+- **`TransitionAssessment`** (Output, **KEINE** Prozentzahlen) — je Required Capability `status ∈ {already_covered, probably_covered, needs_confirmation, missing, not_applicable, unsupported}` + nächste priorisierte Fragen.
-
-Nach **Master Controls → Master Obligations → Master Capabilities** folgt **Master Delta Questions**.
-Kernumkehr: **Die Frage ist nicht das Primäre — sie ist eine Messsonde, um Unsicherheit über
-Capabilities zu reduzieren.** Jede Frage ist eine **identifizierbare, versionierte Wissenseinheit**.
-
-**`MasterDeltaQuestion` (MDQ)** — stabile Identität, versioniert (genau wie Master Controls):
-
-```yaml
-id: MDQ-00017
-question: "Wie lange stellen Sie Sicherheitsupdates für dieses Produkt bereit?"
-answer_type: duration            # | yes_no_document | enum | ...
-verifies: [MCAP-00042]           # welche Operational Capability(s) — Execution-owned
-supports_obligations: [CRA.OBL.145, CRA.OBL.233]
-transition_patterns: [ISO27001->CRA, IEC62443->CRA, TISAX->CRA]   # nur Referenzen
-expected_evidence: [support_policy, product_lifecycle_policy]
-information_gain: HIGH            # v1 statisch -> v2 computed (Entropy Reduction)
-confidence_impact:               # die Antwort MUTIERT den Trust State (via 2C-Policy)
-  document_uploaded: {MCAP-00042: "inferred -> confirmed"}
-certs_that_reduce_probability: [ISO27001]
-certs_that_do_not_reduce_probability: [ISO9001]
-follow_up:
-  if_unknown: MDQ-00018
-  if_below_required: MDQ-00021
-  if_no: TRANSITION_BLOCK
-# versionierung + lifecycle (wie Master Controls)
-version: 1
-status: active                   # | deprecated
-created: <ts>; deprecated: null; redirect_to: null
-provenance: {author, basis}
-# v2, strukturell vorgesehen (NICHT v1): Lern-Statistik
-observed: {asked: 0, changed_assessment: 0, useless: 0, average_information_gain: null}
-```
-
-- **`verifies → MCAP`:** die MDQ misst eine Operational Capability (Execution-owned `MCAP`-id). **Indexierung nach Capability, NICHT nach Regelwerk** → Wiederverwendung über Transitions.
-- **`confidence_impact` = Bindeglied zur 2A/2C-Trust-Mechanik:** eine Antwort liefert eine Relation + Evidence (z. B. „Dokument hochgeladen" = `confirms` + `artifact`), aus der die bestehende `evaluate_relation`-Policy (Master Capability Registry) den Status **neu berechnet** (`inferred → confirmed`). Die MDQ **speichert keine Confidence** — sie erzeugt den Input, der computed-not-stored ausgewertet wird. Mutiert das Company Capability Profile (2A).
-- **Identitäts-Disziplin = dieselbe wie Controls/Obligations/Capabilities:** `Candidate → Dedup → stabile MDQ-id → Relationen → Versionierung → Lifecycle (merge/deprecate/redirect)`. Ziel: **~300–500 Master Delta Questions** statt tausender Einzelfragen.
-
-## Transition Patterns (nur Referenzen)
-
-Ein Pattern speichert **keine** Fragen-Texte, nur MDQ-Referenzen:
-
-```text
-TransitionPattern  ISO27001 -> CRA  = [MDQ-17, MDQ-21, MDQ-33, MDQ-52, ...]
-```
-
-Folge: eine neue Transition `IEC62443 -> CRA` = großteils Wiederverwendung + wenige neue MDQs
-(z. B. 3 neue statt 30). Patterns liefern **Candidate Questions**; die **Product Map filtert**
-(dieselbe Transition braucht beim Maschinenbauer andere Fragen als beim SaaS-Unternehmen).
 
 ## Algorithmus — Delta-Interview als Optimierung
 
-1. `TransitionGoal` → Required Capabilities (MCAP-Set) — **Execution, injiziert**.
+1. `TransitionGoal` → Obligations → Controls → Required Capabilities (MCAP).
-2. `have` = Company Capability Profile (confirmed ∪ inferred ∪ declared) — **2A**.
+2. `have` = Company Capability Profile (confirmed ∪ inferred ∪ declared) — 2A.
-3. Delta je Required Capability → status; unsichere (`probably_covered` / `needs_confirmation` / `missing`) bleiben offen.
+3. **Priorisierung/Skip** (Baustein 3): Controls überspringen, deren Capability wahrscheinlich vorhanden ist.
-4. Candidate-MDQs aus dem/den Transition Pattern(s), **gefiltert durch die Product Map**.
+4. Übrige Controls: Frage via `Control × Template` **generieren** (Baustein 1+2), durch Product Map filtern.
-5. **Nicht sequenziell** — die Engine wählt iterativ die MDQ mit dem **höchsten erwarteten Informationsgewinn** für DIESEN Kunden (Entropy Reduction über die unsicheren Required Capabilities). Antwort → `confidence_impact` → Profil aktualisiert → neu priorisieren. Abbruch, wenn keine MDQ mehr nennenswert Unsicherheit reduziert (**Ziel: 10–20 Fragen, nicht 150**).
+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` bzw. deterministischer Score
+**Information Gain** deterministisch + erklärbar (v1 `HIGH/MEDIUM/LOW`; v2 aus `observed`-Statistik
-= #unsichere Required Capabilities, die die Antwort auflöst × #abhängige Ziel-Obligations (− Redundanz).
+asked/changed/useless — Statistik gespeichert, Score abgeleitet; kein opaker ML-Score). **Confidence
-v2 = verfeinert aus `observed`-Statistik (asked / changed_assessment / useless) realer Kunden +
+Impact**: eine Antwort liefert Relation+Evidence → bestehende `evaluate_relation`-Policy (2C) berechnet den
-Reference-Suite — aber **erklärbar, kein opaker ML-Score** (sonst die „0.58-Theater"-Falle). Gespeichert
+Status neu (`inferred→confirmed`); die Frage speichert keine Confidence.
-werden Statistik-Fakten, **abgeleitet** wird der Score → computed-not-stored.
 
 ## Ownership (Freeze- und Domänen-konform)
 
 | Domäne | besitzt |
 |---|---|
 | **Legal Knowledge** | Ziel-Regelwerke + Obligations |
-| **Compliance Execution** | Required Capabilities (`obligation → required MCAP`), MCAP / Capability Registry |
+| **Compliance Execution / canonical_controls** | (Master) Controls + `Control→question_intent`, `Control/Obligation→Required Capability`, MCAP, Cert→Capability-Mapping |
-| **Reasoning (dieser Modus)** | Transition Engine, Priorisierung (Information Gain), Delta Interview, Assessment, **MDQ Registry** (Fragen-Wortlaut + Relationen + Versionierung + Follow-up) |
+| **Reasoning (dieser Modus)** | Transition Engine, **Master Question Templates**, Fragen-Generierung, **Priorisierung/Skip**, Information Gain, Delta Interview, Assessment, kuratierte/versionierte **MDQ/Transition Registry** |
 
-Reasoning **konsumiert** Required Capabilities (injiziert — wie 2As `EMPTY_MAPPING`, keine
+Reasoning **konsumiert** Controls + Required Capabilities + Cert→Capability-Mapping (injiziert; keine
-Required-Capability-Daten im Reasoning-Produktcode). **Keine** neuen Capability-Mappings, **keine**
+Corpus-/Mapping-Daten im Produktcode). Keine neuen Mappings/Regelwerke/Controls, keine Meta-Model-Klasse.
-neuen Regelwerke, **keine** Meta-Model-Klasse.
 
 ## Akzeptanzkriterien (Demos → neue Reference-Suite-Szenarien)
 
-- **ISMS → TISAX:** Engine stellt **< 20 Fragen** (nicht 150).
+- **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]].
-- **DSGVO → CRA:** erkennt vorhandenen Datenschutz, fragt gezielt **SBOM / Vulnerability Handling / Security Updates / Product Security**.
-- **ISO9001 → IATF16949:** **nur** Delta-Fragen.
-- **CRA2025 → CRA2028:** RCI liefert das Delta, Transition Engine formuliert daraus das Interview.
 
-Jede Demo wird eine Coverage-Zeile in der [[reference-scenario-suite]] (`Transition` TODO → PASS).
+## Architektur-Invariante (→ [ADR-002](adr/ADR-002-transition-is-data-not-architecture.md))
 
-## 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.
 
-1. **BreakPilot modelliert keine vollständigen Regelwerke als Interviews — sondern ausschließlich den minimalen Informationsgewinn, der nötig ist, um einen Ausgangszustand in einen regulatorischen Zielzustand zu überführen.**
+## Naming & Sequenzierung
-2. **Jede neue Transition entsteht AUSSCHLIESSLICH durch neue Transition Patterns + Capability-/MDQ-Wissen (DATEN). Weder die Engine noch das Metamodell werden dafür erweitert.**
 
-→ Jede neue regulatorische Reise ist ein **Datenproblem**, kein Architekturproblem (= das Ziel des Architektur-Freeze).
+„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 +
-## Naming
+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.**
-„Onboarding-Fragen" → **Transition Interview**. Es fragt nicht „Wie arbeiten Sie?", sondern „Was
-müssen wir noch wissen, um Ihren heutigen Zustand zuverlässig in den Zielzustand zu überführen?".
-
-## Sequenzierung / Abhängigkeit (ehrlich)
-
-Voller Wert braucht **Executions Required-Capabilities-pro-Obligation + MCAP-IDs** (dieselbe
-Abhängigkeit wie RS-003 Company-Gap). Baubar als **v0 in der Reasoning-Spur** mit injizierten
-Required-Capabilities + kleiner Seed-MDQ-Library (wie Company 2A injizierte Mappings konsumierte);
-v2 (computed Information Gain + Lern-Statistik) folgt strukturell. = neues Epic **RS-005 Transition
-Reasoning + MDQ Registry**, eng verwandt mit RS-003. **Spec jetzt, Bau pro Go.**
 
 ## Anhang
 
-- Master Delta Questions v1 (100 Seed-Fragen): [`transition-reasoning/master-delta-questions-v1.md`](transition-reasoning/master-delta-questions-v1.md).
+- 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).
-- Architektur-Entscheidung: [`adr/ADR-002-transition-is-data-not-architecture.md`](adr/ADR-002-transition-is-data-not-architecture.md).

docs-src/architecture/transition-reasoning/master-delta-questions-v1.md

@@ -13,12 +13,17 @@
 - Die Bibliothek schließt **nur die Unsicherheit dazwischen** → dieselbe Frage in vielen Übergängen
   wiederverwendbar. Erwartung: am Ende **~300–500 Master Delta Questions**, nicht 5.000.
 
-## v1 → v2 (Ziel)
+## Rolle dieser Liste (nach Spec-Revision v1.1/v1.2)
 
-Diese 100 sind v1: noch nach Themen gruppiert, noch **un-indexiert**. v2 hebt jede Frage in das
+Diese 100 sind **NICHT die Bibliothek**. Laut Spec v1.1 werden Fragen aus den **Controls generiert**
-MDQ-Schema (siehe Spec): `id (MDQ-xxxxx)` · `verifies: [MCAP-id]` · `supports_obligations` ·
+(`Control × Master Question Template`), nicht von Hand geschrieben; das Expertenwissen steckt in der
-`transition_patterns` · `expected_evidence` · `information_gain` · `confidence_impact` · `follow_up`
+**Priorisierung** (welche Frage eine Zertifizierung überspringbar macht), die laut v1.2 als LLM-Entwurf
-· `version/status/lifecycle`. Erst dann werden sie zur **MDQ Registry** (4. Identitätsmaschine-Instanz).
+entsteht und dann von BreakPilot **reviewt + versioniert + besessen** wird. Diese 100 dienen daher als:
+- **Validierungsset** — entsteht aus dem Generate-from-Controls-Pfad eine vergleichbare Frage?
+- **Quelle für die ~30–40 Master Question Templates** (Intents per Clustern extrahieren).
+- **Seed/Beispiel** für den „1000 MDQ in 30 Tagen"-Workflow.
+
+Siehe [`../transition-reasoning-spec-v1.md`](../transition-reasoning-spec-v1.md) (v1.2).
 
 ---