Dateien nach "docs/architecture/functional" hochladen

docs/architecture/functional/fachliche_zielarchitektur.md

@@ -172,6 +172,42 @@ Vor einer strukturellen Vereinfachung wird geprüft:
 
 Erst wenn diese Prüfung keine relevanten Funktionsverluste zeigt, soll eine interne Vereinfachung vorgenommen werden.
 
+
+## 2.9 Context Fidelity und Re-Grounding
+
+Verdichtete Zustände, Thread Memories und Reflection-Space-Sichten dürfen nicht unbegrenzt rekursiv aufeinander aufbauen, ohne den ursprünglichen Kontext erneut zu prüfen.
+
+Die fachliche Zielarchitektur fordert deshalb einen **Context-Fidelity-/Drift-Mechanismus**.
+
+Dieser soll beantworten:
+
+> Wie sicher kann Kanshō sein, dass der aktuell verwendete verdichtete Kontext noch ausreichend treu zu den zugrunde liegenden Quellen ist?
+
+Bei ausreichendem Drift-Risiko wird ein **Re-Grounding** ausgelöst.
+
+Re-Grounding bedeutet:
+
+- relevante Ursprungsquellen erneut abrufen,
+- bisherigen verdichteten Kontext gegen diese Quellen prüfen,
+- Widersprüche und Veränderungen erkennen,
+- den aktuellen Zustand gegebenenfalls neu ableiten,
+- Provenance und Änderungshistorie erhalten.
+
+Der Mechanismus muss sowohl:
+
+- automatisch beziehungsweise systemseitig ausgelöst werden können,
+- als auch ausdrücklich durch den Nutzer anforderbar sein.
+
+Die konkrete technische Berechnung eines Index, Scores oder Zustandsmodells wird bewusst noch nicht festgelegt.
+
+Für Entwicklung und Test soll die Admin-/Developer View später mindestens sichtbar machen können:
+
+- letzten vollständigen Re-Grounding-Zeitpunkt,
+- relevante Drift-/Fidelity-Indikatoren,
+- verwendete Quellschichten,
+- Gründe für ausgelöstes Re-Grounding,
+- Unterschiede zwischen vorherigem und neu abgeleitetem Kontext.
+
 # 3. Vorgeschlagene Repository-Struktur
 
 ```text
@@ -215,7 +251,8 @@ kansho/
 │   │   ├── 06_writing_profile.md
 │   │   ├── 07_temporal_memory.md
 │   │   ├── 08_conflicts_forgetting_and_correction.md
-│   │   └── 09_context_builder.md
+│   │   ├── 09_context_builder.md
+│   │   └── 10_context_drift_and_regrounding.md
 │   │
 │   ├── 05_reflection_intelligence/
 │   │   ├── 01_reflection_model.md
@@ -1286,6 +1323,8 @@ Bereits entschieden:
 - Ein Reflection Space ist kein bloßer Ablageort, sondern eine laufend aktualisierte Sicht auf einen zusammenhängenden persönlichen Denk- und Erfahrungsraum.
 - Ein Reflection Space soll Orientierung, Fortsetzung, offene Fragen, Historie und Entwicklung unterstützen.
 - Der aktuelle Zustand eines Reflection Space muss auf zugrunde liegende Quellen zurückführbar sein.
+- Verdichteter Langzeitkontext muss auf mögliche Context Drift geprüft und bei Bedarf aus den Ursprungsquellen neu geerdet (Re-Grounding) werden.
+- Re-Grounding kann systemseitig oder ausdrücklich durch den Nutzer ausgelöst werden.
 
 Als Nächstes zu klären:
 

docs/architecture/functional/produktvision_und_produktidentitaet.md

@@ -542,6 +542,84 @@ Wichtig:
 
 Damit wird der Reflection Space zu einer **lebendigen, kontextuellen Sicht auf persönliche Entwicklung innerhalb eines bestimmten Zusammenhangs**.
 
+
+## 8.8 Context Drift und Re-Grounding
+
+Die verdichtete aktuelle Sicht eines Reflection Space dient dazu, langfristige Dialoge handhabbar zu machen. Diese Verdichtung darf jedoch nicht dazu führen, dass Kanshō über längere Zeit nur noch auf früheren Zusammenfassungen, abgeleiteten Erinnerungen oder bereits interpretierten Zuständen aufbaut.
+
+Daher benötigt Kanshō fachlich einen Mechanismus zur Bewertung, **wie weit der aktuell verwendete Kontext noch zuverlässig auf den ursprünglichen Quellen basiert**.
+
+Arbeitstitel:
+
+- **Context Drift Index**
+- alternativ: **Re-Grounding Need**
+- alternativ: **Context Fidelity State**
+
+Die endgültige Bezeichnung ist offen.
+
+### Zweck
+
+Der Mechanismus soll Kanshō veranlassen, bei zunehmender Unsicherheit oder möglicher semantischer Drift den tatsächlichen historischen Kontext erneut nachzuvollziehen.
+
+Dazu kann die KI – abhängig von Situation und Relevanz – erneut auf zugrunde liegende Quellen zurückgreifen, beispielsweise:
+
+- Originaldialoge,
+- frühere Tagebucheinträge,
+- Episoden und Memories,
+- Obsidian-Quellen,
+- mindnet-Knoten und deren Provenance,
+- bestätigte Self-Model-Aussagen,
+- frühere Hypothesen und deren Entwicklungsverlauf.
+
+### Fachliche Trigger für Re-Grounding
+
+Ein erneutes Nachvollziehen des Ursprungskontexts soll insbesondere in Betracht gezogen werden, wenn:
+
+- ein Kontext über viele Verdichtungs- oder Aktualisierungsschritte fortgeschrieben wurde,
+- der letzte vollständige Quellenabgleich lange zurückliegt,
+- neue Informationen bisherigen Aussagen widersprechen,
+- mehrere Threads oder Reflection Spaces miteinander verschmelzen,
+- eine Aussage hohe persönliche Bedeutung besitzt,
+- das Self Model oder grundlegende Werte betroffen sind,
+- die KI selbst geringe Sicherheit bezüglich des Zusammenhangs erkennt,
+- Herkunft oder Provenance einer relevanten Aussage nicht ausreichend klar ist,
+- der Nutzer eine Einordnung korrigiert,
+- der Nutzer ausdrücklich verlangt, den ursprünglichen Kontext erneut nachzuvollziehen.
+
+### Nutzerinitiierte Re-Grounding-Funktion
+
+Der Nutzer soll Kanshō jederzeit sinngemäß anweisen können:
+
+> „Prüfe noch einmal den ursprünglichen Kontext.“
+
+oder:
+
+> „Geh dafür noch einmal auf die ursprünglichen Reflexionen zurück.“
+
+Kanshō soll dann nicht lediglich die bestehende Zusammenfassung erneut interpretieren, sondern – soweit verfügbar – auf die zugrunde liegenden Quellen zurückgreifen.
+
+### Verhältnis zur Nutzer-Transparenz
+
+Diese Re-Grounding-Funktion ist von der zuvor beschriebenen Aufklappbarkeit zu unterscheiden.
+
+- **Aufklappen / Provenance View:** Der Nutzer möchte sehen, worauf eine Aussage basiert.
+- **Re-Grounding:** Kanshō selbst rekonstruiert den relevanten Kontext erneut aus den Ursprungsquellen und prüft seine bisherige Verdichtung beziehungsweise Interpretation.
+
+Beide Funktionen greifen auf ähnliche Provenance-Strukturen zurück, dienen aber unterschiedlichen Zwecken.
+
+### Kein blindes Überschreiben
+
+Ein erneuter Quellenabgleich soll frühere Zustände nicht spurlos überschreiben.
+
+Wenn sich die bisherige Einordnung ändert, sollte nachvollziehbar bleiben:
+
+- was zuvor angenommen wurde,
+- welche neuen beziehungsweise erneut geprüften Quellen berücksichtigt wurden,
+- warum sich die Einordnung verändert hat,
+- welcher aktuelle Stand daraus entstanden ist.
+
+Die konkrete Berechnung eines Drift- oder Fidelity-Werts wird erst in der technischen Architektur spezifiziert.
+
 # 9. Dialogfäden
 
 Ein Gespräch kann mehrere Themen oder Reflexionsfäden enthalten.
@@ -1375,6 +1453,10 @@ Die folgenden Punkte sind bewusst noch nicht entschieden.
 | Reflection Space | kein Ablageort, sondern lebendiger Denk- und Erfahrungsraum | entschieden |
 | Reflection-Space-Zustand | laufend aktualisierte, quellengebundene Sicht auf den aktuellen Stand | entschieden |
 | Kernnutzen eines Space | Orientierung, Fortsetzung, offene Fragen, Historie und Entwicklung | entschieden |
+| Context Drift | Kanshō muss mögliche Drift verdichteter Langzeitkontexte erkennen können | entschieden |
+| Re-Grounding | bei Bedarf Rekonstruktion aus Ursprungsquellen statt erneuter Interpretation bestehender Summaries | entschieden |
+| Nutzer-Trigger | Nutzer kann erneuten Quellenabgleich ausdrücklich anfordern | entschieden |
+| Drift-Metrik | fachlich erforderlich, konkrete Berechnung und Bezeichnung später technisch zu spezifizieren | bevorzugte Richtung |
 | Produktname Kanshō | Arbeitstitel | offen |
 
 ---