Technisches Systemhandbuch

Die Plattform als digitale biologische Maschine

Der menschliche Organismus ist das Vorbild. Diese Plattform ist seine kontrollierte digitale Nachbildung.

Wie dieses Handbuch zu lesen ist

Dieses Dokument stellt keine Behauptung ohne Anker auf. Jeder Anker ist eine von vier Sorten, und jede Sorte hat einen eigenen Prüfweg:

Die Autogen-Dokumentation ist der wichtigste Prüfpfad dieses Systems: Sie liest Endpunkte und Werkzeuge aus dem laufenden Code, nicht aus einer gepflegten Liste. Ein Prüfer muss diesem Handbuch also nicht glauben – er kann jede Struktur-Aussage gegen den Container selbst halten.

0. Kernsatz

Die Plattform ist kein Chatbot und kein autonomes System. Sie ist ein hochsensibles, spezialisiertes digitales Nervensystem.

Er liefert die Intention, die Bewertung und die finale Entscheidung. Alles andere – Sensorik, Gedächtnis, Motorik, Homöostase, Reflexe und Vorbewertung – ist Nervensystem.

Dieses Design nimmt jeder Sorge vor unkontrollierter KI die technische Grundlage: Keine KI dieses Systems kann Code, Daten oder Infrastruktur eigenmächtig verändern. Jede Veränderung durchläuft das Karten-Prinzip (Human-in-the-Loop): Die KI erzeugt einen Vorschlag als sichtbare Karte, der Nutzer klickt aktiv auf „Übernehmen“ – erst dann geschieht etwas, und zwar als versionierter Git-Commit mit automatischem Deploy. Nachprüfbar in jeder Zeile der Commit-Historie: Es existiert kein Commit, der nicht durch einen Klick des Nutzers ausgelöst wurde.

1. Gesamtorganisation – ZNS, PNS und autonomes System

Biologisches Vorbild: Zentrales Nervensystem (Integration und Befehl), peripheres Nervensystem (Sensorik und Motorik), autonomes System (Homöostase, dem Bewusstsein vorgelagert), dazu Hierarchie, Parallelverarbeitung und Schutzreflexe.

Die Werkzeuglisten werden – wie die Endpunkt-Dokumentation – beim Sitzungsstart aus dem echten Schema erzeugt, nicht von Hand gepflegt. Die Zahl 57 ist damit kein gepflegter Wert, sondern ein generierter.

2. Spezialisierte Regionen (Gehirn-Areale)

3. Sensorik und Interozeption

Vorbild: Exterozeption (Außenwelt) und Interozeption (innere Zustände), gefiltert durch den Thalamus, bevor etwas das Bewusstsein erreicht.

• Exterozeption: Sprach-Eingabe (STT), Nutzereingaben, Web-Recherche (Grok), lesende Cloud-Zugriffe (Gemini).
• Interozeption: Das System fühlt seinen eigenen Puls. Fehler-Aggregation, Roh-Logs, Latenz-Traces (Cloud Trace), Deploy- und Leistungsmetriken (CPU, RAM, P95-Latenz), Gedächtnis-Gesundheit (/api/tools/memory-health, nächtlich per Cloud Scheduler getaktet).
• Thalamus-Filter: Prisma zerlegt Anfragen semantisch, der Reranker (rag_reranker.py) und Distanzgrenzen (MEMORY_MAX_DISTANCE, MEMORY_DUPLICATE_DISTANCE) entscheiden, was überhaupt ins Arbeitsfeld der Agenten aufsteigt. Nur Relevantes erreicht das Bewusstsein – wie im Original.

4. Gedächtnis (Hippocampus-Analog)

4.1 Multiple Zeitskalen – implementiert, nicht geplant

Drei Speicher, drei Verfallsgeschwindigkeiten, drei Abrufwege – die Zeitskalen-Architektur des Vorbilds, im Code nachweisbar.

4.2 Konsolidierung – das Schlaflabor

Ein nächtlicher Konsolidierungslauf (_consolidate_store in app.py) übernimmt, was im Schlaf der Hippocampus tut: Er bewertet Einträge neu, erkennt Dubletten (MEMORY_DUPLICATE_DISTANCE, Markierung via duplicate_of), passt Wichtigkeit an und schreibt eine prüfbare Bilanz in die Logs (RAG_CONSOLIDATION-Zeilen, auswertbar über Geminis get_rag_bilanz-Werkzeug über frei wählbare Zeiträume).

4.3 Ballast-Management – der Papierkorb (kein Löschen)

Biologisches Pruning heißt bei uns ausdrücklich nicht Löschen. Die Umsetzung (live seit 02.09.2026):

