// Charaktersystem

Event-Sourcing — Events als Primärquelle

Die wichtigste architektonische Entscheidung des gesamten Systems: Werte des Charakters sind Aggregate aus Events, keine Primärdaten. Events sind die Wahrheit; alles andere wird berechnet.

Veröffentlicht: · Holger Theymann

Status: ✅ Vollständig ausgearbeitet

Kernidee

Die wichtigste architektonische Entscheidung des gesamten Systems: Werte des Charakters sind Aggregate aus Events, keine Primärdaten. Events sind die Wahrheit; alles andere wird berechnet.

Das hat vier Konsequenzen. Traceability: für jeden aktuellen Wert gibt es eine nachweisbare Ursache in Events. Konsistenz: Aggregate und Events können nicht divergieren, weil Aggregate neu berechnet werden. Re-Interpretierbarkeit: bei Reconsolidation werden Events umcodiert, nicht Werte ersetzt. Ethische Robustheit: die Geschichte des Charakters bleibt nachvollziehbar.

Theoretische Grundlage

Das Paradigma ist an drei Traditionen angelehnt:

Memory Reconsolidation (Nader, Ecker)

Erinnerungen sind nicht statisch — sie werden bei Abruf labil und können neu kodiert werden. Siehe Reconsolidation-Framework.

Konsequenz: Ein Event-basiertes System kann die therapeutische Veränderungsmechanik direkt abbilden.

Narrative Identity (McAdams)

Persönlichkeit auf der dritten Ebene ist die internalisierte Lebensgeschichte. Events sind die Atome dieser Geschichte. Siehe McAdams-Framework.

Event Sourcing (Software-Architektur)

In der Software-Architektur ist Event Sourcing ein bewährtes Muster: Zustände werden nicht direkt gespeichert, sondern als Folge von Events repräsentiert; der aktuelle Zustand ist eine Projektion.

Siehe Fowler 2005, Event Sourcing.

Die drei Dimensionen eines Events

Jedes Event im System trägt drei fundamentale Dimensionen:

1. Zeitpunkt

Der Zeitpunkt wird durch age_at (Alter des Charakters), date_context (kontextuelle Zeitangabe) und developmental_stage (entwicklungspsychologisches Stadium, z.B. Erikson) festgehalten.

2. Verfassung im Moment (state_at_encoding)

Das ist die Innovation gegenüber klassischen Event-Logs: Der Zustand des Charakters zum Zeitpunkt des Erlebens wird festgehalten. Das ist entscheidend, weil dasselbe Ereignis unterschiedlich codiert wird, je nach Verfassung.

state_at_encoding:
  developmental_stage: "schuleintritt"
  ego_maturity: "präoperational"
  polyvagal: "sympathetic → dorsal_collapse"
  window_of_tolerance: "überschritten"
  available_parts: []
  caregivers_available: false
  meaning_making_capacity: 0.3
  prior_related_wounds: []

Warum das wichtig ist: Ein Kind im dorsalen Shutdown codiert Ereignisse anders als ein regulierter Erwachsener. Traumatisches Encoding ist state-dependent (van der Kolk 2014), und die therapeutische Reaktivierung muss den ursprünglichen State ansprechen.

3. Das Ereignis selbst

Das Ereignis wird durch description (narrative Beschreibung), cue_signatures (sensorische, relationale, somatische, symbolische Signale), encoded_beliefs (welche Überzeugungen wurden gelernt) und contributes_to (welche Aggregate dieses Event beeinflusst) beschrieben.

Das vollständige Event-Schema

