# ADR-002: Transition = Data, not Architecture

- **Status:** Accepted
- **Datum:** 2026-06-27
- **Typ:** Architektur-Entscheidung
- **Bezug:** [`../transition-reasoning-spec-v1.md`](../transition-reasoning-spec-v1.md), [[regulatory-intelligence-vision]], Architektur-Freeze v1.0

## Kontext

BreakPilot wird von einem Compliance-Fragebogen zu einer **Transition Engine**: sie beantwortet
`Ausgangszustand → Zielzustand → Delta` (z. B. ISO 27001 → CRA, ISMS → TISAX, MaschRL → MaschVO).
Das Risiko: jede neue regulatorische „Reise" als Engine- oder Metamodell-Erweiterung zu bauen — das
würde die Architektur mit jeder Transition aufblähen und genau den Effekt erzeugen, den der
Architektur-Freeze verhindern soll.

## Entscheidung

1. **BreakPilot modelliert keine vollständigen Regelwerke als Interviews — sondern ausschließlich
   den minimalen Informationsgewinn, der nötig ist, um einen vorhandenen Unternehmenszustand in
   einen gewünschten regulatorischen Zielzustand zu überführen.**

2. **Jede neue Transition (z. B. ISO 27001 → CRA oder ISMS → TISAX) muss ausschließlich durch neue
   Transition Patterns und Capability-/MDQ-Wissen (Daten) entstehen. Weder die Engine noch das
   Metamodell dürfen dafür erweitert werden.**

## Konsequenzen

- Jede neue regulatorische Reise ist ein **Datenproblem**, kein Architekturproblem — exakt das Ziel
  des Architektur-Freeze.
- Eine neue Transition besteht aus: neuen/wiederverwendeten **Master Delta Questions** (MDQ Registry),
  einem **Transition Pattern** (nur MDQ-Referenzen) und **Required-Capability-Wissen** (Compliance
  Execution). Kein neuer Code im Reasoning-Kern, keine neue Objektklasse im Metamodell.
- Wiederverwendung wird zum Normalfall: `IEC 62443 → CRA` teilt die meisten MDQs mit `ISO 27001 → CRA`
  und ergänzt nur wenige neue.
- Diese ADR ist non-runtime → kein Deploy (siehe [ADR-001](ADR-001-runtime-deploy-policy.md)).