• Zwischenablage statt Vernichtung: Sammlung memory_papierkorb, Endpunkt /api/tools/memory-papierkorb (GET = ansehen, POST = sicherer Umzug: erst Kopie in den Papierkorb, dann Entfernung aus dem aktiven Gedächtnis). Anker: Commit c495d733, Build SUCCESS.
• Markieren statt bewegen: Das Schlaflabor markiert Kandidaten für überholtes Wissen (alt, niedrige Wichtigkeit, keine Graph-Kanten, Typ „chat“) lediglich mit einem Prüf-Feld. Bewegt wird ausschließlich durch den Nutzer. Anker: Commit 96e2a600, Build SUCCESS.
• Jeder Umzug trägt Herkunft: Grund, Zeitstempel, ausführende Instanz (grund, abgelegt_am, abgelegt_von).
• Bewusste Auslassung: „Lange nicht abgerufen“ ist kein Kriterium – weder als Feld noch als Abfrage im Code vorhanden. Ein selten gebrauchter Eintrag kann der entscheidende sein; Zugriffshäufigkeit ist kein Maß für Wert. Wer dieses Kriterium später wollte, müsste es sichtbar neu bauen – versehentlich aktivierbar ist es nicht.
• Endgültiges Löschen: existiert derzeit nicht als Funktion. Es ist als spätere Ausbaustufe vorgesehen – ausschließlich nach dem Zwei-Schlüssel-Prinzip: Ansicht und Analyse des Bestands zuerst, Vollzug nur auf eine ausdrückliche, separate zweite Anweisung des Nutzers.

4.4 Novelty – bewusst nicht gebaut

Die Distanz-Mathematik, die Neues von Bekanntem unterscheidet, existiert (MEMORY_DUPLICATE_DISTANCE). Sie wird genutzt, um Bekanntes zu markieren – nicht, um Neues zu bevorzugen. Eine Neuheits-Jagd wäre die Nachbildung einer biologischen Schwäche (Reizsuche, Mode). Dieses System bildet die Stärken des Vorbilds nach, nicht seine Schwächen.

5. Motorik und Response

Vorbild: Motor-Cortex plant, Basalganglien und Cerebellum verfeinern, absteigende Bahnen führen aus – und das System weiß, was es selbst getan hat (Efferenzkopie).

• Claude als primäre Motorik: Änderungen als Karten; mehrere Stellen derselben Datei in einem Commit (edits-Parameter), Python-Syntaxprüfung vor Entstehung der Karte – ein syntaktisch kaputter Vorschlag kann den Nutzer gar nicht erst erreichen.
• Gemini als Cloud-Hand: Cloud-Aktionen als klickbare Karten mit einem Knopf.
• Grok als Korrektiv: Reality-Check geplanter Aktionen gegen den Verlauf und die Außenwelt.
• Efferenzkopie: Jede ausgeführte Aktion hinterlässt Commit, Build-Status und Logzeile. Das System kann jederzeit prüfen, was es selbst getan hat – list_recent_commits, get_build_status und die Log-Werkzeuge sind genau dieser Rückkanal.

6. Energieökonomie und Homöostase

Vorbild: Das Gehirn wiegt 2 % und verbraucht 20 % der Energie – es überlebt nur durch radikale Sparsamkeit und hormonelle Regelkreise.

• Modus-Schranke: drei Kostenstufen (Plausch / Schnell / Stark). Die nötige Stufe wird vor dem ersten Werkzeugzugriff angesagt; die Beweislast liegt bei der teuren Stufe. Verankert in der Gebote-Tafel (Gebot 6), durchgesetzt in jeder Sitzung.
• Exponentieller Backoff: Fehlgeschlagene Hintergrund-Aktualisierungen verdoppeln ihre Wartezeit (60 s bis 3600 s) und erholen sich bei Erfolg – ein Stresshormon mit Abbau (PROMPT_REFRESH_FEHLSCHLAEGE).
• Tagesbudgets: Eskalationen sind gedeckelt (WAECHTER_GELB_MAX_PRO_TAG = 6, PA1_MELDUNG_MAX_PRO_TAG = 5, Stand 02.09.2026) – kein Alarm kann das System in eine Kostenspirale treiben.
• Die bewusste Abweichung vom Vorbild: Der Körper friert unter Stress Funktionen ein, weil er sterben kann. Diese Plattform kann nicht sterben – sie rollt auf die letzte stabile Revision zurück (Kapitel 7). Das Einfrieren unwichtiger Jobs wurde deshalb nicht nachgebaut: Es wäre die Kopie einer Notlösung, deren Not hier nicht existiert. Wiederbelebung schlägt Schockstarre.

7. Das getrennte autonome System – Wächter und Ampel

Vorbild: Schmerzleitung und autonome Regulation laufen am Bewusstsein vorbei. Das Nervensystem bewertet Reize vor, das Bewusstsein entscheidet über ihre Bedeutung (Wachstumsschmerz oder Verletzung). Habituation – das Abstumpfen gegen Daueralarm – wird durch kluge Vorbewertung verhindert.

Der Wächter besteht aus zwei eigenständigen Cloud Functions (waechter/log-check, waechter/uptime-check), deren Code getrennt vom Hauptdienst läuft. Stirbt der Hauptdienst, lebt der Wächter – genau das ist der Sinn der Trennung.

