diff --git a/docs/architecture/functional/reflection_outputs.md b/docs/architecture/functional/reflection_outputs.md new file mode 100644 index 0000000..a89028a --- /dev/null +++ b/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. + + + +## 17. Ergebnisse eines Reflexionsdialogs + +Ein Dialog kann mehrere unterschiedliche Ergebnisse erzeugen. + +Diese Ergebnisse müssen voneinander getrennt behandelt werden. + + + +### 17.1 Journal Entry + +Ein menschenlesbarer autobiografischer Text. + +Zielsystem: + +- primär Obsidian, +- damit indirekt mindnet. + +--- + + + +### 17.2 Reflection Memory + +Eine verdichtete, aber nachvollziehbare Erkenntnis aus einer Reflexion. + +Beispiele: + +- persönliche Einsicht, +- wiederkehrendes Thema, +- bestätigte Beobachtung. + +Zielsystem: + +- mindnet. + +--- + + + +### 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. + +--- + + + +### 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. diff --git a/docs/architecture/functional/reflection_spaces.md b/docs/architecture/functional/reflection_spaces.md new file mode 100644 index 0000000..3ccf7d5 --- /dev/null +++ b/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. + + + +## 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. + +--- + + + +### 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. + + + +### 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. + + + +### 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. + diff --git a/docs/architecture/functional/resurfacing_and_saturation.md b/docs/architecture/functional/resurfacing_and_saturation.md new file mode 100644 index 0000000..e600670 --- /dev/null +++ b/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. + + + +### 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. + + + +### 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. diff --git a/docs/architecture/functional/self_model_and_lived_experience.md b/docs/architecture/functional/self_model_and_lived_experience.md new file mode 100644 index 0000000..9e75741 --- /dev/null +++ b/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. + + + +### 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. + +--- + + + +## 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. + +--- + + + +### 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. + + + +### 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. +