Kansho/docs/architecture/functional/memory_and_context_context.md

47 KiB
Raw Blame History

title status date product_family document_role parent_document
Kanshō Memory und Context Arbeitsstand 2026-08-18 Jinkendo Fachkapitel / Memory Architecture / Context 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.