events:
  - id: "E-007"
    age_at: 7
    date_context: "1. Schultag 1987"
    description: "Lehrerin demütigt ihn vor der Klasse, weil er beim Vorlesen stottert"
    
    event_type: "acute_threat"   # acute_threat | chronic_stress | positive_experience | corrective | turning_point | reconsolidation
    
    state_at_encoding:
      developmental_stage: "schuleintritt"        # Erikson: industry_vs_inferiority
      ego_maturity: "präoperational"               # Piaget-Stadium
      polyvagal: "sympathetic → dorsal_collapse"
      window_of_tolerance: "überschritten"
      available_parts: []                          # noch im Aufbau
      caregivers_available: false
      meaning_making_capacity: 0.3
      prior_related_wounds: []                     # keine vorherige Wunde dieses Typs
    
    cue_signatures:
      sensory: 
        - "Lachen mehrerer Stimmen"
        - "Kreide-Geruch"
        - "Helligkeit des Klassenzimmers"
      relational:
        - "öffentliche Bewertung"
        - "keine Verbündeten"
        - "weibliche Autoritätsfigur"
      somatic:
        - "heiße Wangen"
        - "Magen-Kontraktion"
        - "Stockendes Atmen"
      symbolic:
        - "Autorität + Leistung + Scham"
    
    imprint_strength: 0.9              # wie tief hat sich dieses Event eingeprägt? (0-1)
    
    encoded_beliefs:
      - text: "Wenn ich sichtbar fehlerhaft bin, werde ich verstoßen"
        certainty: 0.85
      - text: "Autoritäten sind gefährlich"
        certainty: 0.6
    
    contributes_to:
      psyche.wunde: {weight: 0.8}
      psyche.luege: {weight: 0.6}
      protective_part.P-001: {weight: 0.5, role: "installed"}
      trigger.T-003: {weight: 1.0, role: "imprint"}
      grawe_needs.self_esteem: {delta: -35}
      grawe_needs.attachment: {delta: -15}
      hexaco.emotionality: {delta: +10}
    
    reconsolidation_history:
      - by_event: "E-042"
        date: "2025-11-03"
        mechanism: "mismatch_experience"
        imprint_delta: -0.1
        conditions_met: [reactivation, mismatch]
        conditions_pending: [repetition]

Aggregation: Wie Events zu Werten werden

Beispiel: psyche.wunde

Ein Charakter hat diese Events mit contributes_to.psyche.wunde:

E-001: weight 0.3 — elterliche Abwertung
E-007: weight 0.8 — Lehrerin-Demütigung (dominant)
E-019: weight 0.4 — Teenie-Zurückweisung

Die psyche.wunde wird daraus berechnet:

psyche:
  wunde:
    narrative_text: "Wenn ich sichtbar fehlerhaft bin, werde ich verstoßen"
    dominant_source_events: ["E-007"]   # höchster weight
    contributing_events: ["E-001", "E-007", "E-019"]
    aggregate_intensity: 0.72           # gewichteter Mittelwert der imprint_strengths

Der narrative_text wird entweder manuell kuratiert oder aus den Top-Beitrags-Events generiert (z.B. per Embedding-Clustering).

Beispiel: grawe_needs.self_esteem

Events produzieren Deltas, die zu aktueller Ausprägung + chronischer Frustration aggregieren:

grawe_needs:
  self_esteem:
    current_satisfaction: 30   # 0-100
    chronic_frustration: 0.7
    computation: |
      current_satisfaction = max(0, min(100, 50 + Σ(event.contributes_to.self_esteem.delta) × time_decay))
      chronic_frustration = std_dev(historical_satisfaction) × negativity_bias

Cue-Signature-Matching — das Trauma-Trigger-Prinzip

Bei jedem neuen Event kann das System fragen: Welche historischen Events haben ähnliche cue_signatures?

Der Match ist semantisch, nicht exakt. Implementiert über Embedding-Vergleich:

neue Szene cue_signatures:
  sensory: ["Kritik in Besprechung", "mehrere Zuhörer"]
  relational: ["Chef bewertet", "Kollegen hören mit"]
  somatic: ["Wangen heiß", "Magen eng"]
  symbolic: ["Autorität + Performance + Scham"]

Match in Event-Historie:
  E-007 — ähnlichkeit: 0.78
    cue_signatures match:
      sensory: "Lachen mehrerer Stimmen" ~ "mehrere Zuhörer"
      relational: "öffentliche Bewertung" ~ "Chef bewertet"
      somatic: "heiße Wangen" ~ "Wangen heiß"
      symbolic: "Autorität + Leistung + Scham" ~ "Autorität + Performance + Scham"

Das erlaubt dem System, spezifische Trauma-Reaktivierungen zu modellieren — nicht nur allgemeine Trigger, sondern individuelle Vergangenheits-Aktivierung.

Implementations-Hinweis: Das ist der Grund für den lokalen Vector-Store (LanceDB) in der Architektur.

Reconsolidation: Events werden umkodiert

Ein zentraler Aspekt: Events sind nicht read-only. Durch korrigierende Erfahrungen kann ihre emotionale Ladung verändert werden — die imprint_strength wird reduziert.

