diff --git a/docs/architecture/functional/memory_and_context_context.md b/docs/architecture/functional/memory_and_context.md
similarity index 75%
rename from docs/architecture/functional/memory_and_context_context.md
rename to docs/architecture/functional/memory_and_context.md
index e636f2f..5f94566 100644
--- a/docs/architecture/functional/memory_and_context_context.md
+++ b/docs/architecture/functional/memory_and_context.md
@@ -1193,3 +1193,496 @@ 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.