Lars/Kansho
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
main
Kansho/docs/architecture/functional/resurfacing_and_saturation.md

8.1 KiB
Raw Permalink Blame History

title status date product_family document_role parent_document
Kanshō – Thread Resurfacing und Reflection Saturation Arbeitsstand 2026-08-18 Jinkendo Querschnittliches Fachkapitel / Resurfacing / Saturation 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.

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.

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.