Kansho/docs/architecture/functional/resurfacing_and_saturation.md

---
    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.

#### 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.