document_role: "Technical Chapter / Data Architecture"
parent_document: "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 |
**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 |
| 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 |
| 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.
- Windows-Checkout: SQLite unter `backend/data/` (gitignoriert) für die lokale App ohne Docker.
- Test-Suite und Gitea: dieselbe Dev-Postgres-Instanz, Datenbank `kansho_test` neben `kansho_dev` (keine dritte Instanz). Nicht `kansho` / `kansho_dev`, weil die Suite das Schema zurücksetzt.