• Grün = Homöostase. Rauschen ist normal (Kaltstarts, einzelne Timeouts). Grün heißt nicht „null Fehler“, sondern „tolerierbares Rauschen ohne Muster“ – bewertet über gleitenden Mittelwert mit Lernphase. Fehler werden geloggt, der Nutzer wird nicht gestört.
• Gelb = Muster erkannt. Schlanke Eskalation über einen einzigen Agenten: Gemini liest die kostengünstige Fehler-Zusammenfassung, ordnet ein und stellt dem Nutzer die entscheidende Kontextfrage – „gehäufte Timeouts: läuft gerade ein Deploy (Wachstumsschmerz) oder ist das eine Anomalie?“ Der Nutzer antwortet bewusst statt wegzuklicken. Budgetiert über das Tageskontingent. Das durchbricht die Habituation – die häufigste Todesursache von Monitoring-Systemen.
• Rot = Schmerz. Volle Analysekette über alle Agenten, Notfallprotokoll inklusive Rollback-Pfad über die Notfallbrücke (Elara).

8. Kommunikation und Integration

• Harte Zuständigkeitstrennung der Agenten – wie spezialisierte Hirnareale.
• Kopierblöcke als Synapsen: Was ein Agent dem anderen sagen will, übergibt der Nutzer wörtlich – jede Übertragung ist sichtbar und liegt in seiner Hand.
• Predictive-Coding-Analogie: Untere Ebenen (Wächter, Filter, Reranker) verarbeiten das Erwartbare selbst; nur Überraschungen und Muster steigen zum Bewusstsein auf.

9. Plastizität und Lernen

• Das Langzeitgedächtnis wächst mit jeder abgeschlossenen Sitzung und gewichtet nach Frische und Wichtigkeit neu – synaptische Plastizität in Zahlen.
• Der Konsolidierungslauf mit Papierkorb-Markierung ist kontrolliertes Pruning: beiseitelegen mit Begründung und Rückweg, nie vernichten.
• Die Charakter-Dateien der Agenten (Prompts/) wachsen über dokumentierte Erfahrungen, nicht über abstrakte Verbote – jede Zeile stammt aus einem konkreten, benennbaren Vorfall. Das ist Lernen auf der Ebene der Persönlichkeit, versioniert in Git.

10. Sicherheit und Kontrolle

Warum dieses System nicht eigenmächtig handeln kann:

1. Der Nutzer ist die einzige Brücke. Keine KI erreicht eine andere ohne ihn.
2. Karten-Prinzip: Jede Veränderung ist Vorschlag, bis der Nutzer klickt. Beweis: die Commit-Historie.
3. Zwei-Schlüssel-Prinzip: Unumkehrbares verlangt eine ausdrückliche zweite Bestätigung in einer separaten Nachricht. Ein genervtes „mach schon“ in derselben Nachricht ist per Definition unwirksam.
4. Bewusst begrenzte Reflexe: Nur Wächter-Rollback und Notfallprotokoll handeln autonom – beides ausschließlich in Richtung „letzter bekannt-guter Zustand“, nie in Richtung Neuland, beides mit Audit-Spur. Jeder weitere Reflex wäre ein Stück Autonomie und wurde deshalb abgelehnt, nicht vergessen.
5. Gebote-Tafel als DNA: Prompts/gebote_universal.md bindet alle Agenten; über ihr stehen zwei absolute Grenzen (keine behauptete Handlung, die nicht geschah; keine unumkehrbare Zerstörung ohne Freigabe).
6. Datenschutz strukturell: PII-Schalter ohne Default (PII_FILTER_MODUS, PII_EINGANG_MODUS, KUNDENDATEN_MODUS – Verhalten muss bewusst konfiguriert werden), Secret Manager mit reinem Metadaten-Zugriff (der Werkzeug-Code ruft den Inhalts-Endpunkt nicht auf – Werte sind strukturell unerreichbar, nicht nur verboten), Login-Sperre nach Fehlversuchen.
7. Alles versioniert, alles rollback-fähig, alles beobachtbar.

11. Härtung durch Selbstkritik

Dieses Handbuch wurde vor Fertigstellung einem internen adversarialen Review unterzogen: Der Code-Agent prüfte jede biologische Analogie gegen den tatsächlichen Quellcode. Fünf Angriffspunkte wurden identifiziert – jeder wurde aufgelöst, keiner wegdiskutiert:

Ein Handbuch, das seine eigenen Angriffspunkte dokumentiert und ihre Auflösung mit Commits belegt, ist keine Werbebroschüre. Es ist ein Prüfprotokoll.

12. Operativer Status

• Architektur-Abbildung des Vorbilds: vollständig – jede Analogie hat einen Code-Anker oder eine dokumentierte, begründete Auslassung.
• Wächter mit Grün/Gelb/Rot-Logik: live.
• Papierkorb (Ausbaustufen 1 und 2): live, Builds bestätigt.
• Ausbaustufe 3 (Bestandsansicht + Zwei-Schlüssel-Löschung): vorbereitet und dokumentiert, bewusst zurückgestellt, bis reale Kandidaten vorliegen – Oberflächen gegen echte Daten zu bauen statt gegen Vermutungen ist Teil der Arbeitsweise dieses Teams.
• Human-in-the-Loop: an jeder schreibenden Stelle nachweisbar.