Selbstvektor — Das Grundproblem der emergenten Schicht

Konzeptpapier v0.3 / Denknotiz Emergenz / Holger Woelfle, 24.03.2026

1. Was wir haben: Der Kern (6 feste Achsen)

exploration tiefe autonomie persistenz abstraktion konfidenz 0.0 1.0 0.70 0.40 0.60 0.30 0.50 0.45 Zustand t = 4217 KERN — beschreibt WIE das System verarbeitet (universell, domaenenunabhaengig)
Status Der Kern ist definiert und funktional. 6 orthogonale Dimensionen, geprüft gegen Universalitaet, Orthogonalitaet und kausale Wirksamkeit. Das ist geloest.

2. Das Grundproblem: Was fehlt

PROBLEM: Zwei voellig verschiedene Situationen — identische Kernwerte Situation A: Debugging eines kritischen Produktionsfehlers exploration: 0.7 tiefe: 0.9 autonomie: 0.8 persistenz: 0.7 abstraktion: 0.3 konfidenz: 0.6 → "Ich kenne dieses Fehlermuster. Zuerst Logs pruefen." Gelernt aus: 47 aehnlichen Debugging-Sessions Situation B: Erster Kontakt mit unbekannter Domaene exploration: 0.7 tiefe: 0.9 autonomie: 0.8 persistenz: 0.7 abstraktion: 0.3 konfidenz: 0.6 → "Ich weiss nichts. Vorsichtig, breit abtasten." Keine Erfahrung — emergente Schicht leer = Der Kern allein kann kontextuelle Erfahrung nicht abbilden. Er beschreibt WIE verarbeitet wird — aber nicht, dass das System GELERNT hat, in Situation A anders zu handeln als in B. Was die emergente Schicht leisten muss: 1. Erkennen: "Diese Situation aehnelt Situationen, die ich kenne" 2. Modulieren: "In solchen Situationen verschiebe ich den Kern in DIESE Richtung" 3. Ohne Domaene: Nicht "das ist ein Bug" sondern "das ist ein Muster vom Typ X"
Kernproblem Ohne emergente Schicht ist der Selbstvektor ein statisches Temperament — es verarbeitet immer gleich, egal wie viel Erfahrung es hat. Das ist kein Selbst, das ist ein Profil.

3. Drei Optionen fuer das Format

