Dateien nach "docs/architecture/functional" hochladen

docs/architecture/functional/reflection_outputs.md

@@ -0,0 +1,99 @@
+---
+    title: "Kanshō – Reflection Outputs"
+    status: "Arbeitsstand"
+    date: "2026-08-18"
+    product_family: "Jinkendo"
+    document_role: "Fachkapitel / Reflection Outputs / Handoffs"
+    parent_document: "fachliche_zielarchitektur.md"
+    ---
+
+    # Kanshō – Reflection Outputs
+
+Dieses Dokument ist das kanonische Home für fachliche Ergebnisse eines Reflexionsdialogs.
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 17 Ergebnisse eines Reflexionsdialogs – Einleitung. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+## 17. Ergebnisse eines Reflexionsdialogs
+
+Ein Dialog kann mehrere unterschiedliche Ergebnisse erzeugen.
+
+Diese Ergebnisse müssen voneinander getrennt behandelt werden.
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 17.1 Journal Entry. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 17.1 Journal Entry
+
+Ein menschenlesbarer autobiografischer Text.
+
+Zielsystem:
+
+- primär Obsidian,
+- damit indirekt mindnet.
+
+---
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 17.2 Reflection Memory. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 17.2 Reflection Memory
+
+Eine verdichtete, aber nachvollziehbare Erkenntnis aus einer Reflexion.
+
+Beispiele:
+
+- persönliche Einsicht,
+- wiederkehrendes Thema,
+- bestätigte Beobachtung.
+
+Zielsystem:
+
+- mindnet.
+
+---
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 17.3 Knowledge Delta. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 17.3 Knowledge Delta
+
+Eine neue oder geänderte Beziehung im persönlichen Wissensnetz.
+
+Beispiele:
+
+- neue Verbindung zwischen Erlebnis und Wert,
+- neue Referenz,
+- korrigierte frühere Annahme,
+- neue Hypothese.
+
+Zielsystem:
+
+- mindnet.
+
+---
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 17.4 Action Candidate. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 17.4 Action Candidate
+
+Aus einer Reflexion kann eine konkrete Handlungsabsicht entstehen.
+
+Beispiele:
+
+- neues Ziel,
+- Ritual,
+- Experiment,
+- Aufgabe,
+- persönlicher Entwicklungsschritt.
+
+Zielsystem:
+
+- Kairo.
+
+Kanshō soll diese Handlungsabsicht erkennen und zur Übernahme anbieten.
+
+Kanshō selbst wird dadurch nicht zum Aufgaben- oder Projektmanager.
+
+---
+
+
+## Noch auszuarbeiten
+
+Beim Abschluss der laufenden Ausarbeitung der Nutzungssituation Tagesreflexion werden hier Session Output, Narrative Output, Long-Term Output sowie die Trennung `Session Lifecycle ≠ Thread Lifecycle` ergänzt.

docs/architecture/functional/reflection_spaces.md

