--- title: "Kanshō – Memory und Context" status: "Arbeitsstand" date: "2026-08-18" product_family: "Jinkendo" document_role: "Fachkapitel / Memory Architecture / Context" parent_document: "fachliche_zielarchitektur.md" --- # Kanshō – Memory und Context Dieses Dokument ist das kanonische Home für Working Context, Thread Memory, Episodic Memory, Knowledge-Graph-Bezug und die Rolle von mindnet im kurzfristigen Dialog. ## 10. Gedächtnismodell Ein zentrales Ergebnis der bisherigen Konzeption ist die Erkenntnis, dass ein einziges LLM-Kontextfenster nicht ausreicht. Kanshō benötigt mehrere Gedächtnisebenen. ### 10.1 Working Context Enthält beispielsweise: - aktuelle Nachrichten, - aktuelle Frage, - unmittelbar vorausgehende Aussagen, - temporäre Gesprächsinformationen. Lebensdauer: - Minuten bis Stunden, - primär für den aktuellen Dialog. --- ### 10.2 Thread Memory Enthält: - Zusammenfassungen einzelner Dialogfäden, - offene Fragen, - Zwischenstände, - noch nicht abgeschlossene Reflexionen, - relevante Aussagen aus früheren Sitzungen. Lebensdauer: - Tage, - Wochen, - Monate, - ggf. länger. --- ### 10.3 Episodic Memory Enthält bedeutsame Ereignisse oder Erfahrungen wie: - Urlaubserlebnisse, - Konflikte, - Entscheidungen, - besondere Erfahrungen, - persönliche Wendepunkte, - wichtige Erkenntnisse. Diese Informationen sind langfristig relevant und sollen in geeigneter Form in Obsidian beziehungsweise mindnet überführt werden. --- ### 10.6 Knowledge Graph / mindnet mindnet übernimmt die langfristige Vernetzung von Informationen. Dazu gehören: - Erfahrungen, - Erkenntnisse, - Beziehungen, - Referenzen, - Werte, - Entscheidungen, - wiederkehrende Themen, - offene Zusammenhänge. Kanshō soll dieses Wissen gezielt abrufen und neue Erkenntnisse wieder zurückführen. --- ## 11. Rolle von mindnet im kurzfristigen Dialog Noch nicht abschließend entschieden ist, ob mindnet als kurzfristiger Dialogspeicher geeignet ist. Der derzeitige konzeptionelle Stand lautet: **mindnet sollte wahrscheinlich nicht der primäre Working-Memory-Speicher laufender Gespräche sein.** Gründe dafür sind insbesondere die unterschiedlichen Anforderungen: Ein Dialogspeicher benötigt unter anderem: - exakte Reihenfolge, - hohe Änderungsfrequenz, - Thread-Zustände, - lokale/offline Synchronisation, - schnelle Wiederaufnahme, - Branching, - Editierbarkeit, - Zustandsmanagement. mindnet ist dagegen besonders geeignet für: - langfristiges Wissen, - semantische Retrieval-Prozesse, - Beziehungen, - Episoden, - Erkenntnisse, - autobiografischen Kontext. Die derzeit bevorzugte Verantwortungsverteilung lautet deshalb: > **Kanshō besitzt den Dialog.** > **mindnet besitzt das langfristige Gedächtnis.** > **Obsidian bildet das menschenlesbare autobiografische Archiv.** Diese Entscheidung ist noch technisch zu validieren. --- ## Kontinuitätsarbeit ohne zwingendes Output-Artefakt **Status: entschieden** Der Erfolg einer Reflexion hängt nicht davon ab, dass daraus zwingend ein Journal Entry, eine neue Erkenntnis, ein Knowledge Delta oder eine Handlungsabsicht entsteht. Davon unabhängig benötigt Kanshō interne Kontinuitätsarbeit, damit lange Dialoge, mehrere Threads und spätere Wiederaufnahmen ohne vermeidbaren Bedeutungsverlust möglich bleiben. Dazu können insbesondere gehören: - Erhalt des Originaldialogs beziehungsweise einer verlässlichen Originalrepräsentation, - Working-Context- und Thread-Memory-Summaries, - offene Fragen und Zwischenstände, - fachlich relevante Erkenntnisse, - vorläufig erkannte Nebenfäden oder Thread-Kandidaten, - Zeitbezug, Provenance, Confidence beziehungsweise Unsicherheit. Nicht jeder erkannte Nebenfaden muss zu einem sichtbaren oder dauerhaft eigenständigen Thread werden. Nicht jede Summary ist eine bestätigte Erkenntnis, und nicht jede Kontinuitätsstruktur ist ein sichtbarer Output. Da Summaries und weitere Verdichtungen selektiv sind, gelten für ihre langfristige Nutzung verbindlich die Regeln aus `context_fidelity_and_regrounding.md`: Die Originalquelle bleibt maßgeblich; bei ausreichendem Drift-Risiko, Abweichungen, Widersprüchen oder möglicher Fehlinterpretation muss Kanshō ein Re-Grounding aus den relevanten Ursprungsquellen auslösen können. Dies kann automatisch beziehungsweise systemseitig oder ausdrücklich durch den Nutzer angestoßen werden. Kontinuitätsarbeit ist nicht an das Ende einer Session gebunden. Sie darf und muss bei fachlichem Bedarf bereits während eines langen Dialogs erfolgen, insbesondere wenn der aktive Kontext sonst relevante Aussagen, Nebenfäden oder Zwischenstände verlieren würde. Das Session-Ende ist ein zusätzlicher fachlicher Kontinuitäts-Checkpoint. Dabei wird geprüft: - Ist die Originalquelle verlässlich erhalten? - Müssen Working Context, Summary oder Thread Memory aktualisiert werden? - Sind tatsächlich relevante Erkenntnisse, offene Fragen oder mögliche Nebenfäden entstanden? - Haben sich Thread-Zustand, Wiedervorlage oder andere Kontinuitätsinformationen tatsächlich verändert? - Besteht ein Drift- beziehungsweise Re-Grounding-Bedarf? Nur tatsächlich notwendige beziehungsweise entstandene Änderungen werden fortgeschrieben. Der Checkpoint erzeugt weder künstlich eine Erkenntnis noch einen Nebenfaden und verlangt kein sichtbares Output-Artefakt. Für die Produktqualität besitzt die verlässliche Langzeitkommunikation höhere Priorität als die maximale Extraktion möglichst vieler Memories oder Wissenselemente. Verdichtungen sollen Kontinuität ermöglichen, dürfen Erkenntnisse aber nicht schrittweise verwässern, vorläufige Deutungen stabilisieren oder fehlende Zusammenhänge halluzinieren. Die verbindlichen Gegenmaßnahmen werden in `context_fidelity_and_regrounding.md` geführt. Die konkrete technische Granularität, Speicherform und Aktualisierungslogik dieser Strukturen bleibt später auszuarbeiten. --- ## Default-Quellbewahrung und skalierbare Informationsorganisation **Status: fachliche Baseline entschieden; konkrete Organisations- und Speicherlogik offen** ### Root Cause Kanshō ist auf langfristige Kommunikation, spätere Rekonstruktion und Re-Grounding ausgelegt. Dafür müssen auch kurze, zunächst unscheinbare oder erst später bedeutsame Äußerungen als zeitgebundene Quellen verfügbar bleiben. Gleichzeitig kann über Jahre eine sehr große Menge an Dialog- und Textmaterial entstehen. ### Risiko Eine relevance-, alters- oder mengengetriebene automatische Löschung könnte Quellen vernichten, deren Bedeutung erst später sichtbar wird, und Re-Grounding sowie Point-in-Time-Rekonstruktion beschädigen. Umgekehrt würde eine undifferenzierte Behandlung jedes Textes als sichtbares Objekt, aktives Memory oder eigener mindnet-Knoten das System fachlich und in der Nutzung zumüllen. ### Fachliche Konsequenz Quellbewahrung und Informationsorganisation sind getrennte Verantwortungen: > **Alles als Quelle bewahren bedeutet nicht, alles sichtbar, aktiv oder semantisch gleichrangig zu halten.** ### Abgeleitete Entscheidungen - Vom Nutzer bewusst in Kanshō eingebrachte Texte und der inhaltliche Dialogverlauf werden standardmäßig unmittelbar als zeitgebundene Originalquelle beziehungsweise verlässliche Originalrepräsentation in der internen vertrauenswürdigen Datenhaltung bewahrt. - Dies gilt auch für kurze spontane Gedanken. Ihre spätere Einordnung, Verknüpfung oder Verdichtung ist von der unmittelbaren Quellbewahrung getrennt. - Originalquellen werden nicht allein wegen Alter, Umfang, derzeit geringer Relevanz, Konsolidierung oder vorhandener Summaries automatisch gelöscht oder überschrieben. - Eine Löschung erfolgt nur auf konkrete Nutzeraufforderung beziehungsweise durch eine dafür berechtigte administrative Handlung. Administrative Löschung ist kein automatisches Mittel zur Relevanz- oder Mengenbereinigung. - Summaries, Thread Memories, Reflection Memories, Knowledge Deltas, Indizes und andere abgeleitete Strukturen dürfen selektiv erzeugt, aktualisiert, konsolidiert, zurückgestuft oder aus dem aktiven Kontext entfernt werden. Sie ersetzen und löschen dadurch nicht ihre Quellen. - Nicht jeder gespeicherte Text wird zu einem sichtbaren Eintrag, Thread, Reflection Space, Journal Entry, Reflection Memory oder mindnet-Knoten. - Nur der für die aktuelle Situation relevante Ausschnitt wird in den aktiven Modellkontext geladen. Langfristig gespeichert bedeutet weder dauerhaft aktiv noch dauerhaft sichtbar. - Wiederfinden und Re-Grounding müssen bei Bedarf bis auf die bewahrte Quellenebene reichen können. Diese Baseline bezieht sich auf die interne Kanshō-Quellhaltung. Sie erlaubt weder eine unminimierte Weitergabe an externe Modelle noch externe Provider-Speicherung; hierfür gelten weiterhin die Regeln aus `guardrails.md`. ### Später auszuarbeitende Fragen Die dauerhafte Organisation sehr großer Textmengen wurde bisher noch nicht im erforderlichen Umfang konzipiert. Später zu klären sind insbesondere: - fachliche Lebenszyklen zwischen aktiv, ruhend, archiviert und bei Bedarf reaktiviert, - konsolidierte Sichten und Retrieval über viele Jahre, ohne eine unüberschaubare Zahl sichtbarer Einzelobjekte zu erzeugen, - Granularität, Versionierung, Indexierung und technische Speicherstufen der Quellen, - Umgang mit echten Duplikaten, Varianten und Korrekturen, ohne zeitliche Perspektiven oder Provenance zu verlieren, - Auswirkungen einer ausdrücklichen Löschung auf Ableitungen, Indizes, Backlinks, Exporte sowie bereits nach Obsidian oder mindnet überführte Inhalte, - Rollen, Berechtigungen, Nachvollziehbarkeit und technische Ausführung administrativer Löschungen, - Kapazitäts-, Kosten-, Offline- und Synchronisationsgrenzen über sehr lange Nutzungszeiträume. Diese offenen Punkte dürfen die entschiedene Default-Quellbewahrung nicht stillschweigend in eine automatische inhaltliche Lösch- oder Vergessenslogik umdeuten. --- --- ## Langfristige Reflexions- und Persistenzarchitektur – fachliche Vertiefung **Status: fachliche Baseline in wesentlichen Teilen entschieden; einzelne Objektgrenzen und technische Umsetzung offen** Dieser Abschnitt ergänzt die bereits entschiedene Default-Quellbewahrung und die Kontinuitätsarbeit um ein fachliches Modell für langfristige Reflexionskontinuität, Bedeutungsorganisation, Promotion, Konsolidierung und Retrieval. Die hier beschriebenen Regeln ersetzen keine der vorangehenden Aussagen. Insbesondere bleiben die bisherigen Regeln zur Quellbewahrung, zum Re-Grounding, zur Rolle von mindnet und zur Trennung von sichtbaren Outputs und interner Kontinuitätsarbeit unverändert bestehen. ### Root Cause Kanshō soll über Jahre und perspektivisch Jahrzehnte hinweg sinnvolle Reflexionsdialoge führen können. Dafür reicht weder ein einzelnes LLM-Kontextfenster noch eine undifferenzierte Sammlung von Sessions, Summaries oder Embeddings. Gleichzeitig darf die Langzeitarchitektur nicht zu einem zweiten mindnet werden und nicht dazu führen, dass Kanshō an der Oberfläche zu einem komplexen Wissens- oder Datenverwaltungsprodukt wird. Die ursprüngliche Nutzenvision bleibt: > **Kanshō ist primär ein langfristiger persönlicher Reflexionsbegleiter. Die interne Langzeitarchitektur dient dazu, relevante frühere Gespräche, Erkenntnisse, offene Fäden und Entwicklungen sinnvoll in neue Dialoge einzubeziehen.** ### Produktleitplanke: Dialogue Utility First **Status: entschieden** Die Langzeit- und Persistenzarchitektur wird primär danach beurteilt, ob sie die Qualität, Kontinuität und Relevanz des Reflexionsdialogs verbessert. Daraus folgt: - Ein umfassendes Hintergrundmodell ist kein Selbstzweck. - Zusätzliche interne Struktur ist nur dann gerechtfertigt, wenn sie einen erkennbaren Nutzen für Dialogkontinuität, Re-Grounding, Wiederfinden, langfristige Entwicklung oder fachliche Integrität besitzt. - Der Nutzer soll an der Oberfläche weiterhin primär Reflexion, Achtsamkeit, Journaling, Meditation und langfristig anschlussfähige Dialoge erleben. - Die interne Struktur darf deutlich komplexer sein als die sichtbare UX, muss aber dem Produktnutzen dienen. Dies konkretisiert das bereits geltende Prinzip einer einfachen Nutzeroberfläche bei reichhaltiger interner Intelligenz. --- ## Fachliches Persistenzmodell **Status: Baseline entschieden** Für die langfristige Informationsorganisation wird folgende fachliche Schichtung verwendet: > **Source → Reflection State → Derived → Retrieval → Promoted Knowledge** Diese Schichten beschreiben fachliche Verantwortungen und noch keine konkreten Datenbanktabellen oder Technologien. ### 1. Source Layer Der Source Layer enthält die ursprünglichen beziehungsweise verlässlich rekonstruierbaren Quellen. Dazu gehören insbesondere: - Sessions, - User Messages, - AI Messages als Bestandteil des historischen Dialogverlaufs, - relevante Message- oder Source-Segmente, - gegebenenfalls Audio, Transkripte, Bilder und Anhänge, - Zeitbezug, - Herkunft und technische Provenance. Verbindliche Regeln: - Die Primärquelle wird nicht durch Summaries, Memories, Interpretationen oder Modelle ersetzt. - Eine Quelle kann später mehrfach fachlich zugeordnet oder referenziert werden, ohne dadurch dupliziert werden zu müssen. - KI-Antworten sind Teil des historischen Dialogs, aber fachliche Interpretationen, die daraus entstehen, bleiben separat als abgeleitete Strukturen nachvollziehbar. ### 2. Reflection State Layer Der Reflection State Layer beschreibt den fachlichen Zustand langlebiger Reflexionsstrukturen. Dazu gehören insbesondere: - Threads, - Reflection Spaces, - offene Fragen, - Resurfacing Anchors, - aktuelle Relevanz, - fachliche Zustände, - zeitliche Zustandsentwicklung. Verbindliche Invariante: > **Bedeutungsvolle Zustandsänderungen müssen historisch nachvollziehbar bleiben; der aktuelle Zustand darf die Vergangenheit nicht zerstören.** Ein aktueller State darf für die operative Nutzung materialisiert werden. Frühere States müssen für Point-in-Time-Rekonstruktion, Re-Grounding und Entwicklungsbetrachtungen jedoch erhalten beziehungsweise zuverlässig rekonstruierbar bleiben. Eine Zustandsänderung soll fachlich mindestens nachvollziehbar machen können: - welches Objekt betroffen war, - vorheriger Zustand, - neuer Zustand, - Zeitpunkt, - Anlass beziehungsweise Trigger, - zugrunde liegende Quellen, - Ursprung der Änderung, beispielsweise Nutzer, KI-Ableitung, Bestätigung oder Re-Grounding. Die konkrete technische Umsetzung über Versionstabellen, Change Ledger oder Event Sourcing ist noch offen. ### 3. Derived Layer Der Derived Layer enthält fachliche Verdichtungen, Interpretationen und daraus abgeleitete Reflexionsobjekte. Dazu können gehören: - Session Outcomes, - Thread Summaries, - Reflection Memories, - Insights, - Hypothesen, - Pattern Candidates, - Self-Model-Kandidaten, - konsolidierte Langzeitbeschreibungen. Für abgeleitete Strukturen gilt: - Sie müssen auf ihre Ursprungsquellen zurückführbar sein. - Sie benötigen Zeitbezug. - Status und Unsicherheit müssen unterscheidbar sein. - Beobachtung, Interpretation, Hypothese und bestätigte Erkenntnis dürfen nicht stillschweigend gleichgesetzt werden. - Eine spätere Korrektur darf den historischen früheren Interpretationszustand nicht unkenntlich machen, wenn dieser für Point-in-Time-Rekonstruktion relevant ist. ### 4. Retrieval Layer Der Retrieval Layer dient der situativ relevanten Auswahl aus der langfristig gespeicherten Informationsbasis. Er ist fachlich kein zusätzlicher Wahrheits- oder Wissensspeicher. Retrieval-Strukturen können später beispielsweise Suchindizes, semantische Repräsentationen oder andere Zugriffshilfen enthalten. Verbindliche Regel: > **Retrieval-Strukturen müssen aus kanonischen Quellen und fachlichen Zuständen wieder ableitbar sein und dürfen nicht selbst zur alleinigen Source of Truth werden.** ### 5. Promoted Knowledge Layer Nicht jede Reflexion wird Teil des allgemeinen persönlichen Wissensnetzes. Langfristig relevantes und geeignetes Wissen kann aus Kanshō nach mindnet überführt beziehungsweise mit mindnet verbunden werden. Dabei gilt: - Kanshō bewahrt die Dialog-, Erlebnis- und Reflexionsgeschichte. - mindnet übernimmt die langfristige Wissens- und Beziehungsintegration. - Eine Überführung nach mindnet soll die Kanshō-Quelle nicht ersetzen. - Beziehungen zwischen Kanshō und mindnet sollen möglichst referenziell und bidirektional nachvollziehbar sein. Die ältere vereinfachte Formulierung > **Kanshō besitzt den Dialog. mindnet besitzt das langfristige Gedächtnis.** bleibt als frühere Arbeitsvereinfachung erhalten, wird fachlich aber präzisiert: > **Kanshō besitzt die langfristige Dialog-, Erlebnis- und Reflexionsgeschichte. mindnet besitzt das langfristig integrierte persönliche Wissensnetz. Obsidian bildet weiterhin die menschenlesbare autobiografische Archiv- und Exportebene.** --- ## Source Retention ist nicht Active Memory **Status: entschieden** Die bereits festgelegte Default-Quellbewahrung darf nicht dazu führen, dass langfristig jede gespeicherte Information gleichrangig aktiv bleibt. Daher gilt: > **Die Rohhistorie darf groß werden. Der aktive Bedeutungsraum muss klein, strukturiert und konsolidierbar bleiben.** Kanshō unterscheidet damit zwischen: - vollständig beziehungsweise verlässlich bewahrter Quellenhistorie, - operativ relevanten aktiven Reflexionsstrukturen, - ruhenden beziehungsweise historischen Strukturen, - selektiv abgeleiteten und konsolidierten Repräsentationen. Eine historische Session kann dauerhaft als Quelle bestehen, ohne im normalen Kontextaufbau ständig berücksichtigt zu werden. --- ## Reflection Graph statt Reflection Datalake **Status: fachliche Richtung entschieden; konkrete Ontologie offen** Langfristige Reflexionskontinuität soll nicht primär durch eine flache Sammlung von Sessions, Summaries und Embeddings organisiert werden. Stattdessen benötigt Kanshō eine fachliche Beziehungsstruktur über langlebige Reflexionsobjekte. Vorläufiger Arbeitsbegriff: > **Reflection Graph** Der Reflection Graph ist kein zweites mindnet. Er organisiert primär: - Reflection Spaces, - Threads, - relevante Experiences, - offene Fragen, - Reflection Memories beziehungsweise Insights, - zeitliche Zustände, - Resurfacing, - Entwicklungs- und Provenance-Beziehungen. mindnet organisiert demgegenüber allgemeines langfristiges persönliches Wissen, Entitäten, Beziehungen, Werte, Entscheidungen, Erfahrungen und Wissenszusammenhänge. Kanshō soll allgemeine Personen-, Wissens-, Werte- und Entitätsmodelle nach Möglichkeit referenzieren statt sie vollständig zu duplizieren. --- ## Enrichment before Proliferation **Status: entschieden** Um eine unkontrollierte Vermehrung langlebiger Reflexionsobjekte zu vermeiden, gilt: > **Bestehende Bedeutungsstrukturen werden erweitert, bevor neue dauerhafte Strukturen erzeugt werden.** Beispiele: - Eine neue Aussage zu einem bereits bestehenden Reflexionsfaden soll bevorzugt den vorhandenen Thread anreichern. - Eine neue Perspektive zu einem bekannten Reflection Space soll nicht automatisch einen neuen Space erzeugen. - Mehrere ähnliche Urlaubserlebnisse müssen nicht jeweils zu dauerhaften Experiences werden. - Wiederkehrende Einzelbeobachtungen können später in eine konsolidierte Aussage überführt werden. Semantische Ähnlichkeit allein reicht jedoch nicht, um verschiedene Bedeutungen zusammenzuführen. Bei Unsicherheit muss getrennte Provenance erhalten bleiben. --- ## Konsolidierung ohne Verlust der Evidenz **Status: entschieden** Kanshō darf operative Reflexionsstrukturen langfristig verdichten, sofern die zugrunde liegenden Quellen erhalten und wieder erreichbar bleiben. Beispiel: Aus vielen einzelnen Quellen zu Schwimmen, Wandern, Spazierengehen oder anderen Aktivitäten im Urlaub kann später eine konsolidierte Beobachtung entstehen wie: > „In deinen bisherigen Urlauben spielt körperliche Aktivität häufig eine wichtige Rolle.“ Die einzelnen Quellen müssen dafür nicht alle dauerhaft als aktive eigenständige Experiences repräsentiert werden. Verbindliche Regeln: - Konsolidierung reduziert operative Komplexität. - Konsolidierung löscht die Evidenz nicht. - Der Geltungsbereich einer Verdichtung darf nicht unzulässig erweitert werden. - Aus häufigen Aktivitäten in bisherigen Urlauben darf nicht ohne zusätzliche Evidenz eine universelle Aussage wie „Du brauchst immer Sport, um dich zu erholen“ werden. - Eine Verdichtung bleibt Derived und muss auf ihre Quellen zurückführen können. Arbeitsprinzip: > **Consolidation reduces operational complexity without erasing evidence or inflating certainty.** --- ## Promotion und langlebige Identität **Status: Baseline entschieden; konkrete Schwellenwerte offen** Nicht jedes im Dialog erkannte Element erhält sofort eine langlebige fachliche Identität. Für potenziell langlebige Reflexionsobjekte gilt ein allgemeiner Promotion-Lifecycle: > **Transient → Candidate → Established** ### Transient Ein Element ist zunächst nur Bestandteil des unmittelbaren Dialog- beziehungsweise Quellenkontexts. Beispiele: - Nebenbemerkung, - spontane Beobachtung, - kurzfristige Interpretation, - möglicher Zusammenhang. ### Candidate Ein Element erscheint potenziell längerfristig relevant und soll über weitere Kontexte beobachtbar bleiben. Beispiele: - Thread Candidate, - Experience Candidate, - Insight Candidate, - Pattern Candidate, - Reflection Frontier Candidate. Candidate ist fachlich primär ein Lifecycle-Zustand und nicht zwingend eine eigene sichtbare Objektklasse. ### Established Ein Element erhält eine dauerhafte eigenständige fachliche Identität, wenn ausreichend Bedeutung oder Fortsetzungswert vorliegt. Dabei gilt: > **Langlebige Reflexionsobjekte entstehen nicht allein aus Häufigkeit oder semantischer Ähnlichkeit. Sie werden promoted, wenn sie eigenständige zukünftige Bedeutung besitzen.** Die konkrete Bedeutung ist objektspezifisch. --- ## Significance Gate für Experiences **Status: fachliche Baseline entschieden** Nicht jedes erwähnte Ereignis wird zu einer dauerhaften Experience. Eine Experience erhält langfristige eigenständige Bedeutung insbesondere aufgrund folgender Signale: 1. **Explizite Bedeutung** - Der Nutzer bezeichnet das Erlebnis als wichtig, prägend, außergewöhnlich, tiefgreifend oder als Meilenstein. 2. **Biografische Neuheit** - erstmalige Erfahrung, - Wendepunkt, - Grenzerfahrung, - neuer Lebensabschnitt, - qualitativ neues Erleben. 3. **Werte- oder Zielbezug** - Verbindung zu zentralen Werten, - Lebenszielen, - richtungsweisenden Entscheidungen, - wesentlichen Rollen oder Lebensrichtungen. 4. **Langfristige Reflexionswirkung** - das Erlebnis wird später wieder aufgegriffen, - verändert andere Perspektiven, - löst neue offene Fragen oder Threads aus. 5. **Vernetzungsrelevanz** - mehrere bedeutsame Beziehungen zu anderen Experiences, Threads, Spaces oder mindnet-Inhalten. 6. **Rückwirkend erkannte Bedeutung** - ein zunächst unscheinbares Ereignis wird durch spätere Entwicklungen biografisch relevant. ### Nutzerautorität Verbindliche Prioritätsregel: > **Explizite Bedeutungszuweisung durch den Nutzer überstimmt algorithmische Signifikanzbewertung.** Wenn der Nutzer ein Erlebnis ausdrücklich als einen der wichtigsten Momente seines Lebens bezeichnet, muss es nicht erst eine technische Signifikanzschwelle erfüllen. Umgekehrt kann der Nutzer ein ungewöhnliches Erlebnis ausdrücklich als für ihn nicht weiter wichtig einordnen. ### Zeitabhängige Signifikanz Bedeutung darf sich im Zeitverlauf verändern. Ein Ereignis kann zunächst nur als Quelle bestehen, später Candidate werden und erst Jahre später als Established Experience erkannt werden. Die ursprüngliche Quelle und frühere Einordnung bleiben dabei erhalten. --- ## Experience und Landmark Experience **Status: fachliche Richtung; konkrete technische Modellierung offen** Für langlebige Experiences kann fachlich zwischen mindestens zwei Bedeutungsstufen unterschieden werden: ### Established Experience Ein langfristig relevantes Erlebnis beziehungsweise eine relevante Episode. ### Landmark Experience Ein besonders biografisch bedeutsames Erlebnis, beispielsweise: - Wendepunkt, - erstmalige außergewöhnliche Erfahrung, - bedeutender Erfolg oder Misserfolg, - zentrale Lebensentscheidung, - prägender Verlust, - erfüllter Lebenstraum, - Bucket-List-Ereignis, - Erfahrung mit möglicher nachhaltiger Veränderung der eigenen Weltsicht. Ob `Landmark Experience` später eine eigene technische Entität, ein Status, eine Klassifikation oder ein Attribut wird, ist ausdrücklich offen. --- ## Beispiel: Meditationserlebnis mit Mehrfachzuordnung **Status: Referenzbeispiel für die Architektur** Beispielhafte Quelle: > „Gestern habe ich meinen Urlaubstag dazu genutzt, tief zu meditieren. Dabei ist es bei mir zum ersten Mal vorgekommen, dass ich das Gefühl hatte, meinen Körper zu verlassen. Das war eine tiefgreifende Erfahrung.“ Dieses Beispiel zeigt, dass fachliche Identität und fachliche Zuordnung getrennt werden müssen. Die ursprüngliche Aussage beziehungsweise Source besitzt eine kanonische Quellenidentität. Das daraus beschriebene Erlebnis kann gleichzeitig relevant sein für: - den chronologischen Urlaubskontext, - ein Urlaubstagebuch, - einen Reflection Space Meditation, - einen langfristigen Thread zur persönlichen Meditationsreise, - persönliche Entwicklung, - gegebenenfalls Bucket-List- oder Lebensmeilenstein-Kontext, - später daraus entstehende Insights. Verbindliche Regel: > **Mehrfachzuordnung erzeugt keine Duplikation der Primärquelle.** Ob das Erlebnis selbst eine dauerhafte Experience wird, hängt von seiner Signifikanz ab. Im genannten Beispiel sprechen insbesondere Erstmaligkeit, explizit beschriebene Tiefe und eine mögliche nachhaltige Bedeutung für die eigene Bewusstseins- oder Meditationsentwicklung für einen starken Experience Candidate beziehungsweise eine spätere Established oder Landmark Experience. --- ## Thread-Promotion und Thread-Lifecycle **Status: fachliche Baseline entschieden; technische State-Ausprägung offen** Für Threads wird dieselbe allgemeine Promotion-Philosophie verwendet wie für Experiences, aber mit einem anderen fachlichen Signifikanzkriterium. Leitfrage: > **Gibt es hier etwas, über das über die konkrete Gesprächssituation hinaus sinnvoll weitergedacht werden kann?** Ein dauerhaft eigenständiger Thread ist insbesondere sinnvoll, wenn: - der Nutzer ausdrücklich weiter darüber nachdenken oder später weiterreden möchte, - eine offene Frage oder Spannung bestehen bleibt, - dasselbe Thema in mehreren Sessions wiederkehrt, - das Thema mit Werten, Zielen, Rollen oder wichtigen Entscheidungen verbunden ist, - eine relevante Experience einen längerfristigen Denkprozess auslöst, - neue Ereignisse einen bestehenden Gedanken verändern, - mehrere Gesprächspassagen sinnvoll denselben Reflexionsfaden fortsetzen. Nicht jedes wiederkehrende Thema ist automatisch ein Thread. Beispielsweise erzeugen wiederholte Erwähnungen von Schwimmen im Urlaub nicht zwangsläufig einen langlebigen Thread „Schwimmen im Urlaub“. Daraus kann stattdessen eine konsolidierte Beobachtung entstehen. Arbeitsdefinition: - **Experience:** Etwas Bedeutsames ist passiert. - **Insight / Reflection Memory:** Etwas Bedeutsames wurde erkannt. - **Thread:** Etwas Bedeutsames ist im Denken noch in Bewegung. - **Reflection Space:** Mehrere längerfristig zusammenhängende Reflexionsstrukturen bilden einen größeren Reflexionsraum. ### Thread-Promotion Vorläufig: > **Session Topic → Thread Candidate → Continuity/Significance Gate → Existing Thread Enrichment oder Established Thread** Wenn ein passender bestehender Thread existiert, soll dieser bevorzugt angereichert werden. ### Thread-Zustände Als bereits vorhandene fachliche Baseline bleiben insbesondere relevant: - Active, - Open, - Anchored / Resurface, - Dormant, - Resolved, - gegebenenfalls Reopened. Die konkrete technische Zustandsmaschine bleibt offen. --- ## Eigene Identität und Zuordnung sind getrennt **Status: entschieden** Ein fachliches Objekt erhält nicht deshalb eine zweite Identität, weil es in mehreren Kontexten relevant ist. Ein und dieselbe Experience kann beispielsweise gleichzeitig Beziehungen besitzen zu: - Urlaub, - Meditation, - persönlicher Entwicklung, - einem Reflection Space, - einem Thread, - einem späteren Jahresrückblick. Damit wird verhindert, dass verschiedene Sichten auf dasselbe Ereignis zu voneinander unabhängigen Kopien auseinanderlaufen. --- ## Vorläufige langlebige Kernobjekte **Status: Arbeitsmodell; noch nicht endgültig entschieden** Für die weitere fachliche Modellierung werden derzeit folgende langlebige Objektkandidaten betrachtet: - Session, - Message beziehungsweise referenzierbares Source Segment, - Thread, - Reflection Space, - Open Question, - Experience, wenn ausreichend signifikant, - Reflection Memory / Insight, wenn etabliert, - Resurfacing Anchor. `State History` wird derzeit eher als Historie beziehungsweise Eigenschaft langlebiger Objekte betrachtet und nicht als eigenständiges fachliches Hauptobjekt. `Candidate` ist primär ein Lifecycle-Zustand möglicher langlebiger Objekte. Die endgültige Liste langlebiger Entitäten ist ausdrücklich noch offen und soll nicht vorschnell technisch festgeschrieben werden. --- ## Relationship Layer des Reflection Graph **Status: fachliche Baseline; konkrete Relationstypologie offen** Langlebige Reflexionsobjekte müssen Beziehungen untereinander sowie zu externen Jinkendo-Objekten besitzen können. Für den aktuellen Reifegrad werden nur wenige allgemeine Beziehungsklassen festgelegt: ### Structural Beispiele: - gehört zu, - ist Teil von, - wird in einem Space behandelt. ### Semantic Beispiele: - steht inhaltlich in Beziehung zu, - betrifft ein ähnliches oder verbundenes Thema. ### Temporal / Developmental Beispiele: - entwickelte sich aus, - folgte auf, - veränderte sich, - wurde wieder geöffnet. ### Evidence / Provenance Beispiele: - basiert auf, - wurde abgeleitet aus, - wird durch folgende Quellen gestützt. ### Cross-System Beispiele: - verweist auf mindnet, - wurde nach mindnet überführt, - steht mit Kairo oder Obsidian in Beziehung. Ein detaillierter Relationskatalog wie `CONTRADICTS`, `SUPPORTS`, `TRIGGERED_BY`, `TENSION_WITH` oder ähnliche Typen wird erst später bei nachgewiesenem Bedarf ausgearbeitet. --- ## Provenance und mindnet-Verknüpfung **Status: entschieden** Verdichtungen, Interpretationen und etablierte Erkenntnisse müssen auf ihre Ursprungsquellen zurückführbar sein. Dies gilt insbesondere für: - Summaries, - Reflection Memories, - Insights, - Patterns, - Hypothesen, - Self-Model-Aussagen, - konsolidierte Langzeitbeschreibungen. Für mindnet gilt: > **Verbindungen zwischen Kanshō und mindnet sollen möglichst referenziell und bidirektional nachvollziehbar sein.** Beispiel: - Kanshō Insight → `promoted_to` → mindnet Node - mindnet Node → `originated_from` → Kanshō Insight - Kanshō Insight → `source` → relevante Dialogpassagen Damit kann langfristiges Wissen bei Bedarf bis auf die ursprüngliche Reflexion zurückgeführt werden. --- ## Zwei fachliche Retrieval-Modi **Status: Baseline entschieden** Kanshō benötigt mindestens zwei unterschiedliche Retrieval-Strategien. ### Meaning-oriented Retrieval Standard für laufende Reflexionsdialoge. Vorläufige fachliche Reihenfolge: > **aktueller Kontext → relevante Reflection Spaces → relevante Threads → aktuelle beziehungsweise historische States / Insights / Open Questions → relevante Experiences → bei Bedarf Sessions und Originalquellen** Ziel ist nicht maximale Vollständigkeit, sondern situativ relevante Kontinuität. ### Source-oriented Retrieval Für: - Nachschlagen, - historische Direktfragen, - Re-Grounding, - Point-in-Time-Rekonstruktion, - Prüfung früherer Aussagen. Hier darf der Zugriff direkt von: - Datum, - Session, - Ereignis, - Person, - konkreter Referenz auf Primärquellen beziehungsweise damalige States führen. Beispiel: > „Was habe ich am 19. August 2026 über meine Meditation gesagt?“ Eine solche Frage soll nicht erst über aktuelle Thread-Summaries beantwortet werden, sondern quellenorientiert recherchierbar sein. --- ## Intent-unabhängiger Kern und spätere Integrationspunkte **Status: entschieden als Arbeitsgrenze für die aktuelle Konzeptphase** Die hier definierte Memory- und Persistenzarchitektur wird bewusst unabhängig von der endgültigen Ausgestaltung der einzelnen Usage Situations und Reflection Intents entwickelt. Folgende Punkte bleiben spätere Integrationsfragen: - welche Memory-Objekte bei welchem Intent typischerweise entstehen, - wann bestimmte Intents automatisch oder optional Journal Entries erzeugen, - intent-spezifische Saturation- oder Resurfacing-Regeln, - intent-spezifische Priorisierung oder Retention abgeleiteter Strukturen, - genaue Output-Policies je Nutzungssituation. Der intent-unabhängige Kern muss stabil bleiben, auch wenn sich die konkrete Nutzungstypologie später verändert. --- ## Technische Stopplinie für diesen Konzeptblock **Status: entschieden** Die folgenden Punkte werden in diesem fachlichen Memory-/Persistenzblock noch nicht verbindlich technisch festgelegt: - PostgreSQL als Primärspeicher, - konkrete SQL-Tabellen, - Event Sourcing oder Change Ledger, - Neo4j oder andere Graphdatenbanken, - konkrete Qdrant-Collections, - Embedding-Modelle und Chunking, - konkrete Ranking-Algorithmen, - Object Storage, - SQLite oder andere Offline-Datenbanken, - Sync-Protokolle, - API-Schemas, - konkrete mathematische Significance Scores. Diese Elemente bleiben technische Architekturhypothesen beziehungsweise spätere Entscheidungen des Data-/Technical-Architecture-Blocks. Die fachlichen Anforderungen aus diesem Dokument bilden die Grundlage für diese spätere technische Auswahl. --- ## Noch offene Punkte dieses Fachblocks Trotz der nun deutlich konkretisierten Baseline bleiben insbesondere offen: 1. die endgültige Liste langlebiger fachlicher Entitäten, 2. die genaue Abgrenzung von `Open Question`, `Insight`, `Reflection Memory` und gegebenenfalls weiteren abgeleiteten Objektklassen, 3. die objektspezifischen Promotion- und Konsolidierungsregeln jenseits der bereits geklärten Experience- und Thread-Baseline, 4. die konkrete Lebenszykluslogik für Reflection Spaces, 5. die genaue Relevanz- und Aktivierungslogik im Reflection Graph, 6. die spätere Integration mit dem finalen Usage-/Intent-Modell, 7. die technische Umsetzung der fachlichen Versionierung und Provenance, 8. die technische Data Architecture und Retrieval-Implementierung. Diese offenen Punkte sollen gezielt weiterbearbeitet werden. Sie ändern nicht die in diesem Abschnitt bereits entschiedenen fachlichen Invarianten. --- ## Context Builder und Memory Orchestration **Status: fachliche Baseline entschieden; konkrete technische Implementierung offen** Die bisherige Memory- und Persistenzarchitektur wird um eine explizite Context-Builder- und Memory-Orchestration-Logik ergänzt. ### Root Cause Kanshō bewahrt langfristig deutlich mehr Informationen, als in einem einzelnen Reflexionsdialog gleichzeitig sinnvoll aktiv sein können. Die primäre Produktintention ist jedoch nicht, bei jedem Dialogturn das gesamte autobiografische Langzeitgedächtnis zu aktivieren. Kanshō soll primär innerhalb des aktuellen Reflexionsraums arbeiten und langfristige Informationen nur dann hinzuziehen, wenn sie den aktuellen Dialog tatsächlich verbessern. Zusätzlich gilt für modellbasierte API-Nutzung: Ein laufender Gesprächszustand kann technisch je nach Provider unterstützt oder referenziert werden, dennoch bleibt die Modellverarbeitung an ein endliches Kontextfenster und an Token-, Kosten- und Latenzgrenzen gebunden. Kanshō darf deshalb weder fachlich noch technisch davon ausgehen, dass unbegrenzt viel Langzeitkontext dauerhaft aktiv gehalten werden kann. ### Produktinvariante: Reflection Space first, Long-Term Memory on demand **Status: entschieden** Für normale Reflexionsdialoge gilt: > **Kanshō arbeitet standardmäßig innerhalb des aktuellen Reflexionsraums. Langzeitgedächtnis und mindnet erweitern diesen Raum nur bei konkreter fachlicher Relevanz.** Daraus folgt: - Der aktuelle Dialog und der aktuelle Reflection Space besitzen Vorrang. - Aktive Threads, offene Fragen und aktuelle relevante Insights werden bevorzugt aus diesem Reflexionskontext bezogen. - Tieferes Kanshō-Langzeitgedächtnis wird nur bei Bedarf aktiviert. - mindnet ist keine standardmäßig bei jedem Dialogturn zu konsultierende Quelle. - Globale autobiografische Suche ist eine Fähigkeit für relevante Situationen, nicht der Normalmodus jeder Reflexion. Verbindliche Negativregel: > **The normal reflection experience must not depend on global memory traversal.** ### Retention, Activation und Relevance sind getrennte Konzepte **Status: entschieden** > **Retention ≠ Activation ≠ Relevance** Das bedeutet: - Eine Information kann dauerhaft gespeichert sein, ohne aktuell aktiviert zu werden. - Eine Information kann prinzipiell abrufbar sein, ohne für den aktuellen Dialog relevant zu sein. - Eine semantisch ähnliche Information ist nicht automatisch fachlich relevant. - Der Context Builder soll nur den kleinsten ausreichenden Ausschnitt aktivieren, der den nächsten Dialogschritt sinnvoll verbessert. Damit gilt ergänzend: > **Availability is not relevance.** ### Drei operative Kontextebenen **Status: fachliche Baseline entschieden** #### Active Context Unmittelbar benötigter Kontext der laufenden Session: aktuelle Nachricht, relevante Vorgänger, aktuelle Frage, Session-Zustand und notwendige Instruktionen. #### Reflection Context Der aktuelle fachliche Reflexionsraum: Primary Reflection Space, relevante Related Spaces, aktive Threads, offene Fragen, relevante Insights, Experiences und notwendiger Personal Context. #### Latent Long-Term Memory Langfristig erhaltene, aber nicht standardmäßig aktive Informationen: ältere Sessions, ruhende Threads, ältere Experiences und States, tieferes Personal Model, weiter entfernte Spaces, mindnet-Zusammenhänge sowie Primärquellen für Re-Grounding. Latent Long-Term Memory bleibt auffindbar, wird aber nur bei konkretem Bedarf aktiviert. ## Gestufte Retrieval-Eskalation **Status: Baseline entschieden** Bevorzugte fachliche Reihenfolge: > **Current Session → Primary Reflection Space → Active Threads / Open Questions → relevanter Reflection Context → relevantes Kanshō Long-Term Memory → mindnet → Original Sources / Re-Grounding bei Bedarf** Dabei gilt: > **So tief wie nötig, nicht so tief wie möglich.** Tiefe Retrieval-Schritte werden insbesondere durch explizite historische Referenzen, wiederaufgenommene Threads, offene Fragen, relevante frühere Experiences/Insights, Widersprüche, Werte-/Zielbezug, niedrige Confidence, unklare Provenance oder Re-Grounding-Bedarf ausgelöst. Semantische Ähnlichkeit allein reicht nicht. ## Relevanzdimensionen des Context Builders **Status: fachliche Baseline entschieden; konkrete Gewichtung offen** Mindestens relevant sind: - Dialognähe, - Reflection-Space-Zugehörigkeit, - Thread Continuity, - Open Loop, - Explicit Reference, - Temporal Relevance, - Personal Significance, - Development Relevance, - Values / Goals / Roles, - Confidence / Fidelity, - Contradiction / Change. Verbindliche Regel: > **Meaning before semantic similarity.** ## Minimum Sufficient Context **Status: entschieden** > **Minimum sufficient context for the next meaningful reflection step.** Der Context Builder optimiert nicht auf maximale Erinnerung, sondern auf ausreichend hochwertigen Kontext bei möglichst geringem Prompt- und Verarbeitungsumfang. Gefundene Retrieval-Kandidaten werden nicht automatisch vollständig in den Modellkontext übernommen. > **Retrieval finds candidates. Context Assembly decides what is actually injected.** ## Context Budgeting **Status: Architekturprinzip entschieden; konkrete Tokenbudgets offen** Der aktive Modellkontext ist eine begrenzte Ressource. Priorisierbar sein sollen mindestens: - stabile Instruktionen, - aktuelle Conversation History, - aktueller Reflection Context, - selektierter Long-Term Context, - relevanter Personal Context, - Originalquellen beziehungsweise Re-Grounding-Material. > **Mehr verfügbarer Kontext rechtfertigt nicht automatisch einen größeren Prompt.** ## Context Builder als Applikationsfunktion **Status: entschieden** Der Context Builder wird primär als Funktion der Kanshō-Anwendung verstanden und nicht als Kette eigenständiger LLM-Agenten. Soweit fachlich sinnvoll, sollen Datenbankabfragen, State Lookup, Reflection-Graph-Beziehungen, Zeit-/Statusfilter, Indizes, semantisches Retrieval und deterministische Regeln vor einem generativen Modellaufruf genutzt werden. > **Retrieve locally first; use model reasoning where semantic interpretation materially adds value.** ## Hot Path und Enrichment Path **Status: fachliche Baseline entschieden** ### Hot Path Typischer Ablauf: > **User Message → Current/Session State → relevanter Reflection Context → leichter Retrieval-/Fidelity-Check → Context Assembly → Hauptmodell → Antwort** Designziel: > **Ein wesentlicher generativer Hauptmodell-Call pro Dialogturn ist der Normalfall.** Zusätzliche Modellaufrufe sind zulässig, wenn sie fachlich notwendig sind, sollen aber nicht durch die Grundarchitektur bei jedem Turn erzwungen werden. ### Enrichment Path Kann unter anderem enthalten: - Pattern-Erkennung, - Konsolidierung, - Promotion Candidates, - Reflection-Space-Neubewertung, - Personal-Model-Re-Evaluation, - Relationship-Analyse, - Policy-Learning, - tieferes Re-Grounding, - langfristige Zusammenführung mehrerer Sessions. > **Additional model calls are exception paths, not the normal reflection path.** ## Inkrementeller Working- und Session-State **Status: fachliche Baseline entschieden** Während einer laufenden Session soll bereits aufgebauter Kontext inkrementell fortgeschrieben werden, statt ihn bei jedem Turn vollständig neu herzuleiten. Fachlich kann dieser State insbesondere enthalten: - aktuelle Session, - Primary Reflection Space, - relevante Related Spaces, - aktive Threads, - offene Fragen, - kürzlich relevante Insights, - bereits selektierten Personal Context, - zuletzt verwendete Memory-Referenzen, - Session-Summary beziehungsweise Verdichtung, - Fidelity-/Re-Grounding-Status. > **Incremental context before full reconstruction.** ## Provider Conversation State und Prompt Caching **Status: Architekturgrenze entschieden; Provider-spezifische Umsetzung offen** Providermechanismen für Conversation State, Response Chaining oder Prompt Caching dürfen als Laufzeitoptimierung genutzt werden. Sie verändern jedoch nicht die fachliche Datenhoheit: > **Provider state is an optimization, not memory ownership.** Kanshō bleibt Source of Truth für Dialogquellen, fachliche Zustände, Reflection Spaces, Threads, Provenance und langfristige Memory-Strukturen. ## Kosten und Latenz als Qualitätsdimension **Status: entschieden** Kosten und Antwortlatenz sind neben Dialogqualität und Context Fidelity relevante Qualitätsdimensionen des Context Builders. > **Maximale ausreichende Reflexionsqualität mit minimal notwendigem Kontext und minimal notwendiger Modellarbeit.** Qualitätskritische Re-Grounding-, Konflikt- oder historische Rekonstruktionsschritte dürfen zusätzliche Kosten verursachen, wenn sie fachlich notwendig sind. ## Reflection-Space-Erkennung im Context Builder **Status: fachliche Baseline entschieden; detaillierter Lifecycle bleibt kanonisch in `reflection_spaces.md`** Kanshō soll Reflection Spaces möglichst selbstständig erkennen beziehungsweise einen bestehenden Space fortsetzen können. Die Erkennung soll jedoch nicht standardmäßig einen separaten LLM-Aufruf pro Dialogturn erzwingen. Bevorzugte Reihenfolge: 1. bestehenden aktiven Space berücksichtigen, 2. Zeit-, Orts-, Session- und Metadatenkontext nutzen, 3. bestehende Thread- und Space-Beziehungen prüfen, 4. semantische beziehungsweise Retrieval-Signale nutzen, 5. den ohnehin erfolgenden Hauptmodell-Call bei Bedarf strukturierte Space-Metadaten liefern lassen, 6. separaten Analyse-Call nur bei echter Ambiguität oder höherwertiger Neubewertung verwenden. > **Space recognition should normally piggyback on existing processing rather than create an additional LLM round trip.** Die genaue Entstehungs-, Promotion-, Primary-/Related- und Lifecycle-Logik bleibt kanonisch in `reflection_spaces.md`. ## Personal Model als selektiv aktivierter Kontext **Status: entschieden als Querschnittsregel** Personal Context, Interaction Profile, Self Model, Observed Patterns und weitere Personal-Model-Inhalte sind langfristig verfügbarer Kontext, aber kein permanenter Vollprompt. > **Personal Model is available context, not a permanent full prompt.** ## Aktualisierter Stand der offenen Punkte dieses Fachblocks **Status: Arbeitsstand nach Context-Builder-Klärung** Die frühere Liste offener Punkte bleibt als historischer Arbeitsstand erhalten. Weiter offen beziehungsweise bewusst später zu klären sind insbesondere: 1. die endgültige Liste langlebiger fachlicher Entitäten, 2. die technische Repräsentation von Working-/Session-State und Context Assembly, 3. konkrete Relevanzgewichtungen und Context-Budget-Regeln, 4. die konkrete technische Retrieval-Implementierung, 5. konkrete Provider-, Caching- und Conversation-State-Strategien, 6. die detaillierte Lebenszyklus- und Promotion-Logik für Reflection Spaces in `reflection_spaces.md`, 7. die generische Memory Write / Update Policy, 8. der Continuity Capability Contract, 9. die spätere Integration mit dem finalen Usage-/Intent-Modell, 10. die technische Umsetzung von Versionierung, Provenance und Datenhaltung. Nicht mehr als grundsätzlich offen gelten: - dauerhafte Aktivierung des gesamten Langzeitgedächtnisses, - standardmäßige mindnet-Konsultation bei jedem Turn, - Context Builder als LLM-Agentenkette, - separater Modellaufruf für jede Space-Erkennung, - Kosten und Latenz nur als nachgelagerte Optimierung, - Gleichsetzung von langfristiger Speicherung und aktiver Relevanz. --- ## Memory Write / Update Policy **Status: fachliche Baseline entschieden; konkrete technische Implementierung und objektspezifische Parameter offen** Die Memory Write / Update Policy regelt, welche Informationen Kanshō nach einem Dialogturn automatisch bewahren, operativ fortschreiben, als Kandidaten ableiten oder nur nach erhöhtem Evidenz- beziehungsweise Bestätigungsniveau etablieren darf. Ziel ist weder maximale Extraktion noch maximale Zurückhaltung. Kanshō soll genügend Struktur erzeugen, um langfristige Reflexionskontinuität zu ermöglichen, ohne den Dialog durch administrative Bestätigungen, Objektinflation oder unnötige KI-Verarbeitung zu belasten. ### Grundprinzip > **Source preserves. Explicit user meaning may establish directly. Model-derived meaning starts cautiously. Policy governs promotion. User correction governs current validity.** Daraus folgen vier unterschiedliche fachliche Schreibarten. ### 1. Source Write Quellen werden entsprechend der bestehenden Default-Quellbewahrung unmittelbar und ohne Significance Gate erhalten. Dazu gehören insbesondere: - User Messages, - AI Messages als historischer Dialogbestandteil, - Sessions, - relevante Anhänge und Eingaben, - Zeitbezug und technische Provenance. Für Source Writes gilt keine vorgelagerte Frage, ob eine Aussage „wichtig genug“ ist. Ihre spätere Bedeutung darf sich erst im Zeitverlauf zeigen. ### 2. Operational State Update Reversible operative Zustände dürfen grundsätzlich automatisch fortgeschrieben werden, sofern frühere Zustände, Provenance und Korrigierbarkeit erhalten bleiben. Dazu können insbesondere gehören: - aktueller Session State, - bestehender Primary Reflection Space, - Related Spaces, - bestehende Thread-Zuordnung, - offene Fragen, - Resurfacing Anchors, - aktuelle Thread- oder Space-Zustände. Beispiel: Ein über mehrere Tage fortgeführtes Urlaubstagebuch darf den bestehenden Reflection Space `Lošinj 2026` automatisch weiterverwenden, ohne täglich eine Nutzerbestätigung zu verlangen. ### 3. Derived Candidate Write Kanshō darf mögliche Bedeutungen selbstständig erkennen und als vorläufige Kandidaten beziehungsweise Hypothesen markieren. Dazu können gehören: - Thread Candidate, - Space Candidate, - Experience Candidate, - Insight Candidate, - Open Question Candidate, - Observed Pattern, - AI Hypothesis. Verbindliche Regel: > **Automatisch erkennen bedeutet nicht automatisch als etablierte Wahrheit übernehmen.** ### 4. Established / High-Impact Write Langlebige oder fachlich folgenreiche Strukturen unterliegen objektspezifischen Promotion Policies. Dazu können insbesondere gehören: - Established Experience, - Established Thread, - Reflection Memory, - bestätigtes Insight, - etabliertes Observed Pattern, - Self-Model-Aussage, - Promotion nach mindnet. Je langfristiger, identitätsnäher oder folgenreicher eine Aussage ist, desto höher müssen Evidenz-, Provenance- und gegebenenfalls Bestätigungsanforderungen sein. --- ## Drei Write-Autonomiestufen **Status: Baseline entschieden** Für die Implementierungslogik sollen die Write-Entscheidungen fachlich auf drei Autonomiestufen reduzierbar bleiben. ### Automatic Typischerweise: - Source Writes, - Session State, - Fortführung bestehender Threads, - eindeutige Space-Zuordnungen, - reversible operative States. ### Evidence-gated Typischerweise: - Experiences, - Insights, - Reflection Memories, - neue langlebige Threads, - neue langlebige Spaces, - längerfristige Patterns. Hier entscheidet die jeweilige Policy anhand objektspezifischer Evidenz. ### Confirmation-sensitive Typischerweise: - grundlegende Self-Model-Aussagen, - neue zentrale Werte- oder Identitätsaussagen aus Modellinferenz, - weitreichende Änderungen identitätsnaher persönlicher Modelle. Confirmation-sensitive bedeutet nicht zwingend einen separaten administrativen Bestätigungsdialog. Bestätigung kann natürlich im Reflexionsgespräch entstehen. --- ## Herkunftspfade persönlicher und abgeleiteter Aussagen **Status: fachliche Baseline entschieden** Die Write Policy muss die Herkunft einer Aussage berücksichtigen. ### Explicit User Statement Eine eindeutige Nutzeraussage kann abhängig vom Objekttyp unmittelbar ausreichend Evidenz für einen etablierten Zustand liefern. Beispiel: > „Selbstbestimmung ist für mich einer der wichtigsten Werte.“ Eine solche explizite Aussage muss nicht künstlich denselben Candidate-Prozess durchlaufen wie eine KI-Inferenz. Die Provenance bleibt dennoch erhalten: - Aussage, - Zeitpunkt, - Source Reference, - Ursprung `Explicit User Statement`. ### User/Dialog-derived Candidate Eine im Dialog entstehende Bedeutung, die nicht bereits als eindeutige explizite Nutzeraussage vorliegt, kann zunächst Candidate werden und evidenzbasiert promoted werden. ### AI-derived Hypothesis Eine von Kanshō formulierte Interpretation startet mit erhöhter Zurückhaltung. Beispiel: > „Vielleicht spielt Kontrolle bei dir eine größere Rolle, als dir bisher bewusst war.“ Diese Aussage darf allein aufgrund ihrer Formulierung durch die KI nicht zu einem bestätigten Pattern oder Self-Model-Eintrag werden. Verbindliche Regel: > **AI-generated reflection content is not automatically user memory.** Nutzeraufnahme, spätere Evidenz oder ausdrückliche Bestätigung können die Hypothese später aufwerten. --- ## Zeitgebundene Selbstaussage ist nicht automatisch stabiles Personal Model **Status: entschieden** Momentane Emotionen, Bewertungen oder Selbstbeschreibungen werden zunächst in ihrem zeitlichen Kontext bewahrt. Beispiel: > „Ich hasse meinen Job.“ Dies kann fachlich eine aktuell geäußerte starke Unzufriedenheit abbilden, darf aber nicht automatisch als zeitloses Self-Model-Merkmal gespeichert werden. Verbindliche Regel: > **Current expressed state ≠ stable identity statement.** Längerfristige Patterns oder Threads können sich erst aus späterer Evidenz beziehungsweise weiterer Reflexion entwickeln. --- ## Nutzerkorrektur und Current Validity **Status: entschieden** Explizite Nutzerkorrekturen besitzen Vorrang gegenüber fortgesetzter Modellinferenz. Beispiele: - „Das hast du falsch verstanden.“ - „Das stimmt so nicht.“ - „Das war nur damals so.“ - „Das ist für mich gar kein wichtiges Thema.“ Verbindliche Regel: > **User correction governs current validity.** Eine frühere Hypothese, Verdichtung oder Interpretation wird dadurch nicht aus der Historie gelöscht. Sie muss jedoch als verworfen, revidiert, historisch oder anderweitig nicht mehr aktuell markierbar sein und darf nicht stillschweigend weiter als aktuelle Wahrheit verwendet werden. Damit werden zwei Verantwortungen getrennt: - **History Preservation** - **Current Validity** --- ## Änderungen ergänzen statt überschreiben **Status: entschieden** Persönliche Haltungen, Werte, Prioritäten, Threads und andere zeitabhängige Zustände sollen bei Veränderung nicht einfach überschrieben werden. Beispiel: - früher: Karriere besitzt sehr hohe Bedeutung, - später: Karriere besitzt deutlich geringere Bedeutung. Der aktuelle Zustand darf sich ändern, während der frühere Zustand weiterhin Point-in-Time-rekonstruierbar bleibt. Verbindliche Regel: > **New state updates current validity; it does not erase historical validity.** --- ## Write Evaluation ist signal-driven, nicht exhaustive **Status: entschieden** Die fachlich verfügbaren Write- und Enrichment-Fähigkeiten dürfen nicht so implementiert werden, dass nach jedem Dialogturn sämtliche Objektarten vollständig neu analysiert werden. Verbindliche Regel: > **Write evaluation is signal-driven, not exhaustive.** Der Normalfall eines Dialogturns umfasst: - Source Write, - notwendigen Session-/Operational-State-Update, - nur bei tatsächlich auftretenden Signalen weitere Candidate- oder Enrichment-Verarbeitung. Die Abwesenheit eines relevanten Signals soll keine zusätzliche Memory-Analyse auslösen. > **The absence of a relevant signal should result in no enrichment work.** Beispiel: Ein alltäglicher Urlaubstagebuch-Eintrag kann vollständig mit Source Write, bestehendem Reflection Space und Session-State-Update verarbeitet werden, ohne gleichzeitig Experience-, Pattern-, Self-Model- und mindnet-Promotion zu analysieren. --- ## Modell-Signale und Policy-Entscheidung **Status: fachliche Baseline entschieden** Der ohnehin für die sichtbare Reflexionsantwort verwendete Hauptmodell-Call darf bei Bedarf wenige strukturierte Signale für die Write Policy mitliefern. Mögliche Signale können beispielsweise betreffen: - bestehender oder veränderter Thread, - relevante Open Question, - Experience Candidate, - Insight Candidate, - mögliche Personal-Model-Relevanz, - erhöhte Signifikanz, - Widerspruch beziehungsweise Korrektur, - mögliche Space-Neubewertung. Die konkrete technische Struktur dieser Signale wird hier nicht festgelegt. Verbindliches Prinzip: > **Model proposes; policy decides; source preserves.** Das Modell soll damit nicht selbst die vollständige Persistenzlogik besitzen. Die Anwendung beziehungsweise Policy entscheidet, welche Signale zu welchen Writes, Candidates oder späteren Prüfungen führen. --- ## Inline, Checkpoint und Deep Enrichment **Status: fachliche Baseline entschieden** Zur Begrenzung von Kosten, Latenz und unnötiger Modellarbeit werden drei Verarbeitungsklassen unterschieden. ### 1. Inline / Hot Muss für den unmittelbaren Dialog verfügbar sein. Typischerweise: - Source Write, - Session State, - Primary Reflection Space, - aktive Threads, - unmittelbar relevante Open Questions, - explizite Nutzerkorrekturen, - eindeutige explizite Nutzerpräferenzen. Ziel ist, hierfür keinen zusätzlichen generativen LLM-Call neben dem normalen Hauptmodell-Call zu benötigen. ### 2. Checkpoint Enrichment Kann gesammelt beziehungsweise gebündelt bewertet werden. Typischerweise: - Experience Promotion, - Insights, - Reflection Memories, - neue Threads, - neue Spaces, - begrenzte Konsolidierung. Geeignete Checkpoints können beispielsweise sein: - Session-Ende, - notwendige Zwischenverdichtung in langen Dialogen, - Übergang eines Reflection Space in einen ruhenden Zustand, - Wiederaufnahme eines längeren Reflexionsfadens. Mehrere Kandidaten sollen nach Möglichkeit gemeinsam statt durch jeweils eigene Modellaufrufe bewertet werden. ### 3. Deep Enrichment Seltenere, bewusst aufwendigere Verarbeitung. Typischerweise: - langfristige Pattern-Erkennung, - Personal-Model-Re-Evaluation, - komplexe Konsolidierung, - longitudinale Entwicklungsanalyse, - tiefes Re-Grounding, - komplexe mindnet-Promotion beziehungsweise systemübergreifende Einordnung. Deep Enrichment darf höhere Kosten und Latenz verursachen, wenn der erwartete fachliche Nutzen dies rechtfertigt. --- ## Enrichment Checkpoints und Nicht-Blockierung des Dialogs **Status: fachliche Baseline entschieden** Nicht jede langfristige Strukturentscheidung muss vor der sichtbaren Antwort abgeschlossen sein. Der normale Dialog soll nicht darauf warten müssen, dass beispielsweise: - Landmark-Signifikanz endgültig bewertet, - ein Pattern konsolidiert, - ein Self Model neu bewertet, - mindnet Promotion ausgeführt, - mehrere Sessions longitudinal analysiert wurden. Daraus folgt: > **The reflection response may complete before non-critical enrichment is finalized.** Fachlich relevante Enrichment-Signale dürfen bis zu einem geeigneten Checkpoint vorgemerkt werden. Die genaue technische Queue-, Job- oder Scheduling-Architektur ist noch nicht Teil dieses Fachblocks. --- ## Effizienz und Processing Routing **Status: Architekturprinzip entschieden; konkrete Modelle und Routing-Regeln offen** Nicht jede Verarbeitungsaufgabe benötigt dasselbe Modell oder überhaupt einen generativen LLM-Aufruf. Die spätere technische Architektur soll erlauben, Aufgaben an den jeweils ausreichend leistungsfähigen Verarbeitungspfad zu routen, beispielsweise: - deterministische Anwendungslogik, - Datenbank-/Graph-/Index-Abfrage, - Embedding-/Similarity-Verarbeitung, - kleines günstiges Modell, - Hauptdialogmodell, - stärkeres Modell für seltene komplexe Longitudinalanalysen. Verbindliches Prinzip: > **Tasks shall be routable to the least expensive sufficient processing path.** Damit wird keine konkrete Modellwahl festgeschrieben. --- ## Referenzfälle für die Write Policy **Status: fachliche Referenzbeispiele** ### Alltäglicher Urlaubstagebuch-Eintrag Typische Folge: - Source Write, - Session State aktualisieren, - bestehenden Space fortsetzen, - kein automatischer neuer Thread, - keine automatische Experience, - kein Self-Model-Write. ### Tiefgreifendes Meditationserlebnis Typische Folge: - Source Write, - bestehender Urlaubsspace bleibt Primary Space, - Meditationsreise kann Related Space beziehungsweise Candidate sein, - Experience Candidate möglich, - Thread Candidate nur bei weiterführender Reflexionsbewegung. ### Expliziter zentraler Wert Typische Folge: - Source Write, - eindeutige Explicit User Statement, - abhängig von Policy direkte Etablierung im Personal Model möglich, - Provenance bleibt erhalten. ### Momentane starke Emotion Typische Folge: - Source Write, - zeitgebundene Lived Experience, - kein automatisches stabiles Self Model. ### KI-Hypothese ohne Nutzeraufnahme Typische Folge: - AI Message als Source, - gegebenenfalls AI Hypothesis, - kein automatisch bestätigtes Pattern. ### Nutzer korrigiert etablierte Interpretation Typische Folge: - Correction als Source, - Re-Evaluation, - frühere Interpretation historisch erhalten, - Current Validity aktualisieren, - alte Aussage nicht mehr stillschweigend als aktuelle Wahrheit verwenden. --- ## Aktualisierter Stand der offenen Punkte nach Write-Policy-Klärung **Status: Arbeitsstand** Die frühere offene-Punkte-Liste und der aktualisierte Stand nach der Context-Builder-Klärung bleiben als historische Arbeitsstände erhalten. Nach der vorliegenden Write-Policy-Klärung gilt die generische Memory Write / Update Policy fachlich nicht mehr als grundsätzlich offen. Weiter offen beziehungsweise bewusst später zu klären sind insbesondere: 1. konkrete objektspezifische Promotion- und Evidence-Schwellen, 2. konkrete technische Signalstruktur des Hauptmodell-Calls, 3. technische Umsetzung von Checkpoint- und Deep-Enrichment-Verarbeitung, 4. konkrete Processing-Routing-Logik und Modellzuordnung, 5. technische Repräsentation von Current Validity, Revision und historischen States, 6. endgültige Liste langlebiger fachlicher Entitäten, 7. der Continuity Capability Contract, 8. spätere Integration mit dem finalen Usage-/Intent-Modell, 9. technische Data Architecture, Versionierung und Provenance, 10. detaillierte Learning-/Policy-Governance. Nicht mehr grundsätzlich offen sind: - ob Quellen einer Significance-Prüfung vor Speicherung unterliegen, - ob reversible operative States automatisch aktualisiert werden dürfen, - ob KI-Ableitungen automatisch etablierte persönliche Wahrheit werden, - ob explizite Nutzeraussagen immer künstlich einen Candidate-Umweg benötigen, - ob Nutzerkorrekturen die aktuelle Gültigkeit beeinflussen, - ob jede Objektart nach jedem Turn vollständig neu analysiert werden muss, - ob jede Enrichment-Entscheidung vor der sichtbaren Antwort abgeschlossen sein muss, - ob jede Verarbeitungsaufgabe einen eigenen starken LLM-Aufruf benötigt. --- ## Continuity Capability Contract **Status: fachliche Abschluss-Baseline für den implementierungsrelevanten Memory-/Continuity-Core** Der Continuity Capability Contract definiert nicht eine weitere interne Ontologie, sondern die beobachtbaren Fähigkeiten, an denen die langfristige Reflexionskontinuität von Kanshō gemessen wird. Kanshō erfüllt den fachlichen Anspruch eines langfristigen persönlichen Reflexionsbegleiters, wenn folgende Fähigkeiten zuverlässig realisierbar sind: 1. **Im aktuellen Reflexionsraum bleiben** Der normale Dialog orientiert sich primär an aktueller Session, Primary Reflection Space, aktiven Threads und offenen Fragen. Das globale Langzeitgedächtnis wird nicht permanent aktiviert. 2. **Sinnvoll fortsetzen** Ein früher begonnener Reflexionsfaden kann später wiederaufgenommen werden, ohne dass der Nutzer wesentliche bereits vorhandene Zusammenhänge erneut erklären muss. 3. **Relevant erinnern statt maximal erinnern** Frühere Inhalte werden nur dann aktiviert, wenn sie den aktuellen Reflexionsschritt tatsächlich verbessern. 4. **Aktuell und historisch unterscheiden** Frühere Sichtweisen, Gefühle, Bewertungen und Interpretationen werden nicht stillschweigend mit dem heutigen Zustand gleichgesetzt. 5. **Veränderung erkennbar machen** Relevante Entwicklungen zwischen früheren und aktuellen Perspektiven müssen nachvollziehbar darstellbar sein. 6. **Unsicherheit erhalten** AI Hypothesis, Observed Pattern, Candidate, explizite Nutzeraussage und bestätigte Erkenntnis bleiben unterscheidbar. 7. **Korrigierbar bleiben** Eine ausdrückliche Nutzerkorrektur verändert Current Validity. Frühere Zustände bleiben historisch nachvollziehbar, werden aber nicht weiter als aktuelle Wahrheit verwendet. 8. **Zur Quelle zurückkehren können** Wenn Genauigkeit, Widerspruch, historische Rekonstruktion oder Re-Grounding es erfordern, kann Kanshō auf die zugrunde liegenden Originalquellen zurückgreifen. 9. **Keine künstliche Memory-Produktion** Eine Session muss nicht automatisch Experiences, Insights, Threads, Patterns, Reflection Memories oder andere langlebige Objekte erzeugen. 10. **Kontinuität bleibt dienend** Memory, mindnet und Personal Model unterstützen den Reflexionsdialog und dürfen ihn nicht durch unnötiges Erinnern, Strukturieren oder Psychologisieren dominieren. 11. **Normale Nutzung bleibt effizient** Ein wesentlicher generativer Hauptmodell-Call pro Dialogturn bleibt der Normalfall. Tieferes Retrieval und Enrichment werden signal- beziehungsweise bedarfsgesteuert aktiviert. 12. **Providerunabhängige Kontinuität** Die langfristige Kontinuität darf nicht davon abhängen, dass ein bestimmter KI-Provider Conversation State dauerhaft hält. ### Referenz-Akzeptanzfall Wenn der Nutzer nach längerer Zeit sagt: > „Ich möchte noch einmal über meine Meditationserfahrungen nachdenken.“ soll Kanshō fachlich in der Lage sein: - den relevanten Reflection Space beziehungsweise Reflexionszusammenhang zu erkennen, - den aktuellen Stand und relevante offene Fäden zu berücksichtigen, - gezielt relevante frühere Experiences, Insights oder Quellen einzubeziehen, - irrelevante autobiografische Bereiche nicht automatisch zu aktivieren, - bei Bedarf eine frühere Aussage quellenorientiert zu rekonstruieren, - damalige und heutige Perspektive voneinander zu unterscheiden, - neue Erkenntnisse provenance-fähig und vorsichtig fortzuschreiben. ### Abschlussgrenze dieses Fachblocks Mit Context Builder, Memory Write / Update Policy und diesem Continuity Capability Contract ist der implementierungsrelevante fachliche Memory-/Continuity-Core ausreichend spezifiziert. Nicht vor einem ersten produktiven Slice verbindlich auszudetaillieren sind insbesondere: - mathematische Promotion Scores, - vollständige Relationsontologie, - adaptive Policy-Learning-Algorithmen, - umfassende longitudinale Pattern-Erkennung, - ausgereiftes Self Model, - vollständige mindnet-Promotion, - finale technische Storage- und Retrieval-Architektur. Diese Punkte bleiben Ziel- beziehungsweise Ausbauarchitektur und blockieren den Start einer inkrementellen Implementierung nicht.