Kansho/docs/architecture/technical/memory_storage_and_offline.md

title	version	status	date	product_family	document_role	parent_document
Kanshō – Memory-Speicher, Sync und Offline	0.1	Arbeitsstand	2026-08-19	Jinkendo	Technical Chapter / Memory Storage / Sync / Offline	technische_zielarchitektur.md

Kanshō – Memory-Speicher, Sync und Offline

Kanonisches Home für Gedächtnisschichten und Offline, sobald der Fachstand sie trägt. Die Schichtenbeschreibungen unten spiegeln den heutigen Fach-Arbeitsstand (memory_and_context.md) und sind nicht als finales Speichermodell zu implementieren. Offline-Ausprägung bleibt offen.

1. Schichten

Schicht	Lebensdauer (fachlich)	Technische Konsequenz
Working Context	Minuten bis Stunden	lokal, hohe Schreibfrequenz, an die aktive Session/Conversation gebunden
Thread Memory	Tage bis Monate+	persistiert, quellengebunden, darf nicht die Originalnachrichten ersetzen
Episodic / langfristig	Jahre	Handoff nach mindnet/Obsidian; Kanshō behält Provenance-Referenzen

Ein LLM-Kontextfenster ist kein Speicher. Context Builder wählt Ausschnitte; das Gateway minimiert sie erneut vor Egress.

2. Primärquelle und Re-Grounding

Status: fachliche Invariante (Re-Grounding / Originalquelle). Kein SQL-Schema, keine Drift-Formel in v0.1.

• Vollständige Dialoge bzw. eine verlässliche Originalrepräsentation bleiben erhalten.
• Summaries dürfen laufend fortgeschrieben werden, auch mitten im Dialog, nicht nur am Session-Ende.
• Drift-Erkennung und Re-Grounding arbeiten lokal auf Originalquellen. Für externe Inferenz wird danach ein neuer minimierter External Model Context erzeugt. Privacy Guardrails werden dabei nicht umgangen.

Keine unbegrenzte Kette Summary → Summary ohne Rückgriff auf die Quelle.

Konkrete Drift-Metrik, Granularität und Update-Algorithmen: offen.

3a. Strukturelle Vorsorge (Verträge, kein SQL)

Status: entschieden als Vorsorge. Felder, Enums und Tabellennamen bleiben offen. Festgezogen wird, welche Objektarten und Beziehungen das Langzeitdialog- und Erinnerungssystem tragen müssen. Herkunft: memory_and_context.md, dialogue_model.md, resurfacing_and_saturation.md, context_fidelity_and_regrounding.md, self_model_and_lived_experience.md, reflection_outputs.md, reflection_spaces.md.

Ein späteres Schema füllt diese Verträge. Es darf sie nicht kollabieren (z. B. Thread in der Session aufgehen lassen, Summary als Primärquelle, Handoff als Kanshō-Todo).

Objektarten

Art	Fachliche Rolle	Darf nicht
Conversation	Geordnete Originalrepräsentation (Layer 0). Stabile Message-IDs, Reihenfolge, Zeit.	Durch Summary ersetzt oder nur im LLM-Fenster existieren
Session	Eine Nutzungssitzung / Interaktionszyklus inkl. Checkpoint am Ende	Thread mitabschließen
Thread	Reflexionsfaden über Sitzungen hinweg; Zustand und Wiedervorlage am Faden, nicht an der Session	Geschlossene State-Machine vortäuschen; jeder Nebenfaden muss sichtbar sein
Thread-Kandidat	Intern markierter möglicher Faden	Automatisch eigener Chat oder bestätigtes Wissen
Working Context	Kurzlebiger Arbeitsstand der aktiven Conversation	Langzeitgedächtnis; Egress ohne Gateway
Thread Memory	Quellengebundene Verdichtung eines Fadens (Layer 1, versioniert)	Original ersetzen; still als Erkenntnis schreiben
Reflection Space	Lebendiger Kontext über Conversations/Threads	Bloßer Ordner; interne Feinstruktur 1:1 in der UX
Reflection Intent	Absicht dieser Interaktion, orthogonal zum Space	Mit Space identisch sein
Derived record	Summary, Hypothese, Emotionseinordnung, Pattern, Kandidat	Ohne Provenance, ohne Zeit, ohne „abgeleitet“-Kennzeichnung
Handoff	Journal / Reflection Memory / Knowledge Delta / Action Candidate	Kanshō-Aufgabenliste; mindnet-Graphkopie
External ref	Nullable Verweis mindnet / Obsidian	Besitz des Langzeitgraphen oder des Archivs
Re-grounding event	Wann, warum, aus welchen Quellen neu abgeleitet wurde	Nur Debug-Log ohne Quellenbindung
Identity mapping	Klasse A, lokal	In Summaries, Prompt-Archiv, mindnet-Handoff

Point-in-Time Self / Lived Experience ist keine eigene frühe Tabelle, sondern die Konsequenz: Original + zeitgebundene Ableitungen, die frühere Versionen nicht überschreiben.

Beziehungen, die das Modell skalieren

• profile_id an jeder personenbezogenen Struktur.
• Session 1:n Conversations (oder 1:1, später festlegbar) – ohne 1:1 mit Thread.
• Conversation n:m Threads (ein Gespräch, mehrere Fäden; ein Faden über mehrere Gespräche).
• Thread n:1 oder n:m Spaces (Zuordnung darf vorläufig/unsicher sein).
• Jede Ableitung: source_ids[] auf Messages/Conversations, as_of, confidence/uncertainty, kind.
• Sichtbarkeit getrennt von Existenz: intern vs. nutzersichtbar (Space-Regel: KI strukturiert, Nutzer verwaltet nicht die Feinstruktur).
• Handoffs referenzieren Kanshō-Quellen; sie sind nicht der Dialogspeicher.
• Message-IDs idempotent (späteres Offline, Sync-Hypothese).

