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.


---

## Reflection Space als primäre Kontextgrenze

**Status: fachliche Baseline entschieden**

Reflection Spaces dienen nicht nur der langfristigen Organisation von Reflexionsinhalten. Sie bilden im normalen Dialog auch die bevorzugte fachliche Kontextgrenze.

Für die laufende Nutzung gilt deshalb:

> **Kanshō arbeitet standardmäßig innerhalb des aktuellen Reflection Space und erweitert diesen Kontext nur bei konkreter fachlicher Relevanz um tieferes Langzeitgedächtnis oder mindnet.**

Damit bleibt die primäre Nutzung auf den aktuellen Reflexionszusammenhang fokussiert.

Beispiele:

- Bei einem Urlaubstagebuch kann `Lošinj 2026` der aktuelle Reflection Space sein.
- Bei einer längerfristigen Entwicklung kann `Meine Meditationsreise` ein eigener Reflection Space sein.
- Bei einer beruflichen Reflexion kann ein konkreter Space wie `Institute` oder `Berufliche Neuorientierung` den aktuellen Kontext bilden.

Ein Reflection Space ist damit zugleich:

- ein Bedeutungsraum,
- eine Orientierungshilfe,
- eine Kontinuitätsstruktur,
- eine bevorzugte Kontextgrenze für den laufenden Dialog.

Er ist jedoch kein exklusiver Container und kein technischer Prompt.

---

## Primary und Related Reflection Spaces

**Status: fachliche Baseline entschieden**

Eine Session beziehungsweise ein Dialog kann einen **Primary Reflection Space** besitzen und gleichzeitig mit weiteren **Related Reflection Spaces** verbunden sein.

Der Primary Reflection Space ist der Raum, der den aktuellen Dialog fachlich am stärksten trägt.

Related Reflection Spaces sind weitere längerfristige Kontexte, die durch einzelne Experiences, Threads, offene Fragen oder Insights berührt werden.

Beispiel:

Ein Nutzer schreibt während eines Urlaubs:

> „Gestern habe ich meinen Urlaubstag dazu genutzt, tief zu meditieren. Dabei hatte ich erstmals das Gefühl, meinen Körper zu verlassen. Das war eine tiefgreifende Erfahrung.“

Für den unmittelbaren Journaling-Dialog kann gelten:

- Primary Reflection Space: `Lošinj 2026`
- Related Reflection Space: `Meine Meditationsreise`

Das Erlebnis selbst wird dadurch nicht dupliziert.

Verbindliche Regel:

> **Eine Reflexion kann mehrere Spaces berühren, ohne dass ihre Quellen oder fachlichen Kernobjekte mehrfach angelegt werden.**

---

## Identity ist nicht Assignment

**Status: entschieden**

Die fachliche Identität eines Objekts ist von seiner Zuordnung zu Reflection Spaces zu trennen.

Eine Experience, ein Thread, eine Open Question oder ein Insight kann Beziehungen zu mehreren Reflection Spaces besitzen.

Beispiele:

- eine Experience kann gleichzeitig zu Urlaub und Meditation relevant sein,
- ein Thread kann sowohl persönliche Entwicklung als auch Beruf berühren,
- eine Open Question kann mehrere längerfristige Reflexionsräume verbinden.

Daraus folgt:

> **Mehrfachzuordnung erzeugt keine zweite Identität.**

Reflection Spaces organisieren Bedeutungszusammenhänge; sie besitzen keine exklusive Eigentümerschaft an den darin referenzierten Objekten.

---

## Entstehung und Promotion von Reflection Spaces

**Status: fachliche Baseline entschieden; konkrete Schwellenwerte offen**

Nicht jeder situative Kontext wird unmittelbar zu einem langlebigen Reflection Space.

Für die Entstehung wird derselbe allgemeine Promotion-Gedanke verwendet wie für andere langlebige Reflexionsobjekte:

> **Possible Context → Space Candidate → Existing Space Enrichment oder Established Reflection Space**

