Kairo-Jinkendo/docs/architecture/Kairo_Operating_Model_Steering_Bridge_v0.1.md

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:

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)

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

Ist (AP0.9)

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)

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