Die **Dateinamen selbst bleiben stabil und enthalten keine Versionsnummern oder laufenden Nummerierungspräfixe**. Versionierung erfolgt über Gitea beziehungsweise die Dokumentmetadaten, nicht durch Umbenennen der Datei.
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.
Da die Produktkonzeption über einen langen Dialog hinweg entsteht, wird nicht nur der spätere Anwendungskontext, sondern auch die **Konzeptdokumentation selbst** gegen Drift geschützt.
Vor dem Wechsel in einen neuen größeren Themenblock oder vor einem Handover soll geprüft werden:
1. Sind alle expliziten Nutzeranforderungen seit dem letzten Audit dokumentiert?
2. Sind gemeinsam getroffene Entscheidungen vollständig erhalten?
3. Wurden ursprünglich konkrete Anforderungen ungewollt verallgemeinert oder abgeschwächt?
4. Wurden offene Punkte versehentlich als entschieden dargestellt oder umgekehrt?
5. Sind Root Causes und Begründungen architekturrelevanter Entscheidungen erhalten?
6. Widersprechen sich Zielarchitektur und Fach-/Produktdokumente?
7. Ist der Interviewstatus aktuell?
8. Wurden Inhalte stillschweigend gelöscht oder durch eine kürzere Formulierung ersetzt?
9. Sind Dateinamen und Repository-Struktur weiterhin mit den vereinbarten Gitea-Prinzipien konsistent?
Korrekturen aus einem Audit sollen additiv erfolgen. Inhaltliche Löschungen oder Verdichtungen dürfen nur vorgenommen werden, wenn sie als bewusste Änderung nachvollziehbar sind.
### Audit-Checkpoint 2026-08-18
Vor dem Wechsel vom Reflection-Space-Block zu den typischen Nutzungssituationen wurde die bestehende Dokumentation gegen den bisherigen Konzeptdialog geprüft.
Dabei wurden keine bewussten fachlichen Entscheidungen verworfen. Es wurden jedoch mehrere Stellen identifiziert, an denen frühere konkrete Aussagen zu allgemein geworden oder der Dokumentstatus veraltet war. Additiv beziehungsweise strukturell korrigiert wurden insbesondere:
- explizite Verankerung von Kanshō als bewusst stärker KI-kollaborative Jinkendo-Komponente,
- Wiederherstellung des konkret genannten Referenzrahmens „Day One im Gold-Abo“ für die spätere Journaling-Analyse,
- explizite Sicherung des generierten Tagebucheintrags als vorgesehene Kernfunktion der täglichen Reflexion,
- Dokumentation der vorläufigen sichtbaren Reflection-Space-Baseline,
- Dokumentation, dass Reflection Spaces sowohl kurz-/mittelfristig als auch langfristig relevant sein können,
- Aktualisierung des Interviewstatus: Reflection Spaces vorläufig ausreichend geklärt; typische Nutzungssituationen als nächster Block,
- Entfernung numerischer Präfixe aus den vorgeschlagenen Gitea-Datei- und Ordnernamen,
- Korrektur inkonsistenter Kapitel- und Listenummerierungen,
- strukturelle Verschiebung des Prinzips „Einfachheit an der Oberfläche, Intelligenz im Kern“ aus den Integrationsprinzipien in die Produktprinzipien, ohne inhaltliche Kürzung.
Dieser Checkpoint dokumentiert den Abgleich mit dem bis zu diesem Zeitpunkt vorliegenden Konzeptdialog. Spätere Erkenntnisse können bestehende Punkte konkretisieren oder bewusst ändern, sollen diese Änderungen jedoch nachvollziehbar dokumentieren.
## 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.
## 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.
## 2.13 Privacy Gateway und External-AI-Guardrails
Für leistungsfähige Kanshō-Funktionen ist externe KI-Inferenz grundsätzlich zulässig und aufgrund der aktuell begrenzten lokalen Modellleistung voraussichtlich notwendig.
Gleichzeitig verarbeitet Kanshō besonders sensible, langfristige autobiografische und dialogische Daten.
Daraus folgt die verbindliche Architektur-Invariante:
> **Identität bleibt lokal. Externe Intelligenz erhält nur den notwendigen, minimierten und soweit sinnvoll pseudonymisierten Kontext.**
Persönliche externe AI-Aufrufe müssen deshalb über eine lokale Privacy-Gateway-/Egress-Schicht laufen.
Diese Schicht muss mindestens berücksichtigen:
- Datenminimierung,
- Pseudonymisierung und symbolische Platzhalter,
- ausschließlich lokale Identity-Mappings,
- getrennten Internal und External Model Context,
- Provider-/ZDR-Policy,
- Fail-Closed-Verhalten,
- getrennte Policies für LLM-, Tool- und Web-Egress,
- lokale Response-Validation und Rehydration,
- Auditierbarkeit ohne vollständige Prompt-Logs.
Die vollständige fachliche Herleitung und Guardrail-Spezifikation wird in `guardrails.md` geführt. Spätere Kapitel zu AI Architecture, Data Architecture, Privacy, Security, Voice, Web/Tool-Nutzung, Memory und Integrationen müssen damit konsistent bleiben.
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.