@@ -0,0 +1,224 @@
+---
+    title: "Kanshō – Reflection Spaces"
+    status: "Arbeitsstand"
+    date: "2026-08-18"
+    product_family: "Jinkendo"
+    document_role: "Fachkapitel / Reflection Contexts / Spaces"
+    parent_document: "fachliche_zielarchitektur.md"
+    ---
+
+    # Kanshō – Reflection Spaces
+
+Dieses Dokument ist das kanonische Home für Reflexionskontexte, Reflection Spaces, deren sichtbare und interne Struktur sowie die fachliche Autonomie bei ihrer Organisation.
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 7 Reflexionskontexte. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+## 7. Reflexionskontexte
+
+Reflexionen finden in unterschiedlichen Lebensbereichen und Situationen statt.
+
+Bereits benannte Beispiele sind:
+
+- Urlaub,
+- persönliche Entwicklung,
+- Beruf,
+- allgemeines Befinden,
+- Vergangenheitsbewältigung,
+- Ziele,
+- Visionen,
+- Inspiration,
+- Kreativität.
+
+Diese Liste ist ausdrücklich nicht abschließend.
+
+Eine noch offene konzeptionelle Frage ist, ob solche Kontexte:
+
+1. als feste Kategorien definiert werden,
+2. vollständig dynamisch entstehen,
+3. oder über ein hybrides Modell organisiert werden.
+
+Als derzeit bevorzugte Richtung gilt ein **hybrides Modell**:
+
+- wenige übergeordnete Lebensräume,
+- darunter dynamisch entstehende konkrete Reflexionsräume.
+
+Beispiele:
+
+- `Urlaub → Lošinj 2026`
+- `Beruf → Institute`
+- `Persönliche Entwicklung → Umgang mit Verlust`
+- `Kreativität → neue Produktidee`
+- `Familie → gemeinsames Erleben`
+- `Zukunft → persönliche Vision`
+
+Diese Reflexionsräume sollen mit Objekten aus Kairo und Knoten aus mindnet verknüpft werden können.
+
+---
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 8.4 Fachliche Autonomie der KI bei Strukturierung. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 8.4 Fachliche Autonomie der KI bei Strukturierung
+
+Kanshō soll die interne Strukturierung von Reflexionen möglichst weitgehend im Hintergrund übernehmen.
+
+Dabei gilt als fachliches Prinzip:
+
+> **Die KI erkennt, schlägt vor, strukturiert und konsolidiert – der Nutzer soll aber nicht zum Verwalter der internen Struktur werden.**
+
+Der Umfang dieser Eigenständigkeit soll konfigurierbar sein.
+
+Mögliche Ausprägungen reichen von:
+
+- stark bestätigungsorientiert: Kanshō schlägt neue Räume, Threads oder Zusammenführungen vor und wartet auf Bestätigung,
+- ausgewogen: offensichtliche Strukturierungen erfolgen automatisch, bedeutsame Änderungen werden vorgeschlagen,
+- weitgehend autonom: Kanshō darf neue Räume oder Threads selbst anlegen und später konsolidieren, solange dies transparent und korrigierbar bleibt.
+
+Diese Einstellung ist eine fachliche Produktanforderung. Die genaue technische Umsetzung ist noch offen.
+
+Wichtig ist dabei insbesondere:
+
+- Nicht jedes Seitenthema erzeugt automatisch einen neuen sichtbaren Thread.
+- Nicht jede semantische Abweichung benötigt einen neuen Reflection Space.
+- Kanshō soll Relevanz, Wiederkehr, Tiefe und Dauer eines Themas berücksichtigen.
+- Mehrere schwach ausgeprägte oder verwandte Strukturen dürfen später konsolidiert werden.
+- Der Nutzer muss eine falsche Zuordnung, Trennung oder Zusammenführung korrigieren können.
+
+Damit soll verhindert werden, dass Kanshō über Jahre eine unüberschaubare Menge kleinteiliger Reflexionsräume und Threads erzeugt.
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 8.6 Sichtbare und interne Struktur. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 8.6 Sichtbare und interne Struktur
+
+Kanshō darf intern wesentlich mehr Struktur kennen und verwalten, als dem normalen Nutzer in der Oberfläche angezeigt wird.
+
+Für die reguläre Nutzung gilt:
+
+- nur relevante Reflection Spaces werden sichtbar hervorgehoben,
+- offene oder bewusst markierte Themen können sichtbar angeboten werden,
+- frühere Dialoge und Tagebucheinträge bleiben zugänglich,
+- kleinere Threads, vorläufig erkannte Themen und interne semantische Beziehungen müssen nicht unmittelbar sichtbar sein.
+
+Damit soll verhindert werden, dass die Anwendung zu einem Struktur- oder Wissensverwaltungswerkzeug wird.
+
+#### Admin-/Developer View
+
+Für Entwicklung, Test, Qualitätssicherung und spätere Administration soll es jedoch eine besondere Diagnose- und Transparenzansicht geben.
+
+Diese Ansicht kann – abhängig vom späteren Berechtigungsmodell – insbesondere sichtbar machen:
+
+- erkannte interne Threads,
+- Zuordnung von Dialogen zu Reflection Spaces,
+- vorläufige Space- oder Thread-Kandidaten,
+- Herkunft und Provenance verwendeter Memories,
+- Confidence beziehungsweise Unsicherheit interner Zuordnungen,
+- erkannte Zusammenhänge und Hypothesen,
+- Gründe für Vorschläge zur Trennung oder Konsolidierung,
+- Konsolidierungskandidaten,
+- Context-Builder-Auswahl für einen Dialog,
+- verwendete relevante Erinnerungen und Wissensknoten,
+- vorgeschlagene beziehungsweise durchgeführte Strukturänderungen.
+
+Diese Ansicht ist **nicht Teil der normalen Nutzeroberfläche**.
+
+Sie soll später nur Rollen mit entsprechender Berechtigung zugänglich sein, beispielsweise:
+
+- Hauptadmin,
+- Systemadministrator,
+- Entwickler/Testrolle.
+
+Die konkrete Rollenbezeichnung und technische Berechtigungsumsetzung werden später festgelegt.
+
+Wesentliche Anforderung:
+
+> Interne KI-Strukturen müssen für Entwicklung und Qualitätssicherung nachvollziehbar und inspizierbar sein, ohne die reguläre Nutzung mit dieser Komplexität zu belasten.
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 8.7 Reflection Space als lebendiger Denk- und Erfahrungsraum. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 8.7 Reflection Space als lebendiger Denk- und Erfahrungsraum
+
+Ein Reflection Space ist fachlich **kein bloßer Ablageort für Dialoge oder Tagebucheinträge**.
+
+Er bildet vielmehr eine laufend aktualisierte Sicht auf einen zusammenhängenden persönlichen Denk- und Erfahrungsraum.
+
+Ein Reflection Space kann dabei mehrere Elemente verbinden:
+
+- frühere und aktuelle Dialoge,
+- relevante Threads,
+- Tagebucheinträge,
+- offene Fragen,
+- bereits entstandene Erkenntnisse,
+- zeitliche Entwicklung,
+- Verbindungen zu anderen Reflection Spaces,
+- relevante Informationen aus mindnet,
+- bei Bedarf relevante Kontexte aus anderen Jinkendo-Anwendungen.
+
+Der Reflection Space soll dem Nutzer vor allem fünf Dinge ermöglichen:
+
+1. **Orientierung** – Worum geht es in diesem Raum aktuell?
+2. **Fortsetzung** – Wo kann die Reflexion sinnvoll weitergehen?
+3. **Offene Fragen** – Welche Themen oder Fragen sind noch nicht abgeschlossen?
+4. **Historie** – Welche Dialoge, Erlebnisse und Einträge haben den Raum geprägt?
+5. **Entwicklung** – Was hat sich über die Zeit in Wahrnehmung, Haltung oder Erkenntnis verändert?
+
+#### Aktueller Zustand eines Reflection Space
+
+Jeder Reflection Space besitzt aus Nutzersicht einen aktuellen fachlichen Zustand.
+
+Dieser Zustand beschreibt nicht die vollständige Historie, sondern den derzeit relevanten Stand des Denk- und Erfahrungsraums.
+
+Wichtig:
+
+- Der aktuelle Zustand muss auf zugrunde liegende Reflexionen, Erinnerungen oder andere Quellen zurückführbar sein.
+- Er darf kein frei erfundenes KI-Summary sein.
+- Veränderungen des Zustands müssen nachvollziehbar aus neuen Dialogen, Erkenntnissen oder bestätigten Informationen hervorgehen.
+- Die vollständige Historie bleibt weiterhin zugänglich.
+- Interne technische Strukturen können deutlich umfangreicher sein als die sichtbare Zusammenfassung.
+
+Damit wird der Reflection Space zu einer **lebendigen, kontextuellen Sicht auf persönliche Entwicklung innerhalb eines bestimmten Zusammenhangs**.
+
+
+#### Dauer und Granularität
+
+Reflection Spaces können unterschiedlich lange relevant sein.
+
+Sie können beispielsweise:
+
+- ein klar abgegrenztes Erlebnis oder einen Urlaub über Tage oder Wochen begleiten,
+- ein über mehrere Wochen laufendes persönliches Thema bündeln,
+- eine längerfristige berufliche oder persönliche Entwicklung abbilden,
+- über Jahre hinweg wiederkehrende Fragen oder Lebenszusammenhänge begleiten.
+
+Die Dauer allein entscheidet nicht darüber, ob ein eigener Reflection Space sinnvoll ist. Maßgeblich ist, ob ein Zusammenhang für die Reflexion über mehrere Interaktionen hinweg eigenständige Bedeutung besitzt.
+
+Ältere oder aktuell nicht relevante Spaces dürfen in der normalen Oberfläche zurücktreten, bleiben aber auffindbar und können bei erneuter Relevanz wieder in den Vordergrund treten.
+
+Kanshō soll diese Komplexität weitgehend selbst organisieren. Der Nutzer soll nicht entscheiden müssen, ob ein Thema „groß genug“ für einen Space ist.
+
+#### Vorläufige sichtbare Standardansicht
+
+Für die normale Nutzeroberfläche gilt als **vorläufige fachliche Baseline**, die in späteren Dialogkapiteln weiter konkretisiert werden kann:
+
+1. **Aktueller Stand** – eine kompakte, quellengebundene Sicht darauf, worum es in diesem Space aktuell geht und wo der Nutzer gedanklich steht.
+2. **Was ist noch offen?** – nur die aktuell relevanten offenen Fragen, Spannungsfelder oder bewusst weiterzuverfolgenden Themen.
+3. **Weiterdenken** – ein intelligent priorisierter Vorschlag zur Fortsetzung mit wenigen Alternativen.
+4. **Bisheriger Weg** – eine kompakte zeitliche Sicht auf prägende Erlebnisse, Dialoge, Tagebucheinträge und Wendepunkte.
+
+Diese Darstellung ist bewusst nicht abschließend. Sie bildet den derzeit akzeptierten Ausgangspunkt und darf später auf Basis der konkreten Nutzungsszenarien erweitert oder verändert werden.
+
+#### Aufklappbarkeit und Nutzer-Provenance
+
+Verdichtete Aussagen in der sichtbaren Space-Ansicht sollen für den Nutzer grundsätzlich auf die zugrunde liegenden Inhalte zurückführbar sein.
+
+Der Nutzer soll bei Bedarf nachvollziehen können:
+
+- auf welchen früheren Dialogen,
+- Tagebucheinträgen,
+- Memories,
+- Obsidian-Inhalten,
+- mindnet-Knoten oder
+- bestätigten Erkenntnissen
+
+eine relevante Aussage oder Zusammenfassung basiert.
+
+Dieses **Aufklappen** ist eine Transparenzfunktion für den Nutzer und ist fachlich von dem internen Re-Grounding der KI zu unterscheiden.
+

