2026-07-05 08:18:13 +02:00
# Jinkendo Kairo
## Canonical Operating Model v0.1
2026-07-05 18:06:26 +02:00
> **⚠ Superseded (2026-07-05):** Nicht mehr führend. Verwende [`Kairo_Canonical_Operating_Model_v0.2.md`](Kairo_Canonical_Operating_Model_v0.2.md) und [`Kairo_Vision_and_Product_Direction_v0.2.md`](Kairo_Vision_and_Product_Direction_v0.2.md).
2026-07-05 08:18:13 +02:00
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:
```text
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
```text
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:
```text
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.
