---
title: "Kanshō – Datenarchitektur"
version: "0.1"
status: "Arbeitsstand"
date: "2026-08-19"
product_family: "Jinkendo"
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 |
| 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: dieselbe Dev-Postgres-Instanz, Datenbank `kansho_test` neben `kansho_dev` (keine dritte Instanz). Nicht `kansho` / `kansho_dev`, weil die Suite das Schema zurücksetzt.
- 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`