Die normale Nutzeroberfläche soll interne KI-Strukturen bewusst abstrahieren.
Für Entwicklung, Test und Administration wird jedoch eine gesonderte **Admin-/Developer View** vorgesehen.
Diese dient insbesondere dazu, fachliche und später technische Entscheidungen nachvollziehen zu können, ohne die reguläre Nutzung mit interner Komplexität zu belasten.
Die Diagnoseansicht soll perspektivisch unter anderem Einblick geben in:
- Threads und Thread-Kandidaten,
- Reflection-Space-Zuordnungen,
- Konsolidierungsentscheidungen,
- Memory-Provenance,
- Confidence und Unsicherheit,
- Hypothesen,
- Context-Builder-Ergebnisse,
- verwendete Wissensquellen,
- Strukturänderungen.
Der Zugriff ist rollenbasiert und nicht für reguläre Nutzer vorgesehen.
Dieses Prinzip ist fachlich bereits entschieden; genaue UI, Berechtigungen und technische Implementierung werden später spezifiziert.
Architekturrelevante Entscheidungen mit langfristiger Tragweite oder späterem Vereinfachungsrisiko sollen nicht nur als Lösung dokumentiert werden.
Wo die Begründung für die spätere Nachvollziehbarkeit wesentlich ist, wird zusätzlich folgende Struktur festgehalten:
1.**Root Cause**– welches zugrunde liegende Problem oder welche Systembedingung erzeugt den Bedarf?
2.**Risiko**– welche fachlichen oder qualitativen Folgen entstehen ohne Gegenmaßnahme?
3.**Fachliche Konsequenz**– welche Eigenschaft muss das Produkt deshalb besitzen?
4.**Abgeleitete Anforderung / Entscheidung**– welcher Mechanismus oder welche Architekturleitplanke folgt daraus?
Dieses Prinzip soll verhindern, dass später nur noch ein Architekturmechanismus sichtbar ist, während sein ursprünglicher Zweck verloren geht und die Entscheidung deshalb fälschlich als entbehrliche Komplexität behandelt wird.
Die Anforderung an Context Fidelity und Re-Grounding entsteht nicht aus dem Wunsch nach zusätzlicher technischer Komplexität, sondern aus einer strukturellen Eigenschaft langfristiger KI-gestützter Dialogsysteme.
#### Root Cause
Kanshō soll Reflexionen, Dialoge, Threads und persönliche Entwicklung über Monate und Jahre hinweg fortführen können.
Dafür kann nicht bei jeder Interaktion der vollständige historische Originalkontext in das aktive Kontextfenster geladen werden. Langfristige Inhalte müssen daher selektiert, zusammengefasst, verdichtet oder in abgeleitete Memory- beziehungsweise Zustandsstrukturen überführt werden.
Jede Verdichtung ist jedoch zwangsläufig selektiv. Sie kann:
- Details weglassen,
- Gewichtungen verändern,
- Mehrdeutigkeiten reduzieren,
- zeitliche Zusammenhänge vereinfachen,
- Interpretationen stärker wirken lassen als die ursprünglichen Aussagen,
- frühere Hypothesen ungewollt stabilisieren.
Problematisch wird dies insbesondere dann, wenn spätere Verdichtungen nicht mehr auf Originalquellen, sondern auf bereits verdichteten Zuständen aufbauen.
Mit jeder weiteren Stufe kann sich der verwendete Kontext schrittweise vom ursprünglichen Bedeutungsgehalt entfernen.
#### Risiko
Ohne Gegenmechanismus besteht langfristig das Risiko, dass Kanshō nicht mehr primär auf die tatsächlichen Erlebnisse, Aussagen und dokumentierten Erfahrungen des Nutzers reagiert, sondern zunehmend auf seine eigenen früheren Verdichtungen und Interpretationen davon.
Dies kann insbesondere zu folgenden Problemen führen:
- Verlust relevanter Nuancen,
- Verstärkung früherer Fehlinterpretationen,
- Umdeutung von Hypothesen zu scheinbaren Tatsachen,
- falsche Musterbildung,
- unzutreffende Verknüpfungen zwischen Lebensbereichen,
- fehlerhafte Fortschreibung des Self Models,
- verzerrte Einordnung persönlicher Werte oder Entwicklungen,
- scheinbar konsistente, aber biografisch falsche Langzeitnarrative.
Besonders kritisch ist dieses Risiko bei Aussagen mit hoher persönlicher Bedeutung, etwa zu:
- Werten,
- Leitbild,
- Selbstbild,
- biografischen Wendepunkten,
- langfristigen Mustern,
- tiefen persönlichen Konflikten,
- Vergangenheitsbewältigung.
#### Fachliche Konsequenz
Provenance allein reicht nicht aus.
Es genügt nicht, nur zu wissen, **woher** eine verdichtete Aussage ursprünglich stammt. Kanshō muss zusätzlich beurteilen können, **wann die aktuell verwendete Verdichtung nicht mehr ausreichend zuverlässig ist und der Ursprungskontext erneut nachvollzogen werden sollte**.
Der langfristige Kontext darf daher nicht unbegrenzt rekursiv aus bereits abgeleiteten Zuständen fortgeschrieben werden.
#### Abgeleitete Anforderung
Kanshō benötigt einen fachlichen Mechanismus zur Bewertung der Kontexttreue beziehungsweise des Drift-Risikos.
Dieser Mechanismus muss bei Bedarf ein **Re-Grounding** auslösen können.
Re-Grounding bedeutet:
- relevante Ursprungsquellen erneut abrufen,
- den aktuell verwendeten verdichteten Kontext dagegen prüfen,
- Abweichungen, Widersprüche und Bedeutungsverschiebungen erkennen,
- den aktuellen Zustand gegebenenfalls neu ableiten,
- frühere Zustände und Änderungen nachvollziehbar erhalten.
Der Vorgang muss sowohl:
- automatisch beziehungsweise systemseitig,
- als auch ausdrücklich durch den Nutzer
ausgelöst werden können.
Die konkrete technische Realisierung – beispielsweise als numerischer Drift Index, mehrdimensionale Fidelity-Metrik oder zustandsbasierte Bewertung – wird erst in der technischen Architektur festgelegt.
Die fachliche Anforderung an Re-Grounding gilt unabhängig von dieser späteren technischen Ausgestaltung.
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.
- Welche Daten gehören fachlich weiterhin ausschließlich in die Quellanwendung?
**Zieldateien:**
-`04_kairo_integration.md`
-`05_mitai_integration.md`
-`06_shinkan_integration.md`
-`01_integration_principles.md`
---
## F3. AI Architecture
**Ziel:**
Die technische Umsetzung der kollaborativen KI definieren.
**Leitfragen:**
- ein Modell oder mehrere Rollen?
- Reflection Agent?
- Memory Agent?
- Context Builder?
- Journal Writer?
- Critic/Verifier?
- Model Routing?
- lokale Modelle?
- Cloud Modelle?
- Prompt Registry?
- Evaluation?
**Zieldateien:**
- gesamter Ordner `10_ai_architecture/`
---
## F4. Datenarchitektur
**Ziel:**
Kanonische Datenmodelle definieren.
**Leitfragen:**
- Conversation
- Message
- Thread
- Reflection Space
- Memory
- Hypothesis
- Insight
- Journal Entry
- Context Reference
- Action Candidate
- Writing Profile
- Self Model
**Zieldateien:**
- gesamter Ordner `11_data_architecture/`
---
# Phase G – Experience, Voice, PWA und Offline
## G1. Mobile-First Experience
**Ziel:**
Die Hauptnutzung auf dem Smartphone definieren.
**Leitfragen:**
- Was sieht der Nutzer beim Öffnen?
- Wie schnell kann eine Reflexion beginnen?
- Sprache oder Text?
- Einhandbedienung?
- Wie werden lange Dialoge dargestellt?
- Wie erscheinen frühere Threads?
- Wie vermeidet man Informationsüberladung?
**Zieldateien:**
-`01_experience_principles.md`
-`02_mobile_first.md`
-`03_home_and_entry_points.md`
-`04_conversation_ui.md`
---
## G2. Desktop Experience
**Ziel:**
Desktop nicht nur als vergrößerte Mobile UI behandeln.
**Leitfragen:**
- Welche Tätigkeiten sind auf Desktop besser?
- Welche Mehrspaltenansichten?
- Journal und Dialog nebeneinander?
- Recherche in alten Reflexionen?
- Mindnet-Verbindungen?
**Zieldatei:**
-`07_desktop_experience.md`
---
## G3. Sprache und Transkription
**Ziel:**
Voice als primäre mobile Interaktion prüfen.
**Leitfragen:**
- Push-to-talk?
- kontinuierliche Aufnahme?
- Live-Transkription?
- Audio speichern oder nach Transkription löschen?
- Korrektur vor Übergabe?
- offline?
- Unterbrechungen?
- Mischform Text + Sprache?
**Zieldateien:**
- gesamter Ordner `13_voice_and_media/`
---
## G4. PWA und Offline
**Ziel:**
Festlegen, was ohne Netz noch funktioniert.
**Leitfragen:**
- lokale Journaleinträge?
- lokale Dialoge?
- lokale Transkription?
- lokale kleine Modelle?
- Sync Queue?
- Verschlüsselung?
- Konfliktauflösung?
- Installation auf iOS/Android/Desktop?
**Zieldateien:**
- gesamter Ordner `14_pwa_and_offline/`
---
# Phase H – Datenschutz, Sicherheit und Vertrauen
## H1. Privacy by Design
**Ziel:**
Besonders sensible persönliche Langzeitdaten schützen.
**Leitfragen:**
- Welche Daten sind besonders kritisch?
- Verschlüsselung at rest und in transit?
- lokale Speicherung?
- Cloud Verarbeitung?
- Export?
- vollständiges Löschen?
- selektives Vergessen?
- Zugriff anderer Jinkendo-Apps?
**Zieldateien:**
-`01_privacy_principles.md`
-`02_sensitive_personal_data.md`
-`03_encryption_and_access.md`
-`05_export_delete_and_portability.md`
---
## H2. Memory Transparency
**Ziel:**
Der Nutzer muss verstehen und kontrollieren können, was Kanshō über ihn „weiß“.
**Leitfragen:**
- Kann man gespeicherte Memories ansehen?
- Quelle anzeigen?
- Confidence?
- korrigieren?
- löschen?
- Herleitung anzeigen?
- Self Model editieren?
**Zieldatei:**
-`04_memory_transparency.md`
---
## H3. Safety Boundaries
**Ziel:**
Grenzen bei psychisch belastenden, medizinischen oder anderweitig hochriskanten Themen definieren.
**Zieldateien:**
-`06_ai_safety_boundaries.md`
-`07_crisis_and_high_risk_scenarios.md`
-`06_conversation_safety_and_boundaries.md`
---
# Phase I – MVP und Delivery
## I1. MVP-Schnitt
**Ziel:**
Nach vollständiger fachlicher Konzeption eine erste vertikale Produktversion definieren.
Wichtig:
Der MVP soll nicht dadurch entstehen, dass beliebige Features gestrichen werden. Er soll eine **vollständige kleine Reflexionsschleife** ermöglichen.
Eine mögliche spätere vertikale Scheibe könnte sein:
1. Reflexionsraum auswählen oder erkennen,
2. kontextbezogenes Gespräch starten,
3. Dialog führen,
4. Thread Memory erzeugen,
5. Tagebucheintrag generieren,
6. Nutzer bestätigt,
7. Eintrag nach Obsidian überführen,
8. Reflection Memory in mindnet schreiben.
Dies ist noch keine endgültige MVP-Entscheidung.
**Zieldateien:**
- gesamter Ordner `16_product_delivery/`
---
# Phase J – Research und Benchmarking
Diese Phase kann parallel zu den anderen Phasen laufen.
Zu untersuchen sind insbesondere:
- Day One,
- KI-Journaling-Produkte,
- Reflection Apps,
- Mindfulness Apps,
- Meditation Apps,
- Personal Memory Systeme,
- Long-Term-Memory-Architekturen,
- Voice Journaling,
- Privacy Patterns,
- Personal AI.
**Zieldateien:**
- gesamter Ordner `17_research/`
---
# 5. Empfohlene Reihenfolge des weiteren Interviews
Die unmittelbar nächste Sequenz sollte lauten:
1.**Reflection Spaces**
2.**typische Nutzungssituationen**
3.**Gesprächseinstieg**
4.**Dialogmethodik**
5.**Threads und Branching**
6.**Dialogabschluss und Outputs**
7.**Memory Architecture**
8.**Self Model**
9.**Writing Profile**
10.**Context Builder**
11.**Reflection Frontiers**
12.**Journaling**
13.**Achtsamkeit**
14.**Meditation**
15.**Integrationen**
16.**AI Architecture**
17.**Mobile UX / Voice**
18.**Offline**
19.**Privacy / Safety**
20.**MVP**
Diese Reihenfolge verhindert, dass technische Entscheidungen zu früh getroffen werden, bevor klar ist, welches Verhalten das Produkt tatsächlich benötigt.
---
# 6. Interviewmethode
Für jedes Kapitel wird derselbe Arbeitsmodus empfohlen.
## Schritt 1 – Ausgangshypothese
Auf Basis der bisherigen Entscheidungen wird eine erste strukturierte Hypothese formuliert.
## Schritt 2 – gezielte Fragen
Es werden nur Fragen gestellt, die echte Produktentscheidungen verändern können.
## Schritt 3 – Szenarien
Die Entscheidung wird anhand konkreter Situationen geprüft.
## Schritt 4 – Gegenbeispiele und Grenzfälle
Bewusst problematische oder widersprüchliche Situationen werden getestet.
Zusätzlich wird bei strukturellen Vereinfachungen ein **Capability-Check** durchgeführt, damit keine bereits vorgesehenen Kernfähigkeiten unbeabsichtigt verloren gehen.
- 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.
