# Kairo – System Target State ## v0.1 – Zielzustand des angedachten Gesamtsystems > **Hinweis (2026-07-05):** Beschreibt das **Zielbild**, nicht den Implementierungsstand. Ist-Stand: [`Kairo_Implementation_Truth_Table_v0.1.md`](../product/Kairo_Implementation_Truth_Table_v0.1.md). v0.2 wird explizite Implementierungs-Marker pro Kapitel ergänzen. **Status:** konsolidiertes Zielbild / Nordstern-Dokument **Stand:** 2026-07-05 **Zweck:** Beschreibung des angedachten späteren Zielzustands von Kairo als System, unabhängig von konkreten Implementierungsschnitten. --- ## 1. Executive Summary Kairo ist langfristig keine einfache Aufgabenliste, keine reine Projektmanagement-App, kein Roadmap-Tool und keine freie Workflow-Automatisierungsplattform. Kairo ist eine: ```text adaptive, methodengeführte Entwicklungs- und Steuerungsplattform ``` Der Kern ist ein: ```text Method-driven Adaptive Steering Core ``` Kairo soll unterschiedliche Entwicklungs- und Steuerungskontexte führen können: ```text - Software- und Produktentwicklung - Buch- und Content-Entwicklung - Programmsteuerung - Projekt- und Initiativensteuerung - persönliche Entwicklung - Reifegradentwicklung - Lernpfade - Routinen / Betrieb - Review- und Auditkontexte - Agentenläufe - KI-/Tool-gestützte Steuerung ``` Die zentrale Leitfrage lautet: ```text Welcher nächste Schritt bringt diesen steuerbaren Kontext jetzt am wirksamsten voran? ``` --- ## 2. Grundverständnis Kairo steuert nicht nur Aufgaben. Kairo steuert Entwicklungen. Eine Entwicklung kann sein: ```text - ein Produkt - ein Programm - ein Projekt - eine Initiative - ein Buch - eine Fähigkeit - ein Reifegradziel - eine Routine - ein Review - ein Audit - ein Agentenauftrag ``` Kairo hält dabei fest: ```text - Was soll entwickelt werden? - Warum ist es relevant? - Welche Methode gilt? - Welche Struktur braucht diese Methode? - Wo steht der Kontext aktuell? - Was fehlt? - Was blockiert? - Was braucht Aufmerksamkeit? - Was ist der nächste wirksame Schritt? - Wer oder welcher Agent soll handeln? - Worauf wartet Kairo? - Welche Nachweise, Reviews oder Entscheidungen sind nötig? - Wann wird angepasst, eskaliert oder abgeschlossen? ``` --- ## 3. Produktidentität Kairo ist: ```text System of Record Steering Authority Actor-/Tenant-sicherer Kontextgeber methodengeführter Steuerungskern Roadmap- und Entwicklungsstrukturmodell Signal- und NextAction-System später Workflow-/Agenten-/Tool-orchestrierend ``` Kairo ist nicht: ```text freie Workflow-Plattform beliebiger Automatisierungsbaukasten reines Projektmanagementsystem reine To-do-Liste reines Roadmap-Tool reine KI-Agentenplattform reines Prompt-System ``` --- ## 4. Kernmodell Das Zielmodell: ```text Steerable Object → Steering Context → Steering Method → Standard Lifecycle / Method Lifecycle → Hook Slugs → Structure Builder → Signal Rules → NextAction Strategy → Assignment Strategy → Waiting / Reminder / Escalation Strategy → Result Intake → Evidence / Review / Decision → Adaptation / Closure → optionale Workflow-Fragmente → optionale Human / Agent / LLM / Tool Steps ``` --- ## 5. Method-driven Adaptive Steering Core Der Adaptive Steering Core ist der fachliche und technische Kern von Kairo. Er führt steuerbare Kontexte durch methodengeführte Steuerungsabläufe. Typischer Ablauf: ```text 1. Ziel / Entwicklungsabsicht erfassen 2. Name, Scope und Kontext definieren 3. passende Basismethode wählen oder vorschlagen 4. gemäß Methode eine Steuerungsstruktur erzeugen - Roadmap - Backlog - WBS - Reifegradpfad - Kapitelstruktur - Feature Landscape - WorkCycles - Review Gates 5. Next Best Action ableiten 6. Actor zuweisen 7. auf Ergebnis, Rückmeldung, Termin oder Ereignis warten 8. erinnern, eskalieren oder nachsteuern 9. Ergebnis zurückführen 10. prüfen, reviewen, adaptieren oder abschließen ``` Dieser Ablauf ist der methodengeführte Steuerungsworkflow. Er ist nicht gleichbedeutend mit einer freien technischen Workflow Engine. --- ## 6. Standard Lifecycle Kairo besitzt einen minimalen Standard Lifecycle als gemeinsame Basis. ```text intake method_selection structure_setup planning action_selection assignment waiting result_intake validation review adaptation closure ``` Methoden können diesen Lifecycle: ```text - verwenden - teilweise überspringen - spezialisieren - erweitern - eigene Hooks ergänzen ``` Der Standard Lifecycle ist kein starrer Projektprozess, sondern ein gemeinsames Steuerungsraster. --- ## 7. Steering Methods Eine Methode ist kein Label, sondern ein registriertes Steuerungspaket. Eine Methode definiert: ```text - supported_domains - supported_scope_types - default_lifecycle - required_structures - allowed_structures - hook_slugs - structure_builders - attention_rule_providers - next_action_strategy - assignment_strategy - waiting_strategy - reminder_strategy - escalation_strategy - result_intake_strategy - review_strategy - evidence_policy - closure_policy - allowed_workflow_fragments - allowed_node_types - default_configuration ``` Methoden werden zunächst built-in und code-first angelegt, später versioniert und begrenzt konfigurierbar. Langfristig können Method Profiles entstehen. --- ## 8. Method Registry Kairo benötigt eine Method Registry. Sie funktioniert ähnlich einem Widget-System: ```text Eine Methode meldet sich mit Slug, Version, unterstützten Domains, Lifecycle, Hooks, Structure Builders, Strategies und Policies an. ``` Ziel: ```text Neue Methoden sollen ergänzt werden können, ohne den Core jedes Mal umzubauen. ``` Beispiele für Methoden: ```text simple_action_driven product_milestone_driven backlog_driven wbs_driven cycle_based content_chapter_based maturity_progression routine_control review_driven audit_driven agent_controlled ``` --- ## 9. Steering Domains Kairo unterstützt unterschiedliche Steuerungsdomänen. Beispiele: ```text program project product_development content_development personal_development maturity_development routine_operations audit_review agent_execution custom ``` Jede Domain kann eigene typische Lifecycles, Roadmap-Strukturen, Methoden, Hooks und Signals haben. --- ## 10. Steerable Objects Steuerbar sind nicht nur Initiativen. Mögliche steuerbare Objekte: ```text program initiative project roadmap roadmap_item backlog_item action blocker review evidence decision recurring_element work_cycle agent_run custom ``` Diese Objekte werden über Steering Contexts an Methoden und Domains gebunden. --- ## 11. Steering Context Ein Steering Context beschreibt: ```text Für welches steuerbare Objekt gilt welche Methode, Domain und Lifecycle-Logik? ``` Konzeptuell: ```text SteeringContext - tenant_id - scope_type - scope_id - steering_domain - lifecycle_model - steering_method - method_profile_id optional - method_version - configuration_json - inherits_from_parent - is_active ``` Untergeordnete Objekte können den Steering Context ihres Parents erben oder überschreiben. --- ## 12. Roadmap / Development Model Roadmap ist ein Kernmodell, nicht nur eine UI-Ansicht. Kairo braucht Roadmaps, um Entwicklungsrichtung und Entwicklungsstruktur abzubilden. Roadmap-Struktur: ```text Roadmap → Roadmap Lane → Roadmap Item ``` RoadmapItems können sein: ```text milestone maturity_stage feature capability phase release chapter research_topic work_cycle learning_step review_gate decision_gate architecture_step dependency risk_reduction custom ``` Entscheidung: ```text Milestone = RoadmapItem(type = milestone) ``` --- ## 13. Roadmap vs. Backlog vs. Action Zentrale Unterscheidung: ```text RoadmapItem = Entwicklungsziel / Orientierung / geplanter Entwicklungsschritt BacklogItem = konkreter möglicher Handlungsbedarf Action = freigegebene operative Maßnahme ``` Beispiel Softwareentwicklung: ```text RoadmapItem: Attention Engine regelbasiert BacklogItems: - Attention DTO definieren - Blockierte Maßnahmen auswerten - Widget bauen Actions: - Endpoint implementieren - Tests schreiben ``` Beispiel Buchentwicklung: ```text RoadmapItem: Kapitel 3 – Argumentation ausarbeiten BacklogItems: - Recherche zur These prüfen - Beispiel suchen - Rohfassung schreiben Actions: - Heute Abschnitt 3.1 entwerfen ``` Beispiel Reifegradentwicklung: ```text RoadmapItem: Reifegrad: stabile Seitkick-Beweglichkeit BacklogItems: - Hüftmobilität prüfen - Dehnroutine auswählen - Technikvideo aufnehmen Actions: - 10 Minuten Mobility durchführen ``` --- ## 14. Structure Builder Structure Builder erzeugen methodenspezifische Steuerungsstrukturen. Beispiele: ```text roadmap_builder milestone_plan_builder feature_landscape_builder wbs_builder backlog_builder maturity_path_builder chapter_structure_builder cycle_structure_builder review_gate_builder routine_structure_builder ``` Sie sind zentrale Erweiterungspunkte für Methoden. Ein Structure Builder legt z. B. an: ```text - Roadmap - Roadmap Lanes - Roadmap Items - initiale BacklogItems - Review Gates - WorkCycles ``` --- ## 15. Hooks Hooks sind stabile Einhängepunkte in Steuerungsabläufen. Beispiele: ```text on_goal_captured on_scope_named on_method_selection_required on_method_selected on_structure_required on_roadmap_required on_backlog_required on_wbs_required on_maturity_path_required on_content_structure_required on_plan_required on_dependency_analysis_required on_dod_definition_required on_next_action_requested on_assignment_required on_wait_started on_due_date_reached on_result_overdue on_reminder_required on_escalation_required on_result_received on_evidence_required on_review_due on_reassessment_required on_replan_required on_closure_requested ``` An Hooks können später kleine Workflow-Fragmente, Rules, Prompts, Agent Steps oder Tool Steps gebunden werden. Hooks sind nicht beliebige technische Events, sondern fachlich stabile Steuerungspunkte. --- ## 16. Strategies Methoden bringen oder referenzieren Strategies. Zentrale Strategy-Typen: ```text NextActionStrategy AttentionRuleProvider AssignmentStrategy WaitingStrategy ReminderStrategy EscalationStrategy ResultIntakeStrategy EvidencePolicy ReviewStrategy ClosurePolicy ``` Diese verhindern, dass methodenspezifische Logik monolithisch im Core wächst. --- ## 17. Signals Signals sind sichtbare Ausgaben des Steuerungskerns. Signal Types: ```text attention next_action review_due evidence_required escalation blocker_signal progress_signal risk_signal decision_required dependency_signal dod_signal workflow_trigger ``` ### Attention Beantwortet: ```text Was braucht Aufmerksamkeit? ``` ### NextActionCandidate Beantwortet: ```text Was ist der nächste wirksame Schritt? ``` Signals müssen erklärbar sein: ```text - warum erzeugt? - durch welche Methode? - durch welchen Hook? - auf welchen Scope bezogen? - welche Datenquelle? - welche empfohlene Handlung? ``` --- ## 18. Assignment / Waiting / Reminder / Escalation Der Steuerungskern endet nicht mit dem Erzeugen einer Action. Kairo muss steuern: ```text - Actor auswählen - Actor zuweisen - auf Ergebnis warten - Fälligkeit überwachen - erinnern - eskalieren - externe Ereignisse aufnehmen - Agentenergebnisse zurückführen ``` Actors können sein: ```text human agent working_group external_system ``` --- ## 19. Result Intake / Evidence / Review / Decision Kairo führt Ergebnisse zurück und entscheidet, was daraus folgt. Mögliche Rückführungen: ```text - Action erledigt - Ergebnis unvollständig - Evidence erforderlich - Review erforderlich - Decision erforderlich - Blocker entstanden - RoadmapItem erreicht - Reifegrad plausibel erhöht - neue NextAction nötig ``` Evidence, Reviews und Decisions sind zentrale Qualitätssicherungs- und Steuerungsobjekte. --- ## 20. Workflow-Fragmente und Runtime Kairo soll langfristig Workflow-Fähigkeit haben. Aber: ```text Workflows sind methodengeführte Steuerungsabläufe, keine beliebige freie Automatisierungsplattform als Produktkern. ``` Zielmodell: ```text Hook → Workflow Fragment → Node / Step → Result → Rückführung in Kairo ``` Workflow-Fragmente können später enthalten: ```text human_task approval decision_gate review reflection llm_prompt agent_task tool_call state_transition evidence_check dod_check dependency_analysis notification reminder escalation ``` --- ## 21. Agenten / LLMs / Tools Kairo bleibt Steering Authority. Agenten, LLMs und Tools sind Provider. Sie können später an Hooks und Workflow-Fragmente angebunden werden. Grundsatz: ```text Kairo entscheidet Kontext, Methode, Auftrag und Rückführung. Agenten / LLMs / Tools führen einzelne Steps aus. ``` Agenten sind Actors. Das ist wichtig für: ```text - Verantwortlichkeit - Audit - Assignments - Sichtbarkeit - Tenant-Kontext ``` --- ## 22. Security / Governance / Audit Kairo muss tenant- und actor-sicher bleiben. Grundsätze: ```text - tenant_id immer aus TenantContext - keine tenant_id aus Client Input vertrauen - Actor-Bezüge tenant-intern validieren - Capabilities prüfen - Router dünn - Services schreiben - Data Layer liest - Audit-by-design - Signals und NextActions erklärbar - Agentenaktionen nachvollziehbar ``` --- ## 23. UI-Zielbild Die UI dient als Steuerungs- und Interaktionsschicht. Langfristige Views: ```text Workspace Steering View Roadmap View Method View Attention / NextAction View Backlog View Action View Waiting / Reminder View Evidence / Review / Decision View Workflow Run View später Method/Profile Admin später Agent Run View später ``` Die UI darf nicht die Methode hart kodieren. Sie muss methodenbewusst und strukturgetrieben sein. --- ## 24. Architektur-Evolutionslinie Grobe Evolutionslinie: ```text 1. Existing Foundation 2. Adaptive Steering Core Foundation 3. Method Registry / Hook Registry / Standard Lifecycle 4. Roadmap / Structure Builder Foundation 5. Signal / NextAction Engine 6. Assignment / Waiting / Reminder / Escalation 7. Evidence / Review / Decision 8. Workflow Fragments and Bindings 9. Workflow Runtime 10. Agent / LLM / Tool Providers 11. Method Profiles 12. Method Designer / Advanced Configuration 13. Advanced AI Steering / Next Best Action Ranking ``` Dies ist keine Sprintplanung, sondern ein Zielbild der technischen Entwicklung. --- ## 25. Zielzustand in einem Satz Kairo soll ein methodengeführter adaptiver Steuerungskern werden, der Entwicklungen unterschiedlichster Art über registrierbare Methoden, gemeinsame Kernstrukturen, Roadmaps, Hooks, Signals, NextActions, Assignments, Waiting-/Reminder-/Escalation-Mechanismen und später Agent-/Workflow-Fragmente wirksam und nachvollziehbar steuert.