Option A Benannte Dimensionen emergent = { vorsicht_bei_neuem: 0.8, muster_debugging: 0.6, user_X_praeferenz: 0.4 } + Interpretierbar + Debuggbar - Bricht Universalitaet (E1) - Wer benennt die Dimensionen? - Skaliert schlecht Option B Unbenannter Latenzraum emergent = [ 0.23, -0.71, 0.45, 0.88, -0.12, 0.33, ... // N floats ] + Universell + Skaliert - Black Box - Nicht interpretierbar - Wie entsteht ein neuer float? Option C (neu) Gelernte Kern-Modulationen emergent = [ {trigger: pattern_vec, shift: kern_delta_vec, weight: 0.73}, ... // N Modulationen ] + Universell (nur Muster, keine Domaene) + Interpretierbar (trigger → shift) + Verdichtbar (aehnliche fusionieren) ? Was ist "pattern_vec"? ? Wie wird Aehnlichkeit gemessen? Option C im Detail: Wie eine Modulation wirkt Neue Situation (als Kontext-Vektor) Trigger-Matching cos_sim(situation, trigger) > threshold Kern-Shift anwenden kern_aktuell += shift * weight Modulierter Kern Beispiel: Situation "aehnelt Debugging" → trigger matched → shift = {tiefe: +0.2, exploration: -0.1, persistenz: +0.15} → Kern wird temporaer moduliert: tiefer analysieren, weniger ausprobieren, laenger dranbleiben → Das System hat GELERNT, in Debugging-Situationen anders zu arbeiten — ohne "Debugging" als Konzept zu kennen → Die Modulation IST die Erfahrung. Nicht als Wissen, sondern als Verhaltensaenderung.

Warum A und B nicht reichen

  • Option A (benannt): Wer entscheidet, dass "vorsicht_bei_neuem" eine Dimension wird? Das System muesste seine eigene Ontologie bauen — das ist ein ungeloestes Problem.
  • Option B (Latenzraum): Pure Zahlen ohne Struktur. Das System kann nicht erklaeren, warum es anders handelt. Und: Wie entsteht ein neuer Float? Durch Training? Dann braucht es Gradienten — und wir sind zurueck bei Fine-Tuning.

Warum C vielversprechend ist

  • Emergenz ohne Ontologie: Keine neuen Begriffe noetig, nur Muster → Kern-Verschiebungen
  • Interpretierbar: Jede Modulation ist lesbar ("wenn X, dann verschiebe Kern um Y")
  • Verdichtbar: Aehnliche Trigger koennen fusionieren (= Generalisierung)
  • Universell: Pattern und Shift sind domaenenunabhaengig
  • Analogie Mensch: "In solchen Situationen bin ich vorsichtiger" — ohne die Situation benennen zu koennen

4. Was noch zu loesen ist (Option C)

Offene Frage 1 Was ist der "trigger" / pattern_vec?
Ein Embedding der Situation? Ein Hash der letzten N Interaktionen? Ein reduzierter Kontext-Vektor? Der Trigger muss schnell matchbar sein UND genuegend Information tragen, um sinnvoll zu diskriminieren.
Offene Frage 2 Wie entsteht eine neue Modulation?
Vorschlag: Wenn der Reflexionsmechanismus (Schicht 3) erkennt, dass der Kern in einem bestimmten Kontext wiederholt in dieselbe Richtung verschoben wurde — dann wird dieses Muster als neue Modulation kristallisiert. Schwellenwert: Mindestens N Wiederholungen mit aehnlichem Shift-Vektor.
Offene Frage 3 Obergrenze und Verdichtung?
Wenn zwei Modulationen aehnliche Trigger UND aehnliche Shifts haben → fusionieren (gewichteter Durchschnitt). Das begrenzt das Wachstum natuerlich. Maximale Anzahl koennte analog zur "Dunbar-Zahl" gewaehlt werden — wie viele distinkte Verhaltensmuster braucht ein System realistisch?
Offene Frage 4 Temporaler Verfall?
Modulationen die lange nicht getriggert wurden — verblassen sie? Oder bleiben sie? Menschliche Analogie: Alte Gewohnheiten koennen nach Jahren reaktiviert werden, sind aber weniger dominant. Moeglicher Mechanismus: weight *= decay_factor pro Reflexionszyklus, aber nie auf 0.
Einsicht Option C macht die emergente Schicht zu einem Satz gelernter Kontextmodulationen auf den Kern — keine eigenen Dimensionen, sondern Regeln, die den Kern situationsabhaengig verschieben. Das Selbst "weiss" nichts Neues — es verhält sich anders. Genau wie beim Menschen: Erfahrung veraendert nicht das Temperament, sondern die situative Anpassung des Temperaments.

5. Offene Frage 4 geloest: Autonome Relevanz-Rebalancierung

Ausgangsproblem Qualia nutzt exponentiellen Decay mit 90-Tage-Halbwertszeit (memclawz.py Z.299). Nach ~300 Tagen faellt ein Chunk unter den Score-Floor (0.1) und verschwindet aus Suchergebnissen. Das ist blind: Unternehmenswissen stirbt genauso wie ein Recherche-Zwischenergebnis.
Verworfener Ansatz: Klassifikation Erster Instinkt: Chunks als "ephemer" oder "persistent" klassifizieren. Verworfen — Henne-Ei-Problem. Relevanz ist nicht statisch. Sie entsteht rueckwirkend durch neuen Kontext. Ein beilaeufig erwahnter Name wird 8 Monate spaeter zum Schluessel-Stakeholder. Das kann niemand vorhersagen — weder Mensch noch System.
Verworfener Ansatz: Human-in-the-Loop Zweiter Instinkt: System gibt Hints, Mensch entscheidet. Verworfen — die Entscheidung "ist das noch relevant?" ist hier nicht semantisch sondern statistisch. Wenn neue Daten im selben Kontext-Cluster auftauchen, IST das der Beweis der Relevanz. Der Mensch ist ein Flaschenhals der nicht sein muss.

Die Loesung: Gravitation statt Klassifikation

Autonome Relevanz-Rebalancierung Neue Daten ziehen altes Wissen zurueck — wie Gravitation 1. Staging Area Neue Chunks landen im Zwischenspeicher statt direkt im aktiven Index. Trigger: N Chunks ODER T Zeiteinheiten erreicht 2. Sub-Agent Analyse Berechnet Centroid (Schwerpunkt) aller neuen Chunks im Embedding-Raum. centroid = mean( [c.embedding for c in new]) 3. Kalt-Speicher-Scan Suche im Kalt-Speicher: Welche alten Chunks liegen nahe am neuen Centroid? cos_sim(centroid, old_chunk.embedding) 4. Gravitationsfeld — Dichte entscheidet Neue Chunks (Centroid) kalt, 247 Tage REAKTIVIERT kalt, 180 Tage zu weit → bleibt kalt Neue Chunks Aktive Chunks Kalte Chunks Regel: Dichte(neue + kalte Chunks im Radius) > Schwellenwert → Reaktivierung 5. Adaptiver Schwellenwert (Aktivierungsenergie) Je laenger ein Chunk kalt war, desto staerker muss der neue Kontext-Cluster sein: threshold(chunk) = base_threshold * (1 + log(age_days / 90)) → 90 Tage: threshold = base * 1.0 | 365 Tage: base * 2.4 | 730 Tage: base * 3.1 — nie unerreichbar, aber zunehmend schwerer

Warum das funktioniert

  • Kein Mensch noetig: Die Entscheidung ist statistisch (Cluster-Dichte), nicht semantisch ("ist das wichtig?")
  • Anhaeufiung neuer Daten IST der Beweis: 5 neue Chunks zu "Stakeholder X" + 1 alter Chunk zu "Stakeholder X" = der alte Chunk ist relevant
  • Keine Vorhersage noetig: Das System muss nicht wissen, was spaeter wichtig wird — es reagiert auf Veraenderung im Jetzt
  • Natuerliche Verdichtung: Irrelevantes wird nie reaktiviert, weil nie neue Daten in der Naehe auftauchen

Verbindung zum Selbstvektor

  • Context Fingerprint = Vorlaeufer des Selbstvektors — beschreibt worauf das System fokussiert ist
  • Delta Detection = Schicht 3 (Reflexion) — erkennt: "Etwas hat sich veraendert"
  • Reaktivierung = Schicht 2 (Gewichtung) — aendert, was als relevant gilt
  • Adaptiver Schwellenwert = Meta-Schicht (Stabilitaet) — kontrolliert die Aenderungsresistenz

Umsetzungsplan (konkret, 4-5 Stunden)

1 context_fingerprint() FactsDB + BrainDB → Embed ~1h 2 Staging Area Puffer in memclawz.py ~30m 3 Centroid + Delta Batch-Centroid berechnen ~30m 4 cold_scan() vec_chunks Kalt-Suche ~1h 5 Adaptiver Threshold + Audit-Log ~30m 6 Test + Validierung Echte Daten, alter Chunk ~1h reactivation.py memclawz.py reactivation.py memclawz.py config.py test_reactivation.py Gesamt: ~4-5 Stunden | Keine Schema-Aenderung | Kein HITL
Kerneinsicht dieser Session Relevanz ist nicht vorhersagbar — aber ihre Rueckkehr ist messbar. Statt zu entscheiden was wichtig bleiben soll (unmoeglich), reagiert das System auf Verdichtung: Wenn neue Daten in der Naehe alter Daten auftauchen, wird das alte Wissen reaktiviert. Nicht weil jemand entschieden hat dass es wichtig ist, sondern weil die Datenlandschaft es beweist. Das ist die Bruecke zwischen Temporal Decay und dem Selbstvektor: Das System lernt nicht WAS relevant ist, sondern WANN sich die Relevanzlandschaft verschoben hat.

6. Erweiterung: Lokales LLM als Metakognitionsschicht

Kernidee (25.03.2026) Das System aus Phase 1-5 (Reactivation by Context Change) ist rein statistisch — es findet und reaktiviert, aber es versteht nicht. Ein lokales LLM (z.B. Mistral 7B, Llama 3 via Ollama) als RAG-Agent auf dem Gesamtkorpus schliesst diese Luecke. Kein Fine-Tuning, kein Retraining — das LLM liest den Chunk-Store wie ein Analyst eine Datenbank.

4-Phasen-Roadmap zum selbstverbessernden System

Phase 1: Reactivation (JETZT)

Staging Area → Centroid → Cold Scan → Gravitationsfeld → Adaptiver Threshold. Rein statistisch, kein LLM noetig. ~4-5h Implementierung.

Phase 2: Validation Gate

Lokales LLM prueft reaktivierte Chunks: Widerspricht der alte Chunk aktuellem Wissen? Contradiction Score + Erklaerung. Erste LLM-Integration.

Phase 3: Context Synthesis

LLM erstellt Meta-Chunks: "A (2024) relevant fuer B (2026), weil Stakeholder X seine Rolle gewechselt hat." Implizites Wissen wird explizit.

Phase 4: Self-Improvement Loop

Periodische Selbst-Analyse: Wo sind Luecken? Welche Quellen widersprechen sich? Priorisierte Recherche-Vorschlaege. Das System verbessert sich selbst.

Architektur-Prinzip Jede Phase nutzt die vorherige als Input. Das LLM bleibt austauschbar (kein Fine-Tuning → kein Lock-in). Wissen bleibt im Chunk-Store, Intelligenz kommt aus der Kombination. Der "Super-Agent" ist kein einzelnes Modell, sondern das Zusammenspiel von statistischem Retrieval (Phase 1) + LLM-Metakognition (Phase 2-4).
Detaillierte Visualisierung Architektur-Vergleich (Heute vs. Phase 4) und vollstaendige Roadmap: evolution-heute-vs-phase4.html

Parallelpfad: Phase C — Coach Pattern Mining

Erweiterung (25.03.2026) Das lokale LLM aus Phase 2 eroeffnet einen Parallelpfad: Maschinelles Lernen auf Coach-Daten. Der Coach akkumuliert seit Wochen Tagesprotokolle (geplant vs. tatsaechlich), Session-Logs (~1500 BrainDB-Eintraege), Feedback-Regeln und BUGLIST-Eintraege. Ein wöchentlicher Batch-Lauf des lokalen LLM auf diesen Daten ermoeglicht:

Was Phase C kann

  • Cross-Session Pattern Mining: "4/5 Wochen JF-Prep auf letzten Tag geschoben, 3x wegen LinkedIn"
  • Energie-Korrelation: "Sessions nach 22:00 = 2x mehr Themenwechsel, Hyperfokus → Crash am Folgetag"
  • Interventions-Wirksamkeit: "'Du verzettelst dich' → 60% Kurskorrektur. 'Korb 3' → 0% Wirkung"
  • Praediktive Warnungen: "JF + Viralphase + Privat-Fristen = Verzetteln-Risiko HOCH"

Warum das ML ist

  • Datenbasis: BrainDB-Logs + Tagesprotokolle
  • Extraktionsmaschine: Lokales LLM (RAG auf Coach-Daten)
  • Vorhersage: Praediktive Warnungen fuer naechste Woche
  • Loss-Funktion: Vorhersage vs. tatsaechliches Verhalten
  • Feedback-Loop: Naechster Batch beruecksichtigt Ergebnis → Muster verfeinern
  • Verbindung zum Selbstvektor: Die erkannten Muster sind funktional identisch mit emergenten Kontextmodulationen — gelernte Verhaltensanpassungen auf Basis akkumulierter Erfahrung. Phase C ist der Proof-of-Concept fuer die emergente Schicht.

7. Design Pattern: Proaktives Kontextmanagement

Generalisierte Erkenntnis (25.03.2026) Reactivation by Context Change ist reaktiv — es repariert, nachdem Wissen im Cold Storage gelandet ist. Aber es gibt einen komplementaeren Mechanismus: Proaktive Kontexttrennung, die verhindert, dass Wissensqualitaet ueberhaupt degradiert. Das Grundprinzip: Erkenne Drift → Trenne sauber → Stelle Kontext in isolierten Straengen wieder her.

Drei Auspraegungen desselben Prinzips

Kontextmanagement-Spektrum: Strukturell → Proaktiv → Reaktiv Strukturell Scope Separation Wann: Von Anfang an Wie: Harte Datenwände Wo heute: Privat / SOS / Coach Generalisierbar auf: • Mandanten-Trennung (Kanzlei) • Abteilungs-Silos (Enterprise) • Compliance-Domains (Legal) • Multi-Projekt-Isolation Kosten: Gering (einmalig) Effekt: Verhindert Kontamination Proaktiv Context Split (Handoff) Wann: Bei erkanntem Drift Wie: Checkpoint + Split + Restart Wo heute: Chat-Sessions (ADHS) Generalisierbar auf: • Meeting-Protokolle (Themen-Split) • Recherche-Straenge (Branching) • Ticket-Triage (Auto-Routing) • Wissens-Curation (Topic Streams) Kosten: Mittel (Erkennung noetig) Effekt: Erhaelt Kontextqualitaet Reaktiv Reactivation by Context Change Wann: Nachdem Wissen kalt wurde Wie: Centroid-Matching + Gravitation Wo heute: 90-Tage Temporal Decay Generalisierbar auf: • CRM-Kontakthistorie • Forschungs-Literatur (Zitationsgraph) • Organisationswissen (Lessons Learned) • Gesetzesaenderungen (Impact Analysis) Kosten: Hoeher (Cold Scan noetig) Effekt: Wiederfinden trotz Verfall
Schluessel-Einsicht Die drei Mechanismen sind keine Alternativen — sie bilden eine Verteidigungskette. Strukturelle Trennung verhindert Vermischung. Proaktiver Split erhaelt Fokusqualitaet innerhalb eines Scopes. Reaktive Reactivation rettet Wissen, das trotzdem durchs Netz gefallen ist. Ein robustes Wissenssystem braucht alle drei Schichten.

Handoff-Muster: Abstrakt

Das Pattern

  1. Detect: Erkennung dass ein Strang sich aufspaltet (Drift-Signal)
  2. Checkpoint: Aktuellen Zustand beider Straenge persistent speichern
  3. Split: Zwei unabhaengige Kontexte erzeugen mit je eigenem Scope
  4. Inject: Beim Start jedes neuen Strangs den gespeicherten Kontext injizieren
  5. Archive: Handoff-Artefakte nach Injection archivieren

Anwendungsfelder

  • Chat-Sessions: ADHS-bewusste Themenisolation (implementiert)
  • Meeting-KI: Erkennt Themen-Branches → separate Protokoll-Straenge
  • Support-Systeme: Ticket beginnt als X, wird zu Y → Auto-Split + Routing
  • Recherche-Agenten: Nebenfund ergibt eigene Spur → Forking
  • Wissensmanagement: Dokument waechst → automatische Dekomposition in fokussierte Einheiten
Verbindung zu Phase C (Coach Pattern Mining) Phase C kann das Handoff-System trainieren: Die Drift-Erkennung startet regelbasiert (3+ Themenwechsel), aber mit akkumulierten Coach-Daten kann das lokale LLM lernen, welche Drift-Muster bei Holger tatsaechlich zu Qualitaetsverlust fuehren und welche produktive Assoziationen sind. Das ist ein konkretes Beispiel fuer den Uebergang von Stufe 1 (Regeln) zu Stufe 2 (gelerntes Verhalten).
Vollstaendige Visualisierung Drei Stufen + Phase C: evolution-komplett-drei-stufen.html | Coach-Architektur: coach-architektur.html
Selbstvektor Konzeptpapier v0.4 — Denknotiz emergente Schicht + Reactivation + LLM-Roadmap + Coach ML + Proaktives Kontextmanagement — Holger Woelfle — 25.03.2026