docs/architecture/functional/resurfacing_and_saturation.md

@@ -0,0 +1,175 @@
+---
+    title: "Kanshō – Thread Resurfacing und Reflection Saturation"
+    status: "Arbeitsstand"
+    date: "2026-08-18"
+    product_family: "Jinkendo"
+    document_role: "Querschnittliches Fachkapitel / Resurfacing / Saturation"
+    parent_document: "fachliche_zielarchitektur.md"
+    ---
+
+    # Kanshō – Thread Resurfacing und Reflection Saturation
+
+Dieses Dokument ist das kanonische Home für das Wiederauftauchen offener Themen, Wiedervorlagen, Relevanz und die erkannte Abschlussreife von Reflexionssitzungen.
+
+<!-- Migriert aus `fachliche_zielarchitektur.md`: ehemaliger Abschnitt 2.11 Konsistenzregel für Resurfacing und Saturation. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 2.11 Konsistenzregel für Resurfacing und Saturation
+
+Aus dem Nutzungsszenario „Tagesreflexion“ wurden zwei querschnittliche Konzepte abgeleitet, die für die gesamte fachliche und spätere technische Architektur verbindlich berücksichtigt werden müssen.
+
+#### Thread Resurfacing
+
+Beschreibt, **wann ein früherer oder offener Thread wieder aktiv relevant wird**.
+
+Relevanz kann insbesondere entstehen durch:
+
+- explizite Nutzeranfrage,
+- gesetzte Wiedervorlage,
+- zeitlichen oder örtlichen Kontext,
+- neues Ereignis im gleichen Kontext,
+- semantische Reaktivierung,
+- aktuellen Bezug zu einem Reflection Space.
+
+Grundprinzip:
+
+> **Langfristig gespeichert bedeutet nicht automatisch aktuell relevant.**
+
+Memory und Current Relevance sind getrennte Konzepte.
+
+#### Reflection Saturation
+
+Beschreibt, **wann eine Reflexion für die aktuelle Sitzung wahrscheinlich ausreichend tief beziehungsweise weit bearbeitet ist**.
+
+Mögliche fachliche Signale sind:
+
+- Reflection Intent,
+- Nutzerwunsch,
+- individuelle typische Dialogtiefe,
+- Abdeckung aktiver Themen,
+- sinkender zusätzlicher Erkenntnisgewinn,
+- offene Randthemen,
+- Gesprächssignale.
+
+Grundprinzip:
+
+> **Kanshō darf Abschlussreife erkennen und anbieten, aber der Nutzer entscheidet über Weiterführen, Vertiefung, Wiedervorlage oder Abschluss.**
+
+#### Architekturweite Konsistenz
+
+Diese beiden Konzepte müssen in späteren Kapiteln konsistent berücksichtigt werden, insbesondere in:
+
+- `dialogue_model.md`
+- `threads_and_branching.md`
+- `thread_memory.md`
+- `episodic_memory.md`
+- `context_builder.md`
+- `context_drift_and_regrounding.md`
+- `reflection_space_model.md`
+- `agent_roles.md`
+- `retrieval_strategy.md`
+- `memory_write_policy.md`
+- `conversation_ui.md`
+- `notifications_and_background_behaviour.md`
+- `kairo_integration.md`
+- `admin_developer_view.md`
+
+Keines dieser Kapitel soll eine eigene Logik einführen, die dem Grundmodell von Resurfacing oder Saturation widerspricht.
+
+#### Konsistenzprüfung
+
+Bei der späteren Ausarbeitung der genannten Kapitel ist jeweils explizit zu prüfen:
+
+1. Wie wirkt die jeweilige Architekturentscheidung auf Thread Resurfacing?
+2. Wie wirkt sie auf Reflection Saturation?
+3. Bleibt die Trennung zwischen Memory und aktueller Relevanz erhalten?
+4. Bleibt die explizite Nutzerintention höher priorisiert als automatische KI-Vorschläge?
+5. Bleibt der Nutzer Herr über Vertiefung, Wiedervorlage und Abschluss?
+6. Ist die Entscheidung mit Re-Grounding, Provenance und Reflection Spaces konsistent?
+
+Diese Fragen werden Teil des architecture-wide Capability- und Drift-Checks.
+
+<!-- Migriert aus `usage_situations.md`: ehemaliger Abschnitt 7.2 Thread Resurfacing und Reflection Saturation. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 7.2 Thread Resurfacing und Reflection Saturation
+
+Aus der Ausarbeitung der Tagesreflexion ergeben sich zwei querschnittliche fachliche Konzepte, die nicht nur für diese Nutzungssituation gelten.
+
+#### Thread Resurfacing
+
+Thread Resurfacing beantwortet die Frage:
+
+> **Wann soll ein früheres oder offenes Thema wieder aktiv relevant werden?**
+
+Mögliche Trigger sind insbesondere:
+
+1. **Explizite Nutzeranfrage**  
+   Beispiele: „Was ist noch offen?“ oder „Wo stehen wir bei Thema X?“
+
+2. **Zeitlicher oder örtlicher Kontext**  
+   Beispiel: Urlaubsthemen sind während des Urlaubs besonders relevant und können noch in einer definierten Rückschauphase danach aktiv angeboten werden.
+
+3. **Situations- oder kontextgebundene Reaktivierung**  
+   Beispiel: Ein neues Erlebnis beim Sport, in der Familie oder bei einer Meditation steht in erkennbarem Zusammenhang mit einem früheren Thread.
+
+4. **Explizit gesetzter Anker im Dialog**  
+   Beispiel: „Lass uns morgen daran weiterarbeiten.“
+
+5. **Semantische Reaktivierung**  
+   Ein aktuelles Erlebnis steht in starker inhaltlicher Beziehung zu einem früheren Thema, auch wenn der Nutzer es nicht ausdrücklich nennt.
+
+Wichtig ist die Trennung zwischen:
+
+- **Memory:** Ein Thema bleibt langfristig erhalten.
+- **Current Relevance:** Ein Thema ist aktuell geeignet, wieder aktiv angeboten zu werden.
+
+Ein Thema darf historisch vollständig verfügbar bleiben, ohne regelmäßig ungefragt in den Vordergrund zu treten.
+
+#### Reflection Saturation
+
+Reflection Saturation beantwortet die Frage:
+
+> **Ist für die aktuelle Reflexionssitzung wahrscheinlich ausreichend gesagt beziehungsweise verstanden worden?**
+
+Dabei können fachlich unter anderem berücksichtigt werden:
+
+- aktueller Reflection Intent,
+- expliziter Nutzerwunsch,
+- typische persönliche Dialogtiefe,
+- Umfang und Tiefe vergleichbarer früherer Reflexionen,
+- Abdeckung aktuell relevanter Themen,
+- offene Randthemen,
+- sinkender zusätzlicher Erkenntnisgewinn,
+- erkennbare Gesprächssignale.
+
+Reflection Saturation ist **kein automatischer Gesprächsabbruch**.
+
+Kanshō darf erkennen, dass eine Reflexion für den Moment ausreichend rund wirkt, soll den Abschluss aber als Möglichkeit anbieten.
+
+Die letzte Entscheidung über Weiterführen, Vertiefen, Wiedervorlage oder Abschluss liegt beim Nutzer.
+
+#### Fachliche Thread-Zustände
+
+Für die weitere Architektur sind mindestens folgende fachlichen Zustände beziehungsweise Bedeutungen relevant:
+
+- **Active** – wird aktuell bearbeitet,
+- **Open** – noch nicht ausgeschöpft,
+- **Anchored / Resurface** – ausdrücklich für eine spätere Wiederaufnahme markiert,
+- **Dormant** – nicht abgeschlossen, aber aktuell nicht relevant,
+- **Resolved** – für den derzeitigen Erkenntnisstand ausreichend bearbeitet.
+
+Diese Begriffe sind noch **kein festes technisches State Model**. Sie dienen zunächst dazu, spätere Architekturentscheidungen konsistent auszurichten.
+
+#### Architekturweite Gültigkeit
+
+Thread Resurfacing und Reflection Saturation sind querschnittliche Konzepte.
+
+Spätere Kapitel zu Dialogmodell, Memory, Context Builder, AI-Architektur, Reflection Spaces, UX, Notifications, Kairo-Integration und Admin-/Developer View müssen mit diesen Konzepten konsistent bleiben.
+
+Die konkrete Berechnung von Relevanz, Saturation, Scores oder Zustandsübergängen wird erst in den jeweiligen technischen Architekturkapiteln festgelegt.
+
+---
+
+
+## Nutzungsspezifische Regeln
+
+Konkrete Regeln der Tagesreflexion – beispielsweise explizite Wiedervorlage, Fokuswahl und Priorisierung des heutigen Kontexts – verbleiben in `usage_situations.md` und müssen mit diesem Querschnittsmodell konsistent sein.

