Kansho/docs/architecture/functional/reflection_spaces.md

---
    title: "Kanshō – Reflection Spaces"
    status: "Arbeitsstand"
    date: "2026-08-18"
    product_family: "Jinkendo"
    document_role: "Fachkapitel / Reflection Contexts / Spaces"
    parent_document: "fachliche_zielarchitektur.md"
    ---

    # Kanshō – Reflection Spaces

Dieses Dokument ist das kanonische Home für Reflexionskontexte, Reflection Spaces, deren sichtbare und interne Struktur sowie die fachliche Autonomie bei ihrer Organisation.

<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 7 Reflexionskontexte. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->

## 7. Reflexionskontexte

Reflexionen finden in unterschiedlichen Lebensbereichen und Situationen statt.

Bereits benannte Beispiele sind:

- Urlaub,
- persönliche Entwicklung,
- Beruf,
- allgemeines Befinden,
- Vergangenheitsbewältigung,
- Ziele,
- Visionen,
- Inspiration,
- Kreativität.

Diese Liste ist ausdrücklich nicht abschließend.

Eine noch offene konzeptionelle Frage ist, ob solche Kontexte:

1. als feste Kategorien definiert werden,
2. vollständig dynamisch entstehen,
3. oder über ein hybrides Modell organisiert werden.

Als derzeit bevorzugte Richtung gilt ein **hybrides Modell**:

- wenige übergeordnete Lebensräume,
- darunter dynamisch entstehende konkrete Reflexionsräume.

Beispiele:

- `Urlaub → Lošinj 2026`
- `Beruf → Institute`
- `Persönliche Entwicklung → Umgang mit Verlust`
- `Kreativität → neue Produktidee`
- `Familie → gemeinsames Erleben`
- `Zukunft → persönliche Vision`

Diese Reflexionsräume sollen mit Objekten aus Kairo und Knoten aus mindnet verknüpft werden können.

---

<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 8.4 Fachliche Autonomie der KI bei Strukturierung. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->

### 8.4 Fachliche Autonomie der KI bei Strukturierung

Kanshō soll die interne Strukturierung von Reflexionen möglichst weitgehend im Hintergrund übernehmen.

Dabei gilt als fachliches Prinzip:

> **Die KI erkennt, schlägt vor, strukturiert und konsolidiert – der Nutzer soll aber nicht zum Verwalter der internen Struktur werden.**

Der Umfang dieser Eigenständigkeit soll konfigurierbar sein.

Mögliche Ausprägungen reichen von:

- stark bestätigungsorientiert: Kanshō schlägt neue Räume, Threads oder Zusammenführungen vor und wartet auf Bestätigung,
- ausgewogen: offensichtliche Strukturierungen erfolgen automatisch, bedeutsame Änderungen werden vorgeschlagen,
- weitgehend autonom: Kanshō darf neue Räume oder Threads selbst anlegen und später konsolidieren, solange dies transparent und korrigierbar bleibt.

Diese Einstellung ist eine fachliche Produktanforderung. Die genaue technische Umsetzung ist noch offen.

Wichtig ist dabei insbesondere:

- Nicht jedes Seitenthema erzeugt automatisch einen neuen sichtbaren Thread.
- Nicht jede semantische Abweichung benötigt einen neuen Reflection Space.
- Kanshō soll Relevanz, Wiederkehr, Tiefe und Dauer eines Themas berücksichtigen.
- Mehrere schwach ausgeprägte oder verwandte Strukturen dürfen später konsolidiert werden.
- Der Nutzer muss eine falsche Zuordnung, Trennung oder Zusammenführung korrigieren können.

Damit soll verhindert werden, dass Kanshō über Jahre eine unüberschaubare Menge kleinteiliger Reflexionsräume und Threads erzeugt.

<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 8.6 Sichtbare und interne Struktur. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->

### 8.6 Sichtbare und interne Struktur

Kanshō darf intern wesentlich mehr Struktur kennen und verwalten, als dem normalen Nutzer in der Oberfläche angezeigt wird.

Für die reguläre Nutzung gilt:

- nur relevante Reflection Spaces werden sichtbar hervorgehoben,
- offene oder bewusst markierte Themen können sichtbar angeboten werden,
- frühere Dialoge und Tagebucheinträge bleiben zugänglich,
- kleinere Threads, vorläufig erkannte Themen und interne semantische Beziehungen müssen nicht unmittelbar sichtbar sein.

Damit soll verhindert werden, dass die Anwendung zu einem Struktur- oder Wissensverwaltungswerkzeug wird.

#### Admin-/Developer View

Für Entwicklung, Test, Qualitätssicherung und spätere Administration soll es jedoch eine besondere Diagnose- und Transparenzansicht geben.

Diese Ansicht kann – abhängig vom späteren Berechtigungsmodell – insbesondere sichtbar machen:

- erkannte interne Threads,
- Zuordnung von Dialogen zu Reflection Spaces,
- vorläufige Space- oder Thread-Kandidaten,
- Herkunft und Provenance verwendeter Memories,
- Confidence beziehungsweise Unsicherheit interner Zuordnungen,
- erkannte Zusammenhänge und Hypothesen,
- Gründe für Vorschläge zur Trennung oder Konsolidierung,
- Konsolidierungskandidaten,
- Context-Builder-Auswahl für einen Dialog,
- verwendete relevante Erinnerungen und Wissensknoten,
- vorgeschlagene beziehungsweise durchgeführte Strukturänderungen.

Diese Ansicht ist **nicht Teil der normalen Nutzeroberfläche**.

Sie soll später nur Rollen mit entsprechender Berechtigung zugänglich sein, beispielsweise:

- Hauptadmin,
- Systemadministrator,
- Entwickler/Testrolle.

Die konkrete Rollenbezeichnung und technische Berechtigungsumsetzung werden später festgelegt.

Wesentliche Anforderung:

> Interne KI-Strukturen müssen für Entwicklung und Qualitätssicherung nachvollziehbar und inspizierbar sein, ohne die reguläre Nutzung mit dieser Komplexität zu belasten.

<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 8.7 Reflection Space als lebendiger Denk- und Erfahrungsraum. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->

### 8.7 Reflection Space als lebendiger Denk- und Erfahrungsraum

Ein Reflection Space ist fachlich **kein bloßer Ablageort für Dialoge oder Tagebucheinträge**.

Er bildet vielmehr eine laufend aktualisierte Sicht auf einen zusammenhängenden persönlichen Denk- und Erfahrungsraum.

Ein Reflection Space kann dabei mehrere Elemente verbinden:

- frühere und aktuelle Dialoge,
- relevante Threads,
- Tagebucheinträge,
- offene Fragen,
- bereits entstandene Erkenntnisse,
- zeitliche Entwicklung,
- Verbindungen zu anderen Reflection Spaces,
- relevante Informationen aus mindnet,
- bei Bedarf relevante Kontexte aus anderen Jinkendo-Anwendungen.

Der Reflection Space soll dem Nutzer vor allem fünf Dinge ermöglichen:

1. **Orientierung** – Worum geht es in diesem Raum aktuell?
2. **Fortsetzung** – Wo kann die Reflexion sinnvoll weitergehen?
3. **Offene Fragen** – Welche Themen oder Fragen sind noch nicht abgeschlossen?
4. **Historie** – Welche Dialoge, Erlebnisse und Einträge haben den Raum geprägt?
5. **Entwicklung** – Was hat sich über die Zeit in Wahrnehmung, Haltung oder Erkenntnis verändert?

#### Aktueller Zustand eines Reflection Space

Jeder Reflection Space besitzt aus Nutzersicht einen aktuellen fachlichen Zustand.

Dieser Zustand beschreibt nicht die vollständige Historie, sondern den derzeit relevanten Stand des Denk- und Erfahrungsraums.

Wichtig:

- Der aktuelle Zustand muss auf zugrunde liegende Reflexionen, Erinnerungen oder andere Quellen zurückführbar sein.
- Er darf kein frei erfundenes KI-Summary sein.
- Veränderungen des Zustands müssen nachvollziehbar aus neuen Dialogen, Erkenntnissen oder bestätigten Informationen hervorgehen.
- Die vollständige Historie bleibt weiterhin zugänglich.
- Interne technische Strukturen können deutlich umfangreicher sein als die sichtbare Zusammenfassung.

Damit wird der Reflection Space zu einer **lebendigen, kontextuellen Sicht auf persönliche Entwicklung innerhalb eines bestimmten Zusammenhangs**.


#### Dauer und Granularität

Reflection Spaces können unterschiedlich lange relevant sein.

Sie können beispielsweise:

- ein klar abgegrenztes Erlebnis oder einen Urlaub über Tage oder Wochen begleiten,
- ein über mehrere Wochen laufendes persönliches Thema bündeln,
- eine längerfristige berufliche oder persönliche Entwicklung abbilden,
- über Jahre hinweg wiederkehrende Fragen oder Lebenszusammenhänge begleiten.

Die Dauer allein entscheidet nicht darüber, ob ein eigener Reflection Space sinnvoll ist. Maßgeblich ist, ob ein Zusammenhang für die Reflexion über mehrere Interaktionen hinweg eigenständige Bedeutung besitzt.

Ältere oder aktuell nicht relevante Spaces dürfen in der normalen Oberfläche zurücktreten, bleiben aber auffindbar und können bei erneuter Relevanz wieder in den Vordergrund treten.

Kanshō soll diese Komplexität weitgehend selbst organisieren. Der Nutzer soll nicht entscheiden müssen, ob ein Thema „groß genug“ für einen Space ist.

#### Vorläufige sichtbare Standardansicht

Für die normale Nutzeroberfläche gilt als **vorläufige fachliche Baseline**, die in späteren Dialogkapiteln weiter konkretisiert werden kann:

1. **Aktueller Stand** – eine kompakte, quellengebundene Sicht darauf, worum es in diesem Space aktuell geht und wo der Nutzer gedanklich steht.
2. **Was ist noch offen?** – nur die aktuell relevanten offenen Fragen, Spannungsfelder oder bewusst weiterzuverfolgenden Themen.
3. **Weiterdenken** – ein intelligent priorisierter Vorschlag zur Fortsetzung mit wenigen Alternativen.
4. **Bisheriger Weg** – eine kompakte zeitliche Sicht auf prägende Erlebnisse, Dialoge, Tagebucheinträge und Wendepunkte.

Diese Darstellung ist bewusst nicht abschließend. Sie bildet den derzeit akzeptierten Ausgangspunkt und darf später auf Basis der konkreten Nutzungsszenarien erweitert oder verändert werden.

#### Aufklappbarkeit und Nutzer-Provenance

Verdichtete Aussagen in der sichtbaren Space-Ansicht sollen für den Nutzer grundsätzlich auf die zugrunde liegenden Inhalte zurückführbar sein.

Der Nutzer soll bei Bedarf nachvollziehen können:

- auf welchen früheren Dialogen,
- Tagebucheinträgen,
- Memories,
- Obsidian-Inhalten,
- mindnet-Knoten oder
- bestätigten Erkenntnissen

eine relevante Aussage oder Zusammenfassung basiert.

Dieses **Aufklappen** ist eine Transparenzfunktion für den Nutzer und ist fachlich von dem internen Re-Grounding der KI zu unterscheiden.