Schichtenzuordnung

Layer	Hier
0	Conversation/Messages, Session, Thread-Identität und Anker (Wiedervorlage), Space-Identität, Mapping
1	Working-Context-Snapshot, aktuelle Thread-Memory-Version, Space-„aktueller Stand“, später Relevanz/Saturation als registrierte Leser
2a	Context Builder wählt Layer-1- und Quell-Ausschnitte; Gateway minimiert erneut
2b	Fortsetzungsvorschlag, Space-Ansicht, Aufklappen zur Quelle – keine zweite Verdichtungsformel

Kontinuitätsarbeit ist ein laufender Schreibpfad auf Layer 0/1, auslösbar mitten im Dialog und am Session-Checkpoint. Sie ist unabhängig vom sichtbaren Abschluss und unabhängig davon, ob ein Handoff entsteht.

Bewusst nicht schließen

• Thread-Zustandsliste (Open / Anchored / Dormant / Resolved sind Hinweise, kein Enum-Vertrag).
• Drift-Formel, Saturation-Score, Entry-IA (Contextual Continuation).
• Self-Model-Felder, Episodic-Schema in Kanshō (Handoff-Ziel mindnet/Obsidian).
• SQL, Sync-Engine, Offline-Store.

Erweiterbarkeit

Neue fachliche Arten (z. B. weiteres Derived-kind, weiterer Handoff-Typ, feinere Space-Sicht) kommen als registrierter Typ plus Provenance, nicht als Sonderpfad in der Conversation-Tabelle und nicht als Prompt-Text im Code. Retrieval in den Langzeitgraphen bleibt Adapter + External ref, kein zweites mindnet in Kanshō.

Session-Ende ist ein Checkpoint, kein Zwang zu Journal/Memory/Delta/Action. Technisch heißt das: Persistenzpfade für Original und interne Kontinuität existieren unabhängig von Handoff-Tabellen oder sichtbaren Abschluss-Screens.

4. Offline

Anforderung: entschieden. Ausprägung: offen.

Leitplanken, die jede spätere Lösung erfüllen muss:

• Dialoge müssen lokal zwischenspeicherbar sein (fachliche Anforderung).
• Konfliktbehandlung und Sync sind zu definieren, bevor Multi-Gerät produktiv personenbezogene Dialoge führt.
• KI-Funktionen dürfen online bleiben; Fail Closed gilt für unsichere Provider, nicht als Ausrede, lokale Eingaben zu verwerfen.
• App-Shell-Cache (PWA) ist nicht dasselbe wie Dialog-Offline.
• Verschlüsselung at rest auf dem Gerät: offen, siehe security.md.

Lokale kleine Modelle: fachlich offen, nicht als Voraussetzung des Rahmens.

5. Sync-Hypothese

Status: Hypothese

Ein Gerät schreibt in eine lokale Queue, das Backend ist Source of Truth nach erfolgreichem Sync. Idempotente Message-IDs verhindern Duplikate. Konflikte an Originalnachrichten sind selten (ein Nutzer, ein aktiver Dialog); Konflikte an Summaries werden durch Neuberechnung aus der Quelle gelöst, nicht durch Merge von Verdichtungen.

Diese Hypothese ist zu verwerfen oder zu bestätigen, sobald Geräte- und Offline-Szenarien in Phase G4 entschieden sind.

6. Entscheidungsstand

Thema	Stand	Status
Mehrere Memory-Schichten	heutiger Fachstand	nicht als Schema einfrieren
Original vor Summary / Re-Grounding	fachliche Invariante	bindend, sobald Memory gebaut wird
Objektarten und Lebenszyklus-Trennung	Verträge in §3a	entschieden als Vorsorge, kein SQL
mindnet nicht Working Memory	wahrscheinlich	bevorzugte Richtung
Offline-Fähigkeit	erforderlich	entschieden (fachlich), Ausprägung offen
Sync/Konflikte/lokale DB	–	offen
Drift-Berechnung	fachlich nötig	bevorzugte Richtung, Technik offen

6.1 Implementierungsstand (Rahmen-Schnitt)

Status: Code vorhanden, Heuristiken nicht.

Layer-0-Tabellen usage_sessions (nicht Auth-sessions), conversations, messages, Thread-/Space-Identität, derived_records (append-only, Kind-Registry), Handoff-/Ref-/Re-Grounding-/Mapping-Hüllen. Continuity-Checkpoint ohne LLM. Admin trennt Original und Derived. Die Dialogseite speichert nur Originaltext.

Nicht enthalten: Entry-IA, Fadenerkennung, Thread-Enum, Summaries über das Gateway.

7. Offene Fragen

1. IndexedDB vs. SQLite-WASM vs. nur Service-Worker-Queue?
2. Wird Audio nach Transkription gelöscht oder als Medium behalten? → voice_and_media.md
3. Wie greift Re-Grounding bei teilweise gesyncten Sessions?

8. Querverweise

• data_architecture.md, frontend_pwa_shell.md, privacy_gateway.md
• Fachlich: memory_and_context.md, resurfacing_and_saturation.md