docs/architecture/functional/fachliche_zielarchitektur.md

@@ -272,80 +272,3 @@ Die **technische** Zielarchitektur liegt parallel unter `docs/architecture/techn
 
 Der detaillierte Kapitelplan, die Interviewmethode, Definition of Done, Fortschrittsstatus und der nächste Interviewblock werden ab jetzt in `interview_plan.md` gepflegt.
 
----
-
-# Foundation-Checkpoint vor Implementierungsstart – 2026-08-21
-
-**Status: neue aktuelle Arbeitssteuerung; frühere Interview-/Intent-Statusangaben bleiben als historische Zwischenstände erhalten**
-
-## Anlass
-
-Die Fachkonzeption wurde bewusst weit genug entwickelt, um teure spätere Refaktierungen bei Memory, Context, Reflection Spaces, Provenance und langfristiger Kontinuität zu vermeiden.
-
-Gleichzeitig besteht das Risiko, dass eine vollständige Umsetzung des gesamten Zielmodells zu einer überkomplexen ersten Anwendung führt und ein Coding-Agent aus dem umfangreichen Konzept verkürzte oder falsche Implementierungsannahmen ableitet.
-
-Daher wird zwischen drei Ebenen unterschieden:
-
-> **Target Concept → Implementation Foundation → Vertical MVP Slices**
-
-Das ausführliche Fachkonzept beschreibt, wohin Kanshō wachsen können muss.
-
-Die Implementation Foundation definiert nur die Architekturregeln, die frühe Sackgassen verhindern sollen.
-
-Ein MVP Slice implementiert nur eine kleine real nutzbare Produktfunktion auf dieser Foundation.
-
-## Ergebnis des Foundation Audits
-
-### Kein grundlegender Widerspruch festgestellt
-
-Die aktuellen Kernentscheidungen sind fachlich miteinander vereinbar:
-
-- Originalquellen bleiben kanonische Referenzbasis.
-- Kanshō besitzt die langfristige Dialog-, Erlebnis- und Reflexionsgeschichte; mindnet das langfristig integrierte persönliche Wissensnetz.
-- Reflection Spaces sind lebendige Bedeutungs- und Kontextbereiche und keine bloßen Ablageordner.
-- Reflection Space first / Long-Term Memory on demand begrenzt die aktive Kontextmenge.
-- Provider State und Retrieval-Indizes sind Hilfs-/Optimierungsschichten und keine fachliche Source of Truth.
-- AI Hypotheses, zeitgebundene Selbstaussagen und bestätigtes persönliches Wissen bleiben unterscheidbar.
-- User Correction beeinflusst Current Validity, ohne historische Quellen zu verfälschen.
-- Memory Write / Update ist signal-driven und soll nicht nach jedem Turn alle möglichen Objektarten analysieren.
-- Ein wesentlicher generativer Hauptmodell-Call pro Turn bleibt der Normalfall.
-
-### Erkannte Status-Drift: 11 Intents
-
-Frühere Abschnitte dieses Dokuments behandeln die elf Nutzungssituationen als nächsten Interviewblock beziehungsweise als unmittelbar weiter auszuarbeitende Konzeptsequenz.
-
-Diese Arbeitssteuerung ist **nicht mehr aktuell**.
-
-Die elf Nutzungssituationen bleiben fachlich nützliche Szenarien, sind aber kein Critical-Path-Gate für den Implementierungsstart und müssen nicht als elf technische Intent Engines realisiert werden.
-
-Sie werden künftig primär betrachtet als:
-
-- UX- und Nutzungsszenarien,
-- Acceptance Cases,
-- Test- und Validierungskatalog,
-- mögliche spätere Spezialisierungen, falls reale Nutzung dies rechtfertigt.
-
-## Aktueller Critical Path
-
-Vor dem Coding werden nur noch folgende Schritte als notwendig betrachtet:
-
-1. implementierungsrelevanten Memory-/Continuity-Core abschließen,
-2. kompakte `implementation_foundation.md` als Coding-Leitplanke festziehen,
-3. Foundation-/Drift-Audit durchführen,
-4. ersten vertikalen MVP Slice konkret spezifizieren,
-5. Coding beginnen.
-
-Der erste MVP Slice soll bewusst deutlich kleiner sein als das vollständige Kanshō-Zielmodell.
-
-Aktuell bevorzugter Kandidat:
-
-> **Journal / Daily Reflection als Day-One-artige Keimzelle auf Kanshō-Foundations**
-
-Die konkrete Nutzeranwendung, UX, In-/Out-of-Scope-Funktionen und Acceptance Criteria werden nach diesem Foundation-Abschluss separat spezifiziert.
-
-## Implementierungsprinzip
-
-> **Nicht das Zielmodell vorbauen. Nur die Foundations vorbauen, deren späteres Nachrüsten teuer wäre; danach vertikal und nutzungsgetrieben iterieren.**
-
-Damit ist die ausführliche Konzeptarbeit weiterhin verbindliche Leitplanke gegen strukturelle Sackgassen, aber kein monolithisches Lastenheft für den ersten Coding-Schritt.
-

docs/architecture/functional/memory_and_context_context.md

@@ -1193,575 +1193,3 @@ Nicht mehr als grundsätzlich offen gelten:
 - separater Modellaufruf für jede Space-Erkennung,
 - Kosten und Latenz nur als nachgelagerte Optimierung,
 - Gleichsetzung von langfristiger Speicherung und aktiver Relevanz.
-
-
----
-
-## Memory Write / Update Policy
-
-**Status: fachliche Baseline entschieden; konkrete technische Implementierung und objektspezifische Parameter offen**
-
-Die Memory Write / Update Policy regelt, welche Informationen Kanshō nach einem Dialogturn automatisch bewahren, operativ fortschreiben, als Kandidaten ableiten oder nur nach erhöhtem Evidenz- beziehungsweise Bestätigungsniveau etablieren darf.
-
-Ziel ist weder maximale Extraktion noch maximale Zurückhaltung. Kanshō soll genügend Struktur erzeugen, um langfristige Reflexionskontinuität zu ermöglichen, ohne den Dialog durch administrative Bestätigungen, Objektinflation oder unnötige KI-Verarbeitung zu belasten.
-
-### Grundprinzip
-
-> **Source preserves. Explicit user meaning may establish directly. Model-derived meaning starts cautiously. Policy governs promotion. User correction governs current validity.**
-
-Daraus folgen vier unterschiedliche fachliche Schreibarten.
-
-### 1. Source Write
-
-Quellen werden entsprechend der bestehenden Default-Quellbewahrung unmittelbar und ohne Significance Gate erhalten.
-
-Dazu gehören insbesondere:
-
-- User Messages,
-- AI Messages als historischer Dialogbestandteil,
-- Sessions,
-- relevante Anhänge und Eingaben,
-- Zeitbezug und technische Provenance.
-
-Für Source Writes gilt keine vorgelagerte Frage, ob eine Aussage „wichtig genug“ ist. Ihre spätere Bedeutung darf sich erst im Zeitverlauf zeigen.
-
-### 2. Operational State Update
-
-Reversible operative Zustände dürfen grundsätzlich automatisch fortgeschrieben werden, sofern frühere Zustände, Provenance und Korrigierbarkeit erhalten bleiben.
-
-Dazu können insbesondere gehören:
-
-- aktueller Session State,
-- bestehender Primary Reflection Space,
-- Related Spaces,
-- bestehende Thread-Zuordnung,
-- offene Fragen,
-- Resurfacing Anchors,
-- aktuelle Thread- oder Space-Zustände.
-
-Beispiel:
-
-Ein über mehrere Tage fortgeführtes Urlaubstagebuch darf den bestehenden Reflection Space `Lošinj 2026` automatisch weiterverwenden, ohne täglich eine Nutzerbestätigung zu verlangen.
-
-### 3. Derived Candidate Write
-
-Kanshō darf mögliche Bedeutungen selbstständig erkennen und als vorläufige Kandidaten beziehungsweise Hypothesen markieren.
-
-Dazu können gehören:
-
-- Thread Candidate,
-- Space Candidate,
-- Experience Candidate,
-- Insight Candidate,
-- Open Question Candidate,
-- Observed Pattern,
-- AI Hypothesis.
-
-Verbindliche Regel:
-
-> **Automatisch erkennen bedeutet nicht automatisch als etablierte Wahrheit übernehmen.**
-
-### 4. Established / High-Impact Write
-
-Langlebige oder fachlich folgenreiche Strukturen unterliegen objektspezifischen Promotion Policies.
-
-Dazu können insbesondere gehören:
-
-- Established Experience,
-- Established Thread,
-- Reflection Memory,
-- bestätigtes Insight,
-- etabliertes Observed Pattern,
-- Self-Model-Aussage,
-- Promotion nach mindnet.
-
-Je langfristiger, identitätsnäher oder folgenreicher eine Aussage ist, desto höher müssen Evidenz-, Provenance- und gegebenenfalls Bestätigungsanforderungen sein.
-
----
-
-## Drei Write-Autonomiestufen
-
-**Status: Baseline entschieden**
-
-Für die Implementierungslogik sollen die Write-Entscheidungen fachlich auf drei Autonomiestufen reduzierbar bleiben.
-
-### Automatic
-
-Typischerweise:
-
-- Source Writes,
-- Session State,
-- Fortführung bestehender Threads,
-- eindeutige Space-Zuordnungen,
-- reversible operative States.
-
-### Evidence-gated
-
-Typischerweise:
-
-- Experiences,
-- Insights,
-- Reflection Memories,
-- neue langlebige Threads,
-- neue langlebige Spaces,
-- längerfristige Patterns.
-
-Hier entscheidet die jeweilige Policy anhand objektspezifischer Evidenz.
-
-### Confirmation-sensitive
-
-Typischerweise:
-
-- grundlegende Self-Model-Aussagen,
-- neue zentrale Werte- oder Identitätsaussagen aus Modellinferenz,
-- weitreichende Änderungen identitätsnaher persönlicher Modelle.
-
-Confirmation-sensitive bedeutet nicht zwingend einen separaten administrativen Bestätigungsdialog. Bestätigung kann natürlich im Reflexionsgespräch entstehen.
-
----
-
-## Herkunftspfade persönlicher und abgeleiteter Aussagen
-
-**Status: fachliche Baseline entschieden**
-
-Die Write Policy muss die Herkunft einer Aussage berücksichtigen.
-
-### Explicit User Statement
-
-Eine eindeutige Nutzeraussage kann abhängig vom Objekttyp unmittelbar ausreichend Evidenz für einen etablierten Zustand liefern.
-
-Beispiel:
-
-> „Selbstbestimmung ist für mich einer der wichtigsten Werte.“
-
-Eine solche explizite Aussage muss nicht künstlich denselben Candidate-Prozess durchlaufen wie eine KI-Inferenz.
-
-Die Provenance bleibt dennoch erhalten:
-
-- Aussage,
-- Zeitpunkt,
-- Source Reference,
-- Ursprung `Explicit User Statement`.
-
-### User/Dialog-derived Candidate
-
-Eine im Dialog entstehende Bedeutung, die nicht bereits als eindeutige explizite Nutzeraussage vorliegt, kann zunächst Candidate werden und evidenzbasiert promoted werden.
-
-### AI-derived Hypothesis
-
-Eine von Kanshō formulierte Interpretation startet mit erhöhter Zurückhaltung.
-
-Beispiel:
-
-> „Vielleicht spielt Kontrolle bei dir eine größere Rolle, als dir bisher bewusst war.“
-
-Diese Aussage darf allein aufgrund ihrer Formulierung durch die KI nicht zu einem bestätigten Pattern oder Self-Model-Eintrag werden.
-
-Verbindliche Regel:
-
-> **AI-generated reflection content is not automatically user memory.**
-
-Nutzeraufnahme, spätere Evidenz oder ausdrückliche Bestätigung können die Hypothese später aufwerten.
-
----
-
-## Zeitgebundene Selbstaussage ist nicht automatisch stabiles Personal Model
-
-**Status: entschieden**
-
-Momentane Emotionen, Bewertungen oder Selbstbeschreibungen werden zunächst in ihrem zeitlichen Kontext bewahrt.
-
-Beispiel:
-
-> „Ich hasse meinen Job.“
-
-Dies kann fachlich eine aktuell geäußerte starke Unzufriedenheit abbilden, darf aber nicht automatisch als zeitloses Self-Model-Merkmal gespeichert werden.
-
-Verbindliche Regel:
-
-> **Current expressed state ≠ stable identity statement.**
-
-Längerfristige Patterns oder Threads können sich erst aus späterer Evidenz beziehungsweise weiterer Reflexion entwickeln.
-
----
-
-## Nutzerkorrektur und Current Validity
-
-**Status: entschieden**
-
-Explizite Nutzerkorrekturen besitzen Vorrang gegenüber fortgesetzter Modellinferenz.
-
-Beispiele:
-
-- „Das hast du falsch verstanden.“
-- „Das stimmt so nicht.“
-- „Das war nur damals so.“
-- „Das ist für mich gar kein wichtiges Thema.“
-
-Verbindliche Regel:
-
-> **User correction governs current validity.**
-
-Eine frühere Hypothese, Verdichtung oder Interpretation wird dadurch nicht aus der Historie gelöscht. Sie muss jedoch als verworfen, revidiert, historisch oder anderweitig nicht mehr aktuell markierbar sein und darf nicht stillschweigend weiter als aktuelle Wahrheit verwendet werden.
-
-Damit werden zwei Verantwortungen getrennt:
-
-- **History Preservation**
-- **Current Validity**
-
----
-
-## Änderungen ergänzen statt überschreiben
-
-**Status: entschieden**
-
-Persönliche Haltungen, Werte, Prioritäten, Threads und andere zeitabhängige Zustände sollen bei Veränderung nicht einfach überschrieben werden.
-
-Beispiel:
-
-- früher: Karriere besitzt sehr hohe Bedeutung,
-- später: Karriere besitzt deutlich geringere Bedeutung.
-
-Der aktuelle Zustand darf sich ändern, während der frühere Zustand weiterhin Point-in-Time-rekonstruierbar bleibt.
-
-Verbindliche Regel:
-
-> **New state updates current validity; it does not erase historical validity.**
-
----
-
-## Write Evaluation ist signal-driven, nicht exhaustive
-
-**Status: entschieden**
-
-Die fachlich verfügbaren Write- und Enrichment-Fähigkeiten dürfen nicht so implementiert werden, dass nach jedem Dialogturn sämtliche Objektarten vollständig neu analysiert werden.
-
-Verbindliche Regel:
-
-> **Write evaluation is signal-driven, not exhaustive.**
-
-Der Normalfall eines Dialogturns umfasst:
-
-- Source Write,
-- notwendigen Session-/Operational-State-Update,
-- nur bei tatsächlich auftretenden Signalen weitere Candidate- oder Enrichment-Verarbeitung.
-
-Die Abwesenheit eines relevanten Signals soll keine zusätzliche Memory-Analyse auslösen.
-
-> **The absence of a relevant signal should result in no enrichment work.**
-
-Beispiel:
-
-Ein alltäglicher Urlaubstagebuch-Eintrag kann vollständig mit Source Write, bestehendem Reflection Space und Session-State-Update verarbeitet werden, ohne gleichzeitig Experience-, Pattern-, Self-Model- und mindnet-Promotion zu analysieren.
-
----
-
-## Modell-Signale und Policy-Entscheidung
-
-**Status: fachliche Baseline entschieden**
-
-Der ohnehin für die sichtbare Reflexionsantwort verwendete Hauptmodell-Call darf bei Bedarf wenige strukturierte Signale für die Write Policy mitliefern.
-
-Mögliche Signale können beispielsweise betreffen:
-
-- bestehender oder veränderter Thread,
-- relevante Open Question,
-- Experience Candidate,
-- Insight Candidate,
-- mögliche Personal-Model-Relevanz,
-- erhöhte Signifikanz,
-- Widerspruch beziehungsweise Korrektur,
-- mögliche Space-Neubewertung.
-
-Die konkrete technische Struktur dieser Signale wird hier nicht festgelegt.
-
-Verbindliches Prinzip:
-
-> **Model proposes; policy decides; source preserves.**
-
-Das Modell soll damit nicht selbst die vollständige Persistenzlogik besitzen. Die Anwendung beziehungsweise Policy entscheidet, welche Signale zu welchen Writes, Candidates oder späteren Prüfungen führen.
-
----
-
-## Inline, Checkpoint und Deep Enrichment
-
-**Status: fachliche Baseline entschieden**
-
-Zur Begrenzung von Kosten, Latenz und unnötiger Modellarbeit werden drei Verarbeitungsklassen unterschieden.
-
-### 1. Inline / Hot
-
-Muss für den unmittelbaren Dialog verfügbar sein.
-
-Typischerweise:
-
-- Source Write,
-- Session State,
-- Primary Reflection Space,
-- aktive Threads,
-- unmittelbar relevante Open Questions,
-- explizite Nutzerkorrekturen,
-- eindeutige explizite Nutzerpräferenzen.
-
-Ziel ist, hierfür keinen zusätzlichen generativen LLM-Call neben dem normalen Hauptmodell-Call zu benötigen.
-
-### 2. Checkpoint Enrichment
-
-Kann gesammelt beziehungsweise gebündelt bewertet werden.
-
-Typischerweise:
-
-- Experience Promotion,
-- Insights,
-- Reflection Memories,
-- neue Threads,
-- neue Spaces,
-- begrenzte Konsolidierung.
-
-Geeignete Checkpoints können beispielsweise sein:
-
-- Session-Ende,
-- notwendige Zwischenverdichtung in langen Dialogen,
-- Übergang eines Reflection Space in einen ruhenden Zustand,
-- Wiederaufnahme eines längeren Reflexionsfadens.
-
-Mehrere Kandidaten sollen nach Möglichkeit gemeinsam statt durch jeweils eigene Modellaufrufe bewertet werden.
-
-### 3. Deep Enrichment
-
-Seltenere, bewusst aufwendigere Verarbeitung.
-
-Typischerweise:
-
-- langfristige Pattern-Erkennung,
-- Personal-Model-Re-Evaluation,
-- komplexe Konsolidierung,
-- longitudinale Entwicklungsanalyse,
-- tiefes Re-Grounding,
-- komplexe mindnet-Promotion beziehungsweise systemübergreifende Einordnung.
-
-Deep Enrichment darf höhere Kosten und Latenz verursachen, wenn der erwartete fachliche Nutzen dies rechtfertigt.
-
----
-
-## Enrichment Checkpoints und Nicht-Blockierung des Dialogs
-
-**Status: fachliche Baseline entschieden**
-
-Nicht jede langfristige Strukturentscheidung muss vor der sichtbaren Antwort abgeschlossen sein.
-
-Der normale Dialog soll nicht darauf warten müssen, dass beispielsweise:
-
-- Landmark-Signifikanz endgültig bewertet,
-- ein Pattern konsolidiert,
-- ein Self Model neu bewertet,
-- mindnet Promotion ausgeführt,
-- mehrere Sessions longitudinal analysiert
-
-wurden.
-
-Daraus folgt:
-
-> **The reflection response may complete before non-critical enrichment is finalized.**
-
-Fachlich relevante Enrichment-Signale dürfen bis zu einem geeigneten Checkpoint vorgemerkt werden.
-
-Die genaue technische Queue-, Job- oder Scheduling-Architektur ist noch nicht Teil dieses Fachblocks.
-
----
-
-## Effizienz und Processing Routing
-
-**Status: Architekturprinzip entschieden; konkrete Modelle und Routing-Regeln offen**
-
-Nicht jede Verarbeitungsaufgabe benötigt dasselbe Modell oder überhaupt einen generativen LLM-Aufruf.
-
-Die spätere technische Architektur soll erlauben, Aufgaben an den jeweils ausreichend leistungsfähigen Verarbeitungspfad zu routen, beispielsweise:
-
-- deterministische Anwendungslogik,
-- Datenbank-/Graph-/Index-Abfrage,
-- Embedding-/Similarity-Verarbeitung,
-- kleines günstiges Modell,
-- Hauptdialogmodell,
-- stärkeres Modell für seltene komplexe Longitudinalanalysen.
-
-Verbindliches Prinzip:
-
-> **Tasks shall be routable to the least expensive sufficient processing path.**
-
-Damit wird keine konkrete Modellwahl festgeschrieben.
-
----
-
-## Referenzfälle für die Write Policy
-
-**Status: fachliche Referenzbeispiele**
-
-### Alltäglicher Urlaubstagebuch-Eintrag
-
-Typische Folge:
-
-- Source Write,
-- Session State aktualisieren,
-- bestehenden Space fortsetzen,
-- kein automatischer neuer Thread,
-- keine automatische Experience,
-- kein Self-Model-Write.
-
-### Tiefgreifendes Meditationserlebnis
-
-Typische Folge:
-
-- Source Write,
-- bestehender Urlaubsspace bleibt Primary Space,
-- Meditationsreise kann Related Space beziehungsweise Candidate sein,
-- Experience Candidate möglich,
-- Thread Candidate nur bei weiterführender Reflexionsbewegung.
-
-### Expliziter zentraler Wert
-
-Typische Folge:
-
-- Source Write,
-- eindeutige Explicit User Statement,
-- abhängig von Policy direkte Etablierung im Personal Model möglich,
-- Provenance bleibt erhalten.
-
-### Momentane starke Emotion
-
-Typische Folge:
-
-- Source Write,
-- zeitgebundene Lived Experience,
-- kein automatisches stabiles Self Model.
-
-### KI-Hypothese ohne Nutzeraufnahme
-
-Typische Folge:
-
-- AI Message als Source,
-- gegebenenfalls AI Hypothesis,
-- kein automatisch bestätigtes Pattern.
-
-### Nutzer korrigiert etablierte Interpretation
-
-Typische Folge:
-
-- Correction als Source,
-- Re-Evaluation,
-- frühere Interpretation historisch erhalten,
-- Current Validity aktualisieren,
-- alte Aussage nicht mehr stillschweigend als aktuelle Wahrheit verwenden.
-
----
-
-## Aktualisierter Stand der offenen Punkte nach Write-Policy-Klärung
-
-**Status: Arbeitsstand**
-
-Die frühere offene-Punkte-Liste und der aktualisierte Stand nach der Context-Builder-Klärung bleiben als historische Arbeitsstände erhalten.
-
-Nach der vorliegenden Write-Policy-Klärung gilt die generische Memory Write / Update Policy fachlich nicht mehr als grundsätzlich offen.
-
-Weiter offen beziehungsweise bewusst später zu klären sind insbesondere:
-
-1. konkrete objektspezifische Promotion- und Evidence-Schwellen,
-2. konkrete technische Signalstruktur des Hauptmodell-Calls,
-3. technische Umsetzung von Checkpoint- und Deep-Enrichment-Verarbeitung,
-4. konkrete Processing-Routing-Logik und Modellzuordnung,
-5. technische Repräsentation von Current Validity, Revision und historischen States,
-6. endgültige Liste langlebiger fachlicher Entitäten,
-7. der Continuity Capability Contract,
-8. spätere Integration mit dem finalen Usage-/Intent-Modell,
-9. technische Data Architecture, Versionierung und Provenance,
-10. detaillierte Learning-/Policy-Governance.
-
-Nicht mehr grundsätzlich offen sind:
-
-- ob Quellen einer Significance-Prüfung vor Speicherung unterliegen,
-- ob reversible operative States automatisch aktualisiert werden dürfen,
-- ob KI-Ableitungen automatisch etablierte persönliche Wahrheit werden,
-- ob explizite Nutzeraussagen immer künstlich einen Candidate-Umweg benötigen,
-- ob Nutzerkorrekturen die aktuelle Gültigkeit beeinflussen,
-- ob jede Objektart nach jedem Turn vollständig neu analysiert werden muss,
-- ob jede Enrichment-Entscheidung vor der sichtbaren Antwort abgeschlossen sein muss,
-- ob jede Verarbeitungsaufgabe einen eigenen starken LLM-Aufruf benötigt.
-
----
-
-## Continuity Capability Contract
-
-**Status: fachliche Abschluss-Baseline für den implementierungsrelevanten Memory-/Continuity-Core**
-
-Der Continuity Capability Contract definiert nicht eine weitere interne Ontologie, sondern die beobachtbaren Fähigkeiten, an denen die langfristige Reflexionskontinuität von Kanshō gemessen wird.
-
-Kanshō erfüllt den fachlichen Anspruch eines langfristigen persönlichen Reflexionsbegleiters, wenn folgende Fähigkeiten zuverlässig realisierbar sind:
-
-1. **Im aktuellen Reflexionsraum bleiben**  
-   Der normale Dialog orientiert sich primär an aktueller Session, Primary Reflection Space, aktiven Threads und offenen Fragen. Das globale Langzeitgedächtnis wird nicht permanent aktiviert.
-
-2. **Sinnvoll fortsetzen**  
-   Ein früher begonnener Reflexionsfaden kann später wiederaufgenommen werden, ohne dass der Nutzer wesentliche bereits vorhandene Zusammenhänge erneut erklären muss.
-
-3. **Relevant erinnern statt maximal erinnern**  
-   Frühere Inhalte werden nur dann aktiviert, wenn sie den aktuellen Reflexionsschritt tatsächlich verbessern.
-
-4. **Aktuell und historisch unterscheiden**  
-   Frühere Sichtweisen, Gefühle, Bewertungen und Interpretationen werden nicht stillschweigend mit dem heutigen Zustand gleichgesetzt.
-
-5. **Veränderung erkennbar machen**  
-   Relevante Entwicklungen zwischen früheren und aktuellen Perspektiven müssen nachvollziehbar darstellbar sein.
-
-6. **Unsicherheit erhalten**  
-   AI Hypothesis, Observed Pattern, Candidate, explizite Nutzeraussage und bestätigte Erkenntnis bleiben unterscheidbar.
-
-7. **Korrigierbar bleiben**  
-   Eine ausdrückliche Nutzerkorrektur verändert Current Validity. Frühere Zustände bleiben historisch nachvollziehbar, werden aber nicht weiter als aktuelle Wahrheit verwendet.
-
-8. **Zur Quelle zurückkehren können**  
-   Wenn Genauigkeit, Widerspruch, historische Rekonstruktion oder Re-Grounding es erfordern, kann Kanshō auf die zugrunde liegenden Originalquellen zurückgreifen.
-
-9. **Keine künstliche Memory-Produktion**  
-   Eine Session muss nicht automatisch Experiences, Insights, Threads, Patterns, Reflection Memories oder andere langlebige Objekte erzeugen.
-
-10. **Kontinuität bleibt dienend**  
-    Memory, mindnet und Personal Model unterstützen den Reflexionsdialog und dürfen ihn nicht durch unnötiges Erinnern, Strukturieren oder Psychologisieren dominieren.
-
-11. **Normale Nutzung bleibt effizient**  
-    Ein wesentlicher generativer Hauptmodell-Call pro Dialogturn bleibt der Normalfall. Tieferes Retrieval und Enrichment werden signal- beziehungsweise bedarfsgesteuert aktiviert.
-
-12. **Providerunabhängige Kontinuität**  
-    Die langfristige Kontinuität darf nicht davon abhängen, dass ein bestimmter KI-Provider Conversation State dauerhaft hält.
-
-### Referenz-Akzeptanzfall
-
-Wenn der Nutzer nach längerer Zeit sagt:
-
-> „Ich möchte noch einmal über meine Meditationserfahrungen nachdenken.“
-
-soll Kanshō fachlich in der Lage sein:
-
-- den relevanten Reflection Space beziehungsweise Reflexionszusammenhang zu erkennen,
-- den aktuellen Stand und relevante offene Fäden zu berücksichtigen,
-- gezielt relevante frühere Experiences, Insights oder Quellen einzubeziehen,
-- irrelevante autobiografische Bereiche nicht automatisch zu aktivieren,
-- bei Bedarf eine frühere Aussage quellenorientiert zu rekonstruieren,
-- damalige und heutige Perspektive voneinander zu unterscheiden,
-- neue Erkenntnisse provenance-fähig und vorsichtig fortzuschreiben.
-
-### Abschlussgrenze dieses Fachblocks
-
-Mit Context Builder, Memory Write / Update Policy und diesem Continuity Capability Contract ist der implementierungsrelevante fachliche Memory-/Continuity-Core ausreichend spezifiziert.
-
-Nicht vor einem ersten produktiven Slice verbindlich auszudetaillieren sind insbesondere:
-
-- mathematische Promotion Scores,
-- vollständige Relationsontologie,
-- adaptive Policy-Learning-Algorithmen,
-- umfassende longitudinale Pattern-Erkennung,
-- ausgereiftes Self Model,
-- vollständige mindnet-Promotion,
-- finale technische Storage- und Retrieval-Architektur.
-
-Diese Punkte bleiben Ziel- beziehungsweise Ausbauarchitektur und blockieren den Start einer inkrementellen Implementierung nicht.
-