docs/architecture/functional/self_model_and_lived_experience.md

@@ -0,0 +1,247 @@
+---
+    title: "Kanshō – Self Model und Lived Experience"
+    status: "Arbeitsstand"
+    date: "2026-08-18"
+    product_family: "Jinkendo"
+    document_role: "Fachkapitel / Self Model / Point-in-Time Self / Digital Twin"
+    parent_document: "fachliche_zielarchitektur.md"
+    ---
+
+    # Kanshō – Self Model und Lived Experience
+
+Dieses Dokument ist das kanonische Home für Self Model, bestätigte Identitätsaussagen, zeitgebundene Innenperspektive, Point-in-Time Self und den Lived-Experience-Layer des digitalen Zwillings.
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 10.4 Self Model. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 10.4 Self Model
+
+Das Self Model beschreibt nicht die spontane Interpretation der KI, sondern ein nachvollziehbares persönliches Selbstmodell.
+
+Mögliche Bestandteile:
+
+- Werte,
+- Leitbild,
+- Prinzipien,
+- Rollen,
+- langfristige Ziele,
+- bestätigte persönliche Muster,
+- Selbstbeschreibungen,
+- wiederkehrende Spannungsfelder.
+
+Das Self Model soll:
+
+- versioniert sein,
+- Herkunft und Zeitbezug einer Aussage kennen,
+- Beobachtungen von Interpretationen unterscheiden,
+- nicht stillschweigend von der KI verändert werden.
+
+---
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 14 Self Model und Wesenskern. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+## 14. Self Model und „Wesenskern“
+
+Ein zentrales Ziel ist, dass langfristig tiefere Verbindungen zur Persönlichkeit und zum eigenen Wesenskern erkennbar werden.
+
+Dabei gilt jedoch eine wichtige Grenze:
+
+**Die KI soll keinen Wesenskern erfinden.**
+
+Das System soll vielmehr ein nachvollziehbares und versioniertes Selbstmodell aus belastbaren Quellen bilden.
+
+Informationsquellen können sein:
+
+- explizit formulierte Werte,
+- Leitbild,
+- Selbstbeschreibungen,
+- bestätigte Erkenntnisse,
+- frühere Reflexionen,
+- dokumentierte Entscheidungen,
+- längerfristig wiederkehrende Muster.
+
+Wird ein potenziell neues grundlegendes Muster erkannt, soll die KI es zunächst als Hypothese behandeln.
+
+Beispiel:
+
+> „In mehreren Reflexionen scheint Selbstbestimmung eine wichtige Rolle zu spielen. Das ist bisher nicht ausdrücklich Teil deines Wertemodells. Möchtest du das genauer betrachten?“
+
+Eine solche Aussage wird erst nach bewusster Bestätigung Bestandteil eines stabilen Self Models.
+
+---
+
+<!-- Migriert aus `produktvision_und_produktidentitaet.md`: Abschnitt 17.1 Zeitgebundene Innenperspektive und digitaler Zwilling. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 17.1 Zeitgebundene Innenperspektive und digitaler Zwilling
+
+Durch die Persistenz der vollständigen Kanshō-Unterhaltungen entsteht eine zusätzliche Ebene des persönlichen digitalen Zwillings.
+
+mindnet bildet bisher vor allem langfristig nutzbares persönliches Wissen und Zusammenhänge ab, beispielsweise:
+
+- Erfahrungen,
+- Erlebnisse,
+- Entscheidungen,
+- Erkenntnisse,
+- Werte,
+- Leitbild,
+- Beziehungen zwischen Wissenselementen.
+
+Kanshō ergänzt diese Ebene um die **zeitgebundene Innenperspektive** des Nutzers.
+
+Dabei werden nicht nur Ergebnisse einer Reflexion gespeichert, sondern – soweit vom Nutzer vorgesehen – auch die zugrunde liegenden Dialoge, in denen sichtbar wird:
+
+- wie der Nutzer zu einem bestimmten Zeitpunkt gedacht hat,
+- welche Gefühle er beschrieben hat,
+- welche Zweifel oder Ambivalenzen bestanden,
+- welche Alternativen erwogen wurden,
+- wie sich eine Haltung im Gespräch entwickelt hat,
+- welche Fragen noch offen waren,
+- welche Aussagen nur Hypothesen oder Momentaufnahmen waren,
+- welche Sprache und Denkstruktur zu diesem Zeitpunkt verwendet wurde.
+
+Diese Ebene wird vorläufig als **Lived Experience / Inner-State Layer** bezeichnet.
+
+#### Keine Behauptung eines objektiven inneren Zustands
+
+Kanshō kann nicht unmittelbar wissen, was ein Mensch „wirklich“ denkt oder fühlt.
+
+Gespeichert wird deshalb fachlich die:
+
+> **zu einem bestimmten Zeitpunkt geäußerte, beobachtbare und kontextgebundene Innenperspektive des Nutzers.**
+
+Eine Aussage wie „Ich war damals zufrieden“ ist damit zunächst eine zeitgebundene Selbstäußerung und keine objektive psychologische Diagnose.
+
+Diese Unterscheidung ist für die langfristige Integrität des digitalen Zwillings wesentlich.
+
+#### Point-in-Time Self
+
+Die Kombination aus vollständigen Dialogquellen, zeitlichen Zuständen und langfristigem Wissen eröffnet perspektivisch eine neue Fähigkeit:
+
+> **Wie habe ich zu einem bestimmten Zeitpunkt gedacht, gefühlt, bewertet und argumentiert?**
+
+Ein späterer Zustand soll einen früheren nicht überschreiben.
+
+Beispiele:
+
+- „Damals glaubte ich X, heute sehe ich es anders.“
+- „Vor zwei Jahren war diese Entscheidung für mich mit anderen Gefühlen verbunden.“
+- „Dieses Thema wurde damals als Hypothese betrachtet und erst später zu einer bestätigten Erkenntnis.“
+
+Damit bildet Kanshō nicht nur ein aktuelles persönliches Modell, sondern eine **zeitliche Entwicklung des Selbstmodells und der erlebten Innenperspektive**.
+
+#### Beziehung zu mindnet
+
+Kanshō und mindnet besitzen dabei unterschiedliche, komplementäre Rollen:
+
+**Kanshō**
+- bewahrt dialogische Originalquellen,
+- erfasst zeitgebundene Gedanken und ausgedrückte Gefühle,
+- erhält Ambivalenzen, Zweifel und Denkwege,
+- ermöglicht Point-in-Time-Rekonstruktion.
+
+**mindnet**
+- integriert langfristig relevante Erkenntnisse,
+- vernetzt Erfahrungen, Entscheidungen, Werte und Wissenselemente,
+- unterstützt semantisches Retrieval und übergreifende Zusammenhänge.
+
+Kanshō soll damit nicht mindnet ersetzen, sondern mindnet um eine reichere autobiografische Quellen- und Erlebnisebene ergänzen.
+
+#### Originalquelle vor Interpretation
+
+Die vollständige Unterhaltung ist für diese Funktion besonders wertvoll, weil sie späteres Re-Grounding ermöglicht.
+
+Daraus folgt ein wichtiges Prinzip:
+
+> **Rohdialoge beziehungsweise deren verlässliche Originalrepräsentation sind Primärquellen. Summaries, Memories, Emotionseinordnungen, Muster und Self-Model-Aussagen sind abgeleitete Schichten.**
+
+Abgeleitete Interpretationen dürfen die Originalquelle nicht ersetzen.
+
+#### Widerspruch und Veränderung sind Information
+
+Der digitale Zwilling darf Widersprüche nicht automatisch „glattziehen“.
+
+Wenn ein Nutzer zu unterschiedlichen Zeitpunkten verschiedene Sichtweisen äußert, kann gerade diese Veränderung fachlich bedeutsam sein.
+
+Deshalb sollen:
+
+- frühere Zustände erhalten bleiben,
+- zeitliche Gültigkeit berücksichtigt werden,
+- Korrekturen und Neubewertungen nachvollziehbar sein,
+- konkurrierende Perspektiven koexistieren können.
+
+#### Langfristige Perspektive
+
+Diese Architektur ermöglicht perspektivisch Fragen wie:
+
+- „Wie habe ich diese Lebensphase damals erlebt?“
+- „Welche Sorgen hatte ich vor dieser Entscheidung?“
+- „Wie hat sich meine Haltung zu Leistung verändert?“
+- „Was habe ich damals über meine Rolle als Vater gedacht?“
+- „Wann begann sich meine Sicht auf dieses Thema zu verändern?“
+
+Damit wird Kanshō zu einer wesentlichen Daten- und Reflexionsquelle für einen langfristig wachsenden persönlichen digitalen Zwilling.
+
+<!-- Migriert aus `fachliche_zielarchitektur.md`: ehemaliger Abschnitt 2.12 Zeitgebundene Innenperspektive und Digital-Twin-Layer. Inhalt fachlich unverkuerzt; nur Heading-Level fuer die neue Dateistruktur angepasst. -->
+
+### 2.12 Zeitgebundene Innenperspektive und Digital-Twin-Layer
+
+Die Persistenz der vollständigen Kanshō-Dialoge wird als eigenständige Quelle des persönlichen digitalen Zwillings betrachtet.
+
+Kanshō ergänzt mindnet um eine **Lived Experience / Inner-State Layer**.
+
+Diese Ebene soll zeitgebunden rekonstruierbar machen:
+
+- geäußerte Gedanken,
+- beschriebene Gefühle,
+- Zweifel,
+- Ambivalenzen,
+- Bewertungsprozesse,
+- alternative Überlegungen,
+- offene Fragen,
+- Entwicklung einer Haltung innerhalb und zwischen Dialogen.
+
+#### Architektur-Invarianten
+
+1. **Originalquelle bleibt erhalten**  
+   Rohdialog beziehungsweise verlässliche Originalrepräsentation darf nicht durch Summaries oder extrahierte Memories ersetzt werden.
+
+2. **Abgeleitete Schichten bleiben als solche gekennzeichnet**  
+   Emotionseinordnung, Hypothese, Pattern, Memory, Knowledge Delta oder Self-Model-Aussage sind Ableitungen mit Provenance.
+
+3. **Zeitbezug ist wesentlich**  
+   Aussagen müssen im späteren Memory-/Datenmodell zeitlich einordenbar sein.
+
+4. **Frühere Zustände werden nicht überschrieben**  
+   Eine heutige Sicht ersetzt nicht automatisch die frühere Innenperspektive.
+
+5. **Widerspruch ist zulässige Information**  
+   Unterschiedliche Sichtweisen zu verschiedenen Zeitpunkten dürfen nebeneinander bestehen.
+
+6. **Keine objektive Psychologisierung**  
+   Aus Dialogen wird die geäußerte Innenperspektive modelliert, nicht ein behaupteter „wahrer“ psychischer Zustand.
+
+7. **Re-Grounding muss bis zu dieser Quellenebene reichen können**  
+   Langfristige Ableitungen müssen bei Bedarf gegen die ursprünglichen Dialoge geprüft werden können.
+
+#### Architekturweite Auswirkungen
+
+Dieses Prinzip muss später insbesondere berücksichtigt werden in:
+
+- `dialogue_data_model.md`
+- `memory_architecture.md`
+- `episodic_memory.md`
+- `self_model.md`
+- `temporal_memory.md`
+- `conflicts_forgetting_and_correction.md`
+- `context_builder.md`
+- `context_drift_and_regrounding.md`
+- `mindnet_integration.md`
+- `obsidian_integration.md`
+- `memory_write_policy.md`
+- `versioning_and_provenance.md`
+- `retention_and_deletion.md`
+- `privacy_principles.md`
+- `sensitive_personal_data.md`
+- `memory_transparency.md`
+
+Bei diesen Kapiteln ist jeweils zu prüfen, ob die Point-in-Time-Rekonstruktion der ursprünglichen Innenperspektive erhalten bleibt.
+