188 lines
8.1 KiB
Markdown
188 lines
8.1 KiB
Markdown
---
|
||
title: "Kanshō – Thread Resurfacing und Reflection Saturation"
|
||
status: "Arbeitsstand"
|
||
date: "2026-08-18"
|
||
product_family: "Jinkendo"
|
||
document_role: "Querschnittliches Fachkapitel / Resurfacing / Saturation"
|
||
parent_document: "fachliche_zielarchitektur.md"
|
||
---
|
||
|
||
# Kanshō – Thread Resurfacing und Reflection Saturation
|
||
|
||
Dieses Dokument ist das kanonische Home für das Wiederauftauchen offener Themen, Wiedervorlagen, Relevanz und die erkannte Abschlussreife von Reflexionssitzungen.
|
||
|
||
<!-- Migriert aus `fachliche_zielarchitektur.md`: ehemaliger Abschnitt 2.11 Konsistenzregel für Resurfacing und Saturation. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
|
||
|
||
### 2.11 Konsistenzregel für Resurfacing und Saturation
|
||
|
||
Aus dem Nutzungsszenario „Tagesreflexion“ wurden zwei querschnittliche Konzepte abgeleitet, die für die gesamte fachliche und spätere technische Architektur verbindlich berücksichtigt werden müssen.
|
||
|
||
#### Thread Resurfacing
|
||
|
||
Beschreibt, **wann ein früherer oder offener Thread wieder aktiv relevant wird**.
|
||
|
||
Relevanz kann insbesondere entstehen durch:
|
||
|
||
- explizite Nutzeranfrage,
|
||
- gesetzte Wiedervorlage,
|
||
- zeitlichen oder örtlichen Kontext,
|
||
- neues Ereignis im gleichen Kontext,
|
||
- semantische Reaktivierung,
|
||
- aktuellen Bezug zu einem Reflection Space.
|
||
|
||
Grundprinzip:
|
||
|
||
> **Langfristig gespeichert bedeutet nicht automatisch aktuell relevant.**
|
||
|
||
Memory und Current Relevance sind getrennte Konzepte.
|
||
|
||
#### Reflection Saturation
|
||
|
||
Beschreibt, **wann eine Reflexion für die aktuelle Sitzung wahrscheinlich ausreichend tief beziehungsweise weit bearbeitet ist**.
|
||
|
||
Mögliche fachliche Signale sind:
|
||
|
||
- Reflection Intent,
|
||
- Nutzerwunsch,
|
||
- individuelle typische Dialogtiefe,
|
||
- Abdeckung aktiver Themen,
|
||
- sinkender zusätzlicher Erkenntnisgewinn,
|
||
- offene Randthemen,
|
||
- Gesprächssignale.
|
||
|
||
Grundprinzip:
|
||
|
||
> **Kanshō darf Abschlussreife erkennen und anbieten, aber der Nutzer entscheidet über Weiterführen, Vertiefung, Wiedervorlage oder Abschluss.**
|
||
|
||
#### Architekturweite Konsistenz
|
||
|
||
Diese beiden Konzepte müssen in späteren Kapiteln konsistent berücksichtigt werden, insbesondere in:
|
||
|
||
- `dialogue_model.md`
|
||
- `threads_and_branching.md`
|
||
- `thread_memory.md`
|
||
- `episodic_memory.md`
|
||
- `context_builder.md`
|
||
- `context_drift_and_regrounding.md`
|
||
- `reflection_space_model.md`
|
||
- `agent_roles.md`
|
||
- `retrieval_strategy.md`
|
||
- `memory_write_policy.md`
|
||
- `conversation_ui.md`
|
||
- `notifications_and_background_behaviour.md`
|
||
- `kairo_integration.md`
|
||
- `admin_developer_view.md`
|
||
|
||
Keines dieser Kapitel soll eine eigene Logik einführen, die dem Grundmodell von Resurfacing oder Saturation widerspricht.
|
||
|
||
#### Konsistenzprüfung
|
||
|
||
Bei der späteren Ausarbeitung der genannten Kapitel ist jeweils explizit zu prüfen:
|
||
|
||
1. Wie wirkt die jeweilige Architekturentscheidung auf Thread Resurfacing?
|
||
2. Wie wirkt sie auf Reflection Saturation?
|
||
3. Bleibt die Trennung zwischen Memory und aktueller Relevanz erhalten?
|
||
4. Bleibt die explizite Nutzerintention höher priorisiert als automatische KI-Vorschläge?
|
||
5. Bleibt der Nutzer Herr über Vertiefung, Wiedervorlage und Abschluss?
|
||
6. Ist die Entscheidung mit Re-Grounding, Provenance und Reflection Spaces konsistent?
|
||
|
||
Diese Fragen werden Teil des architecture-wide Capability- und Drift-Checks.
|
||
|
||
<!-- Migriert aus `usage_situations.md`: ehemaliger Abschnitt 7.2 Thread Resurfacing und Reflection Saturation. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
|
||
|
||
### 7.2 Thread Resurfacing und Reflection Saturation
|
||
|
||
Aus der Ausarbeitung der Tagesreflexion ergeben sich zwei querschnittliche fachliche Konzepte, die nicht nur für diese Nutzungssituation gelten.
|
||
|
||
#### Thread Resurfacing
|
||
|
||
Thread Resurfacing beantwortet die Frage:
|
||
|
||
> **Wann soll ein früheres oder offenes Thema wieder aktiv relevant werden?**
|
||
|
||
Mögliche Trigger sind insbesondere:
|
||
|
||
1. **Explizite Nutzeranfrage**
|
||
Beispiele: „Was ist noch offen?“ oder „Wo stehen wir bei Thema X?“
|
||
|
||
2. **Zeitlicher oder örtlicher Kontext**
|
||
Beispiel: Urlaubsthemen sind während des Urlaubs besonders relevant und können noch in einer definierten Rückschauphase danach aktiv angeboten werden.
|
||
|
||
3. **Situations- oder kontextgebundene Reaktivierung**
|
||
Beispiel: Ein neues Erlebnis beim Sport, in der Familie oder bei einer Meditation steht in erkennbarem Zusammenhang mit einem früheren Thread.
|
||
|
||
4. **Explizit gesetzter Anker im Dialog**
|
||
Beispiel: „Lass uns morgen daran weiterarbeiten.“
|
||
|
||
5. **Semantische Reaktivierung**
|
||
Ein aktuelles Erlebnis steht in starker inhaltlicher Beziehung zu einem früheren Thema, auch wenn der Nutzer es nicht ausdrücklich nennt.
|
||
|
||
Wichtig ist die Trennung zwischen:
|
||
|
||
- **Memory:** Ein Thema bleibt langfristig erhalten.
|
||
- **Current Relevance:** Ein Thema ist aktuell geeignet, wieder aktiv angeboten zu werden.
|
||
|
||
Ein Thema darf historisch vollständig verfügbar bleiben, ohne regelmäßig ungefragt in den Vordergrund zu treten.
|
||
|
||
#### Reflection Saturation
|
||
|
||
Reflection Saturation beantwortet die Frage:
|
||
|
||
> **Ist für die aktuelle Reflexionssitzung wahrscheinlich ausreichend gesagt beziehungsweise verstanden worden?**
|
||
|
||
Dabei können fachlich unter anderem berücksichtigt werden:
|
||
|
||
- aktueller Reflection Intent,
|
||
- expliziter Nutzerwunsch,
|
||
- typische persönliche Dialogtiefe,
|
||
- Umfang und Tiefe vergleichbarer früherer Reflexionen,
|
||
- Abdeckung aktuell relevanter Themen,
|
||
- offene Randthemen,
|
||
- sinkender zusätzlicher Erkenntnisgewinn,
|
||
- erkennbare Gesprächssignale.
|
||
|
||
Reflection Saturation ist **kein automatischer Gesprächsabbruch**.
|
||
|
||
Kanshō darf erkennen, dass eine Reflexion für den Moment ausreichend rund wirkt, soll den Abschluss aber als Möglichkeit anbieten.
|
||
|
||
Die letzte Entscheidung über Weiterführen, Vertiefen, Wiedervorlage oder Abschluss liegt beim Nutzer.
|
||
|
||
#### Fachliche Thread-Zustände
|
||
|
||
Für die weitere Architektur sind mindestens folgende fachlichen Zustände beziehungsweise Bedeutungen relevant:
|
||
|
||
- **Active** – wird aktuell bearbeitet,
|
||
- **Open** – noch nicht ausgeschöpft,
|
||
- **Anchored / Resurface** – ausdrücklich für eine spätere Wiederaufnahme markiert,
|
||
- **Dormant** – nicht abgeschlossen, aber aktuell nicht relevant,
|
||
- **Resolved** – für den derzeitigen Erkenntnisstand ausreichend bearbeitet.
|
||
|
||
Diese Begriffe sind noch **kein festes technisches State Model**. Sie dienen zunächst dazu, spätere Architekturentscheidungen konsistent auszurichten.
|
||
|
||
Die Aufzählung ist ausdrücklich **nicht abschließend**. In der späteren Ausarbeitung des Thread- und Datenmodells ist zu prüfen, ob weitere fachliche Zustände oder zusätzliche Metainformationen benötigt werden. Aus der heutigen Baseline darf keine vorzeitige technische Vollständigkeit abgeleitet werden.
|
||
|
||
#### Session Lifecycle und Thread Lifecycle
|
||
|
||
Als verbindliche querschnittliche Architekturregel gilt:
|
||
|
||
> **Session Lifecycle ≠ Thread Lifecycle**
|
||
|
||
Eine aktuelle Reflexionssitzung kann enden, während ein darin bearbeiteter Thread `Open`, `Anchored / Resurface` oder `Dormant` bleibt. Das Session-Ende bezeichnet nur das Ende der aktuellen Interaktion und ihrer Output-Verarbeitung. Es setzt einen Thread nicht automatisch auf `Resolved`.
|
||
|
||
Umgekehrt richtet sich der weitere Lebenszyklus des Threads nach seinem fachlichen Erkenntnisstand, seiner aktuellen Relevanz und einer möglichen Wiedervorlage. Die ausführliche Herleitung und die Output-Folgen werden kanonisch in `reflection_outputs.md` geführt.
|
||
|
||
#### Architekturweite Gültigkeit
|
||
|
||
Thread Resurfacing und Reflection Saturation sind querschnittliche Konzepte.
|
||
|
||
Spätere Kapitel zu Dialogmodell, Memory, Context Builder, AI-Architektur, Reflection Spaces, UX, Notifications, Kairo-Integration und Admin-/Developer View müssen mit diesen Konzepten konsistent bleiben.
|
||
|
||
Die konkrete Berechnung von Relevanz, Saturation, Scores oder Zustandsübergängen wird erst in den jeweiligen technischen Architekturkapiteln festgelegt.
|
||
|
||
---
|
||
|
||
|
||
## Nutzungsspezifische Regeln
|
||
|
||
Konkrete Regeln der Tagesreflexion – beispielsweise explizite Wiedervorlage, Fokuswahl und Priorisierung des heutigen Kontexts – verbleiben in `usage_situations.md` und müssen mit diesem Querschnittsmodell konsistent sein.
|