# Jinkendo Kairo
## Canonical Operating Model v0.1

> **⚠ 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).

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.