events:
  - id: "E-007"
    imprint_strength: 0.9         # ursprünglich
    
    reconsolidation_history:
      - by_event: "E-042"
        date: "2025-11-03"
        mechanism: "mismatch_experience"
        mismatch_content: |
          Ursprüngliche Lektion: "Fehler führen zu Demütigung"
          Neue Erfahrung: "Fehler können mit Wärme begegnet werden"
        imprint_delta: -0.1
        conditions_met: [reactivation, mismatch]
        conditions_pending: [repetition]
      
      - by_event: "E-051"
        date: "2026-02-12"
        imprint_delta: -0.12
        conditions_met: [reactivation, mismatch, repetition_start]
    
    current_imprint_strength: 0.68   # = 0.9 - 0.1 - 0.12

Das operationalisiert die Ecker-Bedingungen (Reaktivierung + Mismatch + Wiederholung) direkt. Siehe reconsolidation-ecker-nader.md und 10-reconsolidation.md.

Event-Typen

Das System unterscheidet mehrere Event-Typen:

TypCharakteristikTypischer imprint_strength
acute_threatEinmalige bedrohliche Situation0.6–0.95
chronic_stressWiederkehrende Belastung über Zeit0.3–0.7 pro Instance, kumulativ hoch
positive_experienceFörderliche Erfahrung0.2–0.8
corrective_experienceMismatch für bestehende Wunde0.3–0.7
turning_pointNarrative-Verschiebender Moment0.7–1.0
reconsolidationExplizit therapeutisch modifiziertes EventN/A
routineAlltägliches Ereignis0.1–0.3

Imprint-Strength über Zeit

Imprint-Strength ist nicht statisch — sie verändert sich durch drei Mechanismen. Beim natürlichen Decay schwächt sich auch traumatisches Encoding ohne Reaktivierung allmählich ab (langsam bei imprint > 0.7). Verstärkung tritt auf, wenn wiederkehrende ähnliche Events die zugrundeliegende Struktur verfestigen. Und Reconsolidation reduziert imprint durch korrigierende Erfahrungen.

Diese Dynamik erklärt, warum manche Erinnerungen verblassen, andere lebenslang stark bleiben.

Event-Sourcing in der Speicher-Architektur

Dateistruktur pro Charakter:

kai-mueller/
├── profile.json                     # Stammdaten (ID, Name, Alter…)
├── events.jsonl                     # append-only, die Wahrheit
├── edges.json                       # typisierte Kanten (derives_from, protects…)
├── profile.derived.json             # COMPUTED: Aggregate, neu berechenbar
└── cache/
    └── vectors/                     # Cue-Signature-Embeddings

Rebuild-Regel: profile.derived.json wird nach jedem neuen Event oder Reconsolidation deterministisch neu berechnet. Das macht die Aggregate-Datei reproduzierbar und auditierbar.

Vorteile des Event-Sourcing-Paradigmas

1. Traceability

Für jeden aktuellen Wert kann rückwärts gezeigt werden, welche Events ihn produziert haben — mit welcher Gewichtung und durch welchen Mechanismus.

2. Was-wäre-wenn-Simulation

Durch hypothetisches Modifizieren von imprint_strength-Werten kann simuliert werden, wie sich der Charakter entwickeln würde.

3. Therapeutische Mechanik direkt abbildbar

Reconsolidation als zentraler Change-Mechanismus ist nativ im Datenmodell repräsentiert.

4. Ethische Robustheit

Die Ableitung ist transparent. Bei Coaching-Arbeit kann der Coach sehen, warum das System einen bestimmten Wert angibt — und widersprechen, wenn die Ableitung nicht passt.

5. Git-native Versionierung

Da Events JSONL-formatiert sind, ist die Event-Historie git-diffbar — Charakter-Evolution wird zu Commit-Historie.

Herausforderungen und Grenzen

Event-Auswahl

Welche Events sind relevant? Für einen tiefen Charakter braucht man wahrscheinlich 50–300 Events. Zu wenige = Aggregate sind spärlich belegt; zu viele = Aufwand explodiert.

Cue-Signature-Qualität

Die Kraft des Cue-Matchings hängt an der Qualität der Signaturen. Zu generisch → zu viele False-Positive-Matches; zu spezifisch → keine Matches.

Kulturelle Codierung

encoded_beliefs sind kulturell geprägt. Was ein deutsches Kind aus einer Situation lernt, unterscheidet sich von einem japanischen Kind. Das Schema erlaubt das, erfordert aber bewusste Charakter-Konstruktion.

Manuell kuratierbar vs. automatisch extrahiert

Im Storytelling-Modus werden Events typischerweise hand-kuratiert. Im Coaching-Modus könnten sie aus Gesprächs-Protokollen extrahiert werden (maschinell, mit ethischen Vorbehalten).

Belegbasis

Verknüpfungen

Charaktersystem:

Frameworks:

start call_