Kairo-Jinkendo/docs/product/Kairo_Canonical_Operating_Model_v0.1.md

Jinkendo Kairo

Canonical Operating Model v0.1

Status: kanonisches Produktmodell
Stand: 2026-07-05

---

1. Zweck

Dieses Dokument definiert das kanonische Operating Model von Kairo.

Es verhindert, dass Kairo auf eine einfache To-do- oder Projektliste reduziert wird.

---

2. Leitfrage

Welcher nächste Schritt bringt ein Vorhaben aktuell am wirkungsvollsten voran?

Alle Objekte, Views und Datenmodelle müssen mittelbar auf diese Frage einzahlen.

---

3. Operating Cycle

Kairo folgt einem wiederkehrenden Steuerungszyklus:

Capture
  → Triage
    → Structure
      → Commit
        → Execute
          → Verify
            → Review
              → Adapt
                → Next Action

Capture

Ideen, Risiken, Aufgaben, Nachweise und Beobachtungen werden erfasst.

Triage

Eingänge werden eingeordnet:

• sofortige Maßnahme?
• Backlog?
• Blocker?
• Entscheidung?
• Nachweis?
• Review-Thema?

Structure

Arbeit wird an Vorhaben, Projekte, Meilensteine oder Maßnahmen angebunden.

Commit

Eine Maßnahme wird konkret zugewiesen und erhält Status, Priorität und ggf. Fälligkeit.

Execute

Actors arbeiten Maßnahmen ab.

Verify

Fortschritt wird durch Nachweise oder Statusänderungen belegbar.

Review

Der Zustand eines Vorhabens wird bewertet.

Adapt

Backlog, Maßnahmen, Blocker oder Meilensteine werden angepasst.

Next Action

Kairo zeigt, was jetzt Aufmerksamkeit oder Umsetzung braucht.

---

4. Objektmodell

Tenant
  └── Actor
        └── Initiative
              ├── Project optional
              │     └── Milestone
              ├── Milestone
              ├── BacklogItem
              ├── Action
              │     ├── ActionAssignment
              │     ├── Blocker
              │     └── Evidence
              ├── Decision
              ├── Review
              ├── RecurringElement
              └── AttentionItem / NextActionCandidate

---

5. Objektdefinitionen

Tenant

Abgegrenzter Nutzungsraum.

Alle fachlichen Objekte sind tenant-scoped, sofern nicht explizit global.

Actor

Operative Verantwortungseinheit.

Typen:

• human
• agent
• working_group
• external_system

Zuweisungen erfolgen an Actors, nicht an Users.

Initiative

Ein aktives Vorhaben mit Zielzustand.

Project

Optionale Unterstruktur für größere Vorhaben.

Milestone

Überprüfbarer Zielpunkt.

Kein Task.

BacklogItem

Noch nicht freigegebener Handlungsbedarf.

Action

Konkrete operative Maßnahme.

ActionAssignment

Zuweisung einer Maßnahme an einen oder mehrere Actors.

Blocker

Hindernis, das Fortschritt verhindert oder gefährdet.

Evidence

Nachweis für Fortschritt, Abschluss oder Entscheidung.

Decision

Dokumentierte Auswahl zwischen Optionen.

Review

Strukturierte Bewertung eines Scopes.

RecurringElement

Regelmäßig wiederkehrender Arbeits- oder Review-Bedarf.

AttentionItem

Read Model, das Aufmerksamkeit auf relevante Steuerungspunkte lenkt.

NextActionCandidate

Read Model, das mögliche nächste sinnvolle Aktionen aus dem aktuellen Zustand ableitet.

---

6. Statusmodelle minimal

Initiative

• draft
• active
• paused
• completed
• archived

Project

• planned
• active
• paused
• completed
• archived

Milestone

• planned
• active
• at_risk
• reached
• moved
• discarded

BacklogItem

• new
• triaged
• accepted
• rejected
• converted

Action

• open
• ready
• in_progress
• blocked
• review_required
• done
• discarded

Blocker

• open
• in_progress
• resolved
• accepted_risk
• dismissed

Review

• planned
• completed
• skipped

RecurringElement

• active
• paused
• ended

---

7. Next Action / Attention Logic

Kairo muss eine regelbasierte erste Attention-Schicht bereitstellen, bevor KI eingesetzt wird.

Minimalregeln:

1. Blockierte Maßnahmen sichtbar machen
2. High-Priority offene Maßnahmen sichtbar machen
3. Maßnahmen ohne Assignment sichtbar machen
4. Vorhaben ohne offene nächste Maßnahme sichtbar machen
5. lange unveränderte Vorhaben sichtbar machen
6. Meilensteine mit Status at_risk sichtbar machen
7. überfällige Elemente sichtbar machen, sobald Due Dates existieren
8. fällige Reviews sichtbar machen
9. wiederkehrende Elemente mit next_due_at sichtbar machen

---

8. Data-Layer-Prinzip

Kairo benötigt für Operating-Model-Sichten einen read-orientierten Data Layer.

Router beantworten HTTP.

Services schreiben Domänenobjekte.

Data Layer bereitet Steuerungs- und Workspace-Sichten auf:

data_layer.workspace
data_layer.actions
data_layer.initiatives
data_layer.attention
data_layer.actors

Data Layer ist nicht:

• Analytics-Plattform
• KI-System
• Reporting-Engine
• Ersatz für Services

---

9. UI-Prinzip

Die UI soll nicht nur Tabellen zeigen.

Sie muss Steuerungsfragen sichtbar machen:

• Was ist aktiv?
• Was ist blockiert?
• Was braucht Aufmerksamkeit?
• Was ist meine nächste Arbeit?
• Wo fehlt Struktur?
• Wo fehlt Nachweis?
• Was wurde entschieden?
• Was muss reviewt werden?

---

10. MVP-relevante Sichten

MVP-Sichten:

1. Workspace
2. Meine Maßnahmen
3. Vorhaben
4. Vorhaben-Detail
5. Backlog
6. Attention / Next Action
7. Blocker
8. einfache Review-/Nachweis-Sicht

Nicht-MVP-Sichten:

• Gantt
• Kalender
• komplexe Portfolio-Reports
• AI Chat
• Workflow Designer
• Admin-Konsole

---

11. Agenten-Regel

Agenten dürfen später:

• Status melden
• Fortschritt melden
• Backlog Items vorschlagen
• Nachweise einreichen
• Blocker melden
• Reviews anfordern
• Next Action Empfehlungen erzeugen

Agenten dürfen nicht ohne menschliche Freigabe:

• Ziele ändern
• Meilensteine verschieben
• strategische Priorität ändern
• Rechte ändern
• Prompts produktiv ändern
• Vorhaben löschen

---

12. Minimaler MVP-Zustand

Kairo ist MVP-nah, wenn ein Nutzer reale Vorhaben führen kann mit:

• Vorhaben
• Maßnahmen
• Assignments
• Backlog
• Blocker
• Meilenstein minimal
• Nachweis minimal
• Review minimal
• wiederkehrender Check minimal
• Attention-/Next-Action-Sicht
• Jinkendo Workspace UX
• Tenant/Actor/Data-Layer-Sicherheit

Nicht vorher.