Kansho/docs/architecture/technical/data_architecture.md

title	version	status	date	product_family	document_role	parent_document
Kanshō – Datenarchitektur	0.1	Arbeitsstand	2026-08-19	Jinkendo	Technical Chapter / Data Architecture	technische_zielarchitektur.md

Kanshō – Datenarchitektur

Kanonisches Home für Persistenzgrenzen ohne vorgezogenes SQL-Schema. Ableitungen, die UI und KI gemeinsam brauchen, folgen dem Data-Layer-Muster in platform_extensibility.md (Layer 0/1/2), sobald der Fachstand konkrete Funktionen hergibt.

1. Speicherverantwortung

Herkunft: ../functional/memory_and_context.md §11, bevorzugte Richtung, technisch zu validieren.

System	Besitz	Nicht besitzen
Kanshō / PostgreSQL	laufender Dialog, Session, Thread-Arbeitsstand, Working Context, lokale Kontinuitätsstrukturen	langfristiges Wissensnetz als Primärgraph
mindnet	langfristiges Wissen, Retrieval, Edges, Reflection Memories, Knowledge Deltas	exakte Dialogreihenfolge, Offline-Branching
Obsidian	menschenlesbares Archiv, Journal Entries	interne Thread-Zustände

Status: bevorzugte Richtung für die Verteilung; Validierung bleibt offen.

Kanshō erzeugt kein proprietäres geschlossenes Langzeitarchiv, das Obsidian ersetzen würde.

2. Aktueller Fach-Arbeitsstand (nicht final)

Die folgenden Punkte stehen heute in der Fachdoku. Sie sollen bei einer späteren Persistenz nicht stillschweigend verloren gehen. Sie sind kein Auftrag, jetzt Tabellen, Enums oder State Machines daraus zu bauen. Ändert die Fachkonzeption sie, gilt der neue Fachstand.

1. Originaldialog ist Primärquelle. Summaries, Thread Memories und Space-Zustände sind abgeleitet. Re-Grounding rekonstruiert aus Ursprungsquellen (context_fidelity_and_regrounding.md).
2. Session Lifecycle ≠ Thread Lifecycle. Das Ende einer Nutzungssitzung schließt Threads nicht automatisch (reflection_outputs.md). Tabellen und Statusfelder müssen beide Zyklen unabhängig abbilden können.
3. Lived Experience / Point-in-Time Self. Frühere Innenperspektiven werden nicht durch heutige Summaries überschrieben (self_model_and_lived_experience.md). Versionierung und Zeitbindung sind erforderlich, sobald Self-Model-Daten persistiert werden.
4. Hypothese ≠ bestätigte Erkenntnis. Self-Model-Änderungen nicht stillschweigend schreiben.
5. Action Candidates sind Handoffs nach Kairo, keine Kanshō-Aufgabenliste.
6. Resurfacing ≠ Speicherung. Langfristig gespeichert heißt nicht aktuell relevant (resurfacing_and_saturation.md).

3. Fachliche Entitäten (noch kein Schema)

Die folgende Liste spiegelt den heutigen Fachstand. Sie ist ein Merkzettel, keine Tabellendefinition und keine Zusage, dass all diese Objekte so bleiben. Welche Objektarten und Beziehungen ein späteres Schema erfüllen muss, steht als Vertrag in memory_storage_and_offline.md §3a.

Entität	Fachliches Home	Technische Erwartung v0.1
Profile / Session	dieses Kapitel + auth_identity_and_roles.md	Kanshō-DB, Rahmen
Conversation / Message	dialogue_model.md	Kanshō-DB, Originalrepräsentation
Thread (kein fertiges State Model)	dialogue_model.md, resurfacing_and_saturation.md	Kanshō-DB; Zustände nicht als geschlossene Enum vortäuschen
Reflection Space	reflection_spaces.md	Kanshō-DB, sichtbare vs. interne Struktur trennen
Working / Thread Memory	memory_and_context.md	Kanshō-DB, quellengebunden
Episodic / Journal / Memory / Knowledge Delta	reflection_outputs.md	Handoff-Ziele mindnet/Obsidian
Action Candidate	reflection_outputs.md	Handoff Kairo
Self Model Version	self_model_and_lived_experience.md	lokal, versioniert, Bestätigungspflicht
Writing Profile	writing_profile_and_journaling.md	lokal langfristig
Provenance / Confidence	context_fidelity_and_regrounding.md	an abgeleiteten Strukturen, nicht nur an Originalen
Privacy Mapping	guardrails.md	Klasse A, nur lokal

Kein Thread-State-Machine-Kapitel in v0.1. Die fachlich genannten Zustände (Open, Anchored / Resurface, Dormant, Resolved) sind nicht abschließend.

4. Was nicht in der Kanshō-DB landen soll

• Vollständiges mindnet-Graphmodell als Kopie.
• Kairo-Projekte, Tasks, Rituale als führendes System.
• Mitai-Vital- und Trainingsrohdaten als zweites Tracking.
• Identity-Mapping in Backup-Logs oder Prompt-Archiven.

5. Entscheidungsstand

Thema	Stand	Status
Kanshō besitzt den Dialogspeicher	ja	bevorzugte Richtung
mindnet besitzt langfristiges Gedächtnis	ja	bevorzugte Richtung
Obsidian menschenlesbares Archiv	ja	bevorzugte Richtung
Session ≠ Thread / Originaldialog / Handoffs	aktueller Fach-Arbeitsstand	nicht einfrieren
SQL-Schema / IDs / Edges	nein	offen
Thread-Zustandsmenge	nicht schließen	offen
Gemeinsame IDs mit mindnet/Obsidian	nötig, Form unbekannt	offen

6. Offene Fragen

Entsprechen den Interview-Leitfragen Phase F1/F4 und werden hier nicht vorab beantwortet: kanonische IDs, Backlinks, welche Strukturen nur in Obsidian existieren, Schema für Reflection Memory und Knowledge Delta.

6a. Persistenzgrenzen Server vs. lokal (2026-09-07)

Additiv, ohne das Fachschema vorzuziehen:

• Windows-Checkout: SQLite unter backend/data/ (gitignoriert) für die lokale App ohne Docker.
• Test-Suite und Gitea: pytest auf derselben Dev-Postgres-Instanz, Datenbank kansho_test neben kansho_dev (keine dritte Instanz). Nicht kansho / kansho_dev, weil die Suite das Schema zurücksetzt. Live-Smoke trifft nur /api/health der laufenden Dev-App.
• Docker auf dem Pi: PostgreSQL 16, eigene Instanz je Umgebung, Medien im Compose-Volume kansho-media / dev-kansho-media.
• Identity-Mappings bleiben Klasse A in der Local Trusted Zone (jetzt: Pi-Postgres, nicht Provider).
• Kein Shared-Schema mit Mitai.

7. Querverweise

• memory_storage_and_offline.md, integrations_technical.md, privacy_gateway.md, platform_extensibility.md
• Fachlich: memory_and_context.md, reflection_outputs.md, self_model_and_lived_experience.md