diff --git a/architecture/07-runtime-layout.md b/architecture/07-runtime-layout.md
index 792b9a2..a0c7be6 100644
--- a/architecture/07-runtime-layout.md
+++ b/architecture/07-runtime-layout.md
@@ -13,7 +13,11 @@ Jedes Modul besitzt genau ein eigenes Unterverzeichnis.
 /run/tuxflotte/
 ├── network/
 ├── hardware/
+├── enrollment/
 ├── server/
+├── provisioning/
+├── assignment/
+├── installation/
 ├── runtime/
 ├── backend/
 └── logs/
@@ -26,9 +30,21 @@ Besitzer: 05_network.sh
 hardware/
 Besitzer: 10_hardware.sh
 
+enrollment/
+Besitzer: 12_enrollment_auth.sh
+
 server/
 Besitzer: 15_server_handshake.sh
 
+provisioning/
+Besitzer: 17_device_status.sh
+
+assignment/
+Besitzer: 20_profile_selection.sh
+
+installation/
+Besitzer: 25_installation_confirm.sh
+
 runtime/
 Besitzer: Runtime-Builder
 
@@ -47,7 +63,11 @@ Andere Modulverzeichnisse dürfen nur gelesen werden, wenn dies für den definie
 Beispiele:
 
 - 10_hardware.sh schreibt nur nach /run/tuxflotte/hardware/
-- 15_server_handshake.sh liest aus /run/tuxflotte/network/ und /run/tuxflotte/hardware/
+- 12_enrollment_auth.sh schreibt nur nach /run/tuxflotte/enrollment/
+- 15_server_handshake.sh liest aus /run/tuxflotte/network/, /run/tuxflotte/hardware/ und /run/tuxflotte/enrollment/
+- 17_device_status.sh liest aus /run/tuxflotte/server/ und schreibt nach /run/tuxflotte/provisioning/
+- 20_profile_selection.sh liest aus /run/tuxflotte/server/ und schreibt nach /run/tuxflotte/assignment/
+- 25_installation_confirm.sh liest aus /run/tuxflotte/assignment/ und schreibt nach /run/tuxflotte/installation/
 - Der Runtime-Builder liest aus /run/tuxflotte/server/
 - Der Backend-Orchestrator liest aus /run/tuxflotte/runtime/
 
diff --git a/architecture/10-interactive-provisioning-flow.md b/architecture/10-interactive-provisioning-flow.md
index 383e12e..f1c7fa6 100644
--- a/architecture/10-interactive-provisioning-flow.md
+++ b/architecture/10-interactive-provisioning-flow.md
@@ -15,41 +15,98 @@ Boot
   ↓
 Netzwerk initialisieren
   ↓
-Aktivierungscode erfassen
+Hardware und Geräteidentität erfassen
+  ↓
+Enrollment-Autorisierung erfassen
   ↓
 Provisioning Handshake
   ↓
 Gerät und Organisation erkennen
   ↓
-verfügbare Profile anzeigen
+Gerätestatus anzeigen
   ↓
-Profil auswählen
-  ↓
-Installationsplan anzeigen
-  ↓
-Installation explizit bestätigen
-  ↓
-Commit Point
-  ↓
-Runtime Blueprint
-  ↓
-Backend
-  ↓
-Native Installation
-
-
-Also:
-
-```markdown
-  ↓
-Native Installation
+Provisionierung fortsetzen?
+  ├── nein → kontrollierter Abbruch
+  └── ja
+       ↓
+     verfügbare Profile anzeigen
+       ↓
+     Profil auswählen
+       ↓
+     Installationsplan anzeigen
+       ↓
+     Installation explizit bestätigen
+       ↓
+     Commit Point
+       ↓
+     Runtime Blueprint
+       ↓
+     Backend
+       ↓
+     Native Installation
+```
 
 ## Runtime-Zustände
 
 Der interaktive Provisionierungsablauf übergibt seinen Zustand über klar getrennte Runtime-Verzeichnisse unter `/run/tuxflotte/`.
 
+### Enrollment-Autorisierung
+
+Die Autorisierung des Provisionierungsvorgangs wird unter folgendem Pfad gespeichert:
+
+```text
+/run/tuxflotte/enrollment/
+└── authorization.json
+```
+
+`authorization.json` enthält den für den aktuellen Provisionierungsvorgang vorbereiteten Autorisierungszustand.
+
+Im aktuellen Bootstrap-Modell wird ein temporärer Aktivierungscode verwendet.
+
+Beispiel:
+
+```json
+{
+  "schema_version": 1,
+  "authorization_type": "bootstrap_activation_code",
+  "activation_code": "LAB-2026-START"
+}
+```
+
+Der Provisioning Handshake besitzt keinen eigenen Fallback-Aktivierungscode.
+
+Fehlt eine gültige Enrollment-Autorisierung, muss der Handshake abgebrochen werden.
+
+Der Bootstrap-Aktivierungscode ist ein Übergangsmechanismus und wird langfristig durch Benutzeranmeldung oder Enrollment Sessions ersetzt.
+
+### Provisionierungsentscheidung
+
+Die Entscheidung, ob der interaktive Provisionierungsablauf nach Anzeige des Gerätestatus fortgesetzt werden soll, wird unter folgendem Pfad gespeichert:
+
+```text
+/run/tuxflotte/provisioning/
+└── state.env
+```
+
+Der Zustand enthält:
+
+```bash
+TUXFLOTTE_PROVISIONING_CONTINUE=true
+```
+
+oder:
+
+```bash
+TUXFLOTTE_PROVISIONING_CONTINUE=false
+```
+
+Bei `false` beendet der Orchestrator den Provisionierungsvorgang kontrolliert und erfolgreich.
+
+Fehlt die Zustandsdatei oder enthält sie einen unbekannten Wert, muss der Orchestrator den Ablauf mit einem Fehler beenden.
+
+
 ### Aktivierung
-.
+
 Die Aktivierungsphase verwendet die bereits bestehende Server-Runtime:
 
 ```text
@@ -213,7 +270,9 @@ Der Interactive Provisioning Flow wird durch folgende Module umgesetzt:
 ```text
 05_network.sh
 10_hardware.sh
+12_enrollment_auth.sh
 15_server_handshake.sh
+17_device_status.sh
 20_profile_selection.sh
 25_installation_confirm.sh
 30_runtime_blueprint.sh