# Kairo — Operating Model → Steering Bridge

**Status:** Architektur-Einordnung  
**Stand:** 2026-07-05  
**Zweck:** Ehrliche Antwort auf die Frage, ob AP0.8/0.9 auf spätere Steuerungslogik einzahlen — und was noch fehlt.

---

## 1. Kurzantwort

**Ja, aber indirekt.** AP0.8/0.9 haben das **Vokabular und die Persistenzschicht** des kanonischen Operating Models geliefert — nicht den **Steuerungsgraph**, nicht den **Lifecycle-Orchestrator** und nicht die **Method Registry**.

Das ist kein Versehen, sondern die dokumentierte Reihenfolge:

```text
Foundation (AP0.1–0.7)
  → Operating Model Entitäten (AP0.8–0.9)     ← wir sind hier
  → Integration & Validation (AP0.10)
  → Steering Core Foundation (Sprint 1 / AP1.x)
  → Method Registry, Hooks, Lifecycle Runtime
```

Ohne die Entitäten hätte Steering nichts zu lesen und zu steuern.  
Mit nur den Entitäten **ohne Verbindungslogik** wirkt Kairo zu Recht wie eine Sammlung paralleler Tabellen.

---

## 2. Was AP0.8/0.9 tatsächlich vorbereitet

| Baustein | Beitrag für späteres Steering | Noch nicht da |
|----------|------------------------------|---------------|
| **Entitäten** | Blocker, Backlog, Milestone, Evidence, Decision, Review, Recurring | SteeringContext, Project, Dependency |
| **Schwache FKs** | `blocker.action_id`, `evidence.action_id`, `review.action_id` | Pflicht-Struktur, Graph-Traversierung in UI |
| **Attention (Regeln 1–9)** | Proto-Signal-Engine, erklärbare DTOs | Methoden-spezifische Signal Rules, Ranking |
| **NextActionCandidates** | Regelbasierte Empfehlungen | Hook `on_next_action_requested`, Strategien |
| **Audit-Events** | Nachvollziehbarkeit für Agenten/Steering | Lifecycle-Audit-Kette |
| **Actor-Assignments** | Wer handelt | Waiting/Reminder/Escalation |
| **Status-Enums** | Anknüpfpunkte für Lifecycle-Transitions | State Machine + Guards |

**Fazit:** AP0.8/0.9 = **System of Record für OM-Objekte** + **regelbasierte Signale**.  
Das ist Schritt 5–7 der Evolutionslinie (`Kairo_System_Target_State_v0.1.md` §24), **nicht** Schritt 2–4 (Steering Core, Method Registry, Lifecycle).

---

## 3. Kanonisches Modell vs. Ist-Implementierung

### Soll (Canonical Operating Model)

```text
Initiative
  ├── Milestone
  ├── BacklogItem
  ├── Action
  │     ├── Assignment
  │     ├── Blocker      ← primär an Maßnahme
  │     └── Evidence     ← primär an Maßnahme
  ├── Decision
  ├── Review
  └── RecurringElement
```

### Ist (AP0.9)

```text
Initiative
  ├── [parallele Sektionen in UI]
  ├── Action (Liste)
  ├── Blocker (Liste, action_id optional)
  ├── Evidence (Liste, action_id optional)
  ├── …
```

**Lücke:** Objekte existieren, aber **Struktur und Flow sind nicht sichtbar**.  
Der Nutzer sieht Listen, keinen **Steuerungszustand** eines Vorhabens.

---

## 4. Was „Steuerungslogik“ später bedeutet

Aus `Kairo_Target_Architecture_Method_Driven_Adaptive_Steering_Core_v0.1.md`:

| Komponente | Rolle |
|------------|-------|
| **SteeringContext** | Bindet Initiative an Methode, Lifecycle, Domain |
| **Method Registry** | Liefert Structure Builder, Signal Rules, Strategien |
| **Standard Lifecycle** | intake → … → closure mit Guards |
| **Hook Registry** | `on_review_due`, `on_blocker_open`, `on_next_action_requested` |
| **Signal Engine** | Attention + NextAction aus Methode + Kontext |
| **Transition Orchestrator** | Statusänderung → Side Effects (unblock, review anstoßen) |

AP0.8/0.9 **ersetzen** das nicht — sie liefern die **Daten**, an die Hooks und Regeln andocken.

---

## 5. AP0.10 — Integration statt nur Validation

AP0.10 wird daher **zweigeteilt**:

### A) Operating Model Integration (technisch)

- **Steering-Snapshot** Read-Model: Initiative als verknüpfter Graph (Actions mit Blockern/Evidence/Reviews)
- **Operating Cycle Phase** (heuristisch, erklärbar): triage / execute / verify / review / adapt
- **Transition-Orchestrierung minimal:** z. B. Blocker gelöst → verknüpfte Maßnahme entblocken; Review abgeschlossen → Maßnahme weiterführen
- **UI:** Verknüpfungen sichtbar (Maßnahme ↔ Blocker/Evidence), nicht nur parallele Sektionen
- **Attention:** Regeln, die **Beziehungen** nutzen (Maßnahme blockiert + offener Blocker auf derselben Maßnahme)

### B) MVP Validation (fachlich)

Testvorhaben aus Roadmap (Kairo, Gewaltschutzkurs, …) — Prüffragen: Hilft es bei täglicher Steuerung? Fehlt was **wirklich** als Nächstes?

---

## 6. Evolutionspfad (konkret)

```text
AP0.10  Integration + Validation     ← nächster Schritt
AP1.0   backend/steering/ Foundation (SteeringContext, Lifecycle stub)
AP1.1   Method Registry minimal + Hook Registry
AP1.2   Signal Engine aus attention.py → steering/signals/
AP1.3   Transition Orchestrator (ersetzt operating_transitions.py)
Sprint 2+ Dependencies, Waiting, Method Profiles
```

**Regel:** Keine neuen parallelen Tabellen ohne OM-Bezug.  
Neue Arbeit muss either **verbinden**, **orchestratieren** oder **validieren**.

---

## 7. Leitfrage-Check

> Zahlt jede Entität auf „Welcher nächste Schritt bringt das Vorhaben voran?“ ein?

| Entität | Heute | Nach AP0.10 | Nach Steering Core |
|---------|-------|-------------|-------------------|
| Action | ✓ Commit/Execute | ✓ mit Kontext | ✓ NextAction-Ziel |
| Blocker | △ Signal | ✓ an Maßnahme | ✓ Hook on_blocker_open |
| Backlog | ✓ Triage | ✓ Convert-Flow | ✓ Structure Builder |
| Milestone | △ Signal at_risk | ✓ mit Reviews | ✓ Roadmap-Lane |
| Evidence | △ passive | ✓ an Maßnahme | ✓ Verify-Phase |
| Review | △ due signal | ✓ schließt Execute | ✓ Review Strategy |
| Decision | △ passive | △ Adapt-Hinweis | ✓ Adapt-Hook |
| Recurring | △ due signal | △ Routine-Hinweis | ✓ routine_control |

---

*v0.1 — Referenz für AP0.10 und Sprint-1-Planung*