Ein neuer Reflection Space ist insbesondere dann sinnvoll, wenn ein Zusammenhang:

- über mehrere Interaktionen hinweg eigenständige Reflexionsrelevanz besitzt,
- mehrere zusammenhängende Threads, Experiences, Open Questions oder Insights verbindet,
- vom Nutzer ausdrücklich als zusammenhängender Bereich erlebt oder benannt wird,
- über einen längeren Zeitraum fortgesetzt werden soll,
- eine eigenständige Entwicklungs- oder Historienperspektive benötigt,
- nicht sinnvoll in einen bereits etablierten Space integriert werden kann.

Verbindliche Regel:

> **Existing before new.**

Wenn ein geeigneter bestehender Reflection Space vorhanden ist, soll dieser bevorzugt angereichert werden.

Semantische Ähnlichkeit allein reicht jedoch nicht aus, um zwei unterschiedliche Bedeutungsräume zusammenzuführen.

---

## Unterschiedliche Typen von Reflection-Space-Entstehung

**Status: Arbeitsmodell**

Reflection Spaces können auf unterschiedliche Weise entstehen.

### Situativ klar abgegrenzte Spaces

Diese ergeben sich häufig aus einem klaren zeitlichen oder räumlichen Zusammenhang.

Beispiele:

- Urlaub,
- Reise,
- Seminar,
- Projektphase,
- klar umrissener Lebensabschnitt.

Ein Space wie `Lošinj 2026` kann bereits früh mit hoher Confidence erkannt werden, weil Ort, Zeitraum und wiederkehrender Kontext eine klare Klammer bilden.

### Longitudinal entstehende Spaces

Andere Reflection Spaces entstehen erst über mehrere Interaktionen hinweg.

Beispiele:

- `Meine Meditationsreise`,
- `Umgang mit Verlust`,
- `Meine Rolle als Vater`,
- `Berufliche Neuorientierung`.

Hier kann zunächst nur ein Thread oder Space Candidate bestehen.

Erst wenn ausreichend Kontinuität und eigenständige Bedeutung sichtbar werden, entsteht ein etablierter Reflection Space.

Diese Unterscheidung beschreibt unterschiedliche Entstehungsmuster und noch keine technischen Space-Typen.

---

## Reflection-Space-Lifecycle

**Status: fachliche Baseline entschieden; technische State Machine offen**

Der Lifecycle eines Reflection Space soll bewusst schlank bleiben.

Mindestens folgende Zustände beziehungsweise fachliche Phasen müssen abbildbar sein:

- **Candidate** – möglicher eigenständiger Reflection Space,
- **Active** – aktuell relevante und genutzte Reflexionsumgebung,
- **Dormant** – derzeit nicht aktiv, aber weiterhin langfristig relevant,
- **Historical / Archived** – primär historisch relevant und in der normalen Oberfläche zurückgetreten,
- **Reactivated** – ein zuvor ruhender oder historischer Space wird erneut aktuell.

Dabei gilt:

- Dormant bedeutet nicht gelöscht.
- Historical bedeutet nicht bedeutungslos.
- Reaktivierung erzeugt keinen neuen Space, wenn fachlich derselbe Bedeutungsraum fortgesetzt wird.
- Frühere Zustände und Historie bleiben nachvollziehbar.
- Die konkrete technische Zustandsmaschine wird später festgelegt.

Ein Space muss nicht allein aufgrund seines Alters archiviert werden. Maßgeblich ist seine aktuelle Reflexionsrelevanz.

---

## Automatische Reflection-Space-Erkennung

**Status: fachliche Baseline entschieden**

Kanshō soll Reflection Spaces möglichst selbstständig erkennen und den Nutzer nicht zum manuellen Verwalter der Reflexionsstruktur machen.

Dabei gilt jedoch:

> **Automatische Reflection-Space-Erkennung darf nicht bedeuten, dass vor jedem Dialogturn ein eigener LLM-Analyseaufruf notwendig ist.**

Die Erkennung soll möglichst inkrementell und opportunistisch erfolgen.

Bevorzugte Signalreihenfolge:

1. bestehender aktiver Primary Reflection Space,
2. aktueller Session-Kontext,
3. Zeit- und gegebenenfalls Ortsbezug,
4. bereits verbundene Threads, Experiences und Open Questions,
5. bestehende Space-Beziehungen,
6. semantische beziehungsweise Retrieval-Signale,
7. strukturierte Einschätzung des ohnehin für die Antwort verwendeten Hauptmodells,
8. separater Analyse-Call nur bei echter Ambiguität oder höherwertiger struktureller Neubewertung.

Designregel:

> **Space recognition should normally piggyback on existing processing rather than create an additional LLM round trip.**

---

## Confidence und Umgang mit Unsicherheit

**Status: fachliche Baseline entschieden; konkrete Schwellenwerte offen**

Kanshō darf eine Space-Zuordnung mit unterschiedlicher Sicherheit behandeln.

Bei hoher Confidence kann eine offensichtliche Zuordnung automatisch erfolgen.

Bei mittlerer Confidence kann:

- eine bestehende Zuordnung vorläufig verwendet,
- ein Space Candidate geführt,
- oder eine spätere Neubewertung vorgesehen werden.

Bei niedriger Confidence soll Kanshō nicht künstlich eine neue langlebige Struktur erzeugen.

Der Nutzer soll nur dann mit einer Rückfrage belastet werden, wenn die Zuordnung für die Reflexion tatsächlich relevant ist und nicht sinnvoll im Hintergrund korrigierbar bleibt.

Verbindliche Regel:

> **Unsicherheit rechtfertigt Zurückhaltung, nicht automatisch eine Rückfrage.**

---

## Reflection Space und Context Builder

**Status: entschieden als Querschnittsregel**

Die kanonische Context-Builder-Logik wird in `memory_and_context.md` geführt.

Für Reflection Spaces gilt daraus abgeleitet:

- der Primary Reflection Space wird bevorzugt als Reflection Context verwendet,
- Related Spaces werden nur situativ aktiviert,
- tieferes Long-Term Memory wird nicht standardmäßig geladen,
- mindnet erweitert den Space nur bei konkreter Relevanz,
- die Space-Struktur dient der Kontextfokussierung und darf nicht selbst zur Quelle unnötiger Prompt-Vergrößerung werden.

Leitprinzip:

> **Reflection Space first, Long-Term Memory on demand.**

---

## Aktualisierter Stand der offenen Punkte

**Status: Arbeitsstand nach Lifecycle- und Context-Klärung**

Weiter offen beziehungsweise bewusst später zu klären sind insbesondere:

1. konkrete Schwellenwerte für Space Promotion, Merge und Reaktivierung,
2. die genaue technische Repräsentation von Primary- und Related-Space-Beziehungen,
3. konkrete UI-Regeln für automatische versus sichtbare Space-Zuordnung,
4. die spätere Integration mit dem finalen Usage-/Intent-Modell,
5. technische Event-/State-Modelle für Lifecycle-Änderungen,
6. konkrete Governance-Regeln für automatische Konsolidierung oder Merge,
7. die genaue technische Zusammenarbeit zwischen Context Builder und Space-Erkennung.

Nicht mehr grundsätzlich offen sind:

- ob Reflection Spaces nur Ablageorte oder aktive Reflexionskontexte sind,
- ob eine Session mehreren Spaces zugeordnet sein kann,
- ob Mehrfachzuordnung Duplikation erzeugt,
- ob jeder situative Kontext automatisch einen Space erzeugt,
- ob jeder Turn einen separaten Space-Erkennungs-Call benötigt,
- ob ruhende Spaces gelöscht oder neu angelegt werden müssen,
- ob bestehende Spaces gegenüber neuen bevorzugt werden sollen.