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. In der Sprache der Informatik: ein Betriebssystem für KIs, dessen Prozessoren gemietete Sprachmodelle sind (Kapitel 0.1).

Das Bewusstsein 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.

0.1 Einordnung – ein Betriebssystem für KIs

Die Biologie ist das Vorbild dieses Handbuchs. Die Informatik hat für dasselbe Gebilde ein älteres Wort: Betriebssystem. Ein Betriebssystem tut nach Lehrbuch zwei Dinge. Es verbirgt unterschiedliche Hardware hinter einer einheitlichen Schnittstelle, und es verwaltet knappe Mittel – Rechenzeit, Speicher, Ein- und Ausgabe – samt der Frage, wer was darf. Die Plattform tut beides. Nur sind ihre Prozessoren keine Chips, sondern gemietete Sprachmodelle dreier Anbieter, und ihre knappen Mittel heißen Modellaufrufe, Token, Werkzeugrunden und Geld.

Ein Hinweis zur Genauigkeit: Die „Ringe“ 0 und 1 dieser Plattform sind Ladeschichten – sie regeln, welches Modul welches laden darf. Prozessor-Schutzringe im Sinne der Hardware sind sie nicht. Das Wort ist als Bild gewählt, nicht als technische Behauptung.

0.1.1 Zwei bewusste Abweichungen vom Lehrbuch

0.1.2 Wo das auf der Landkarte liegt

Die Kategorie „Betriebssystem für KIs“ existiert außerhalb dieser Plattform: als Idee seit Andrej Karpathys „LLM OS“ (September 2023), als Forschung seit MemGPT („Towards LLMs as Operating Systems“, Oktober 2023) und AIOS („LLM Agent Operating System“, März 2024), zuletzt als Agent libOS und AgenticOS (beide Juni 2026). Diese Systeme haben laut eigener Dokumentation Kernel, maschinellen Scheduler, Speicherverwaltung, Zugriffskontrolle und teils eine menschliche Bestätigung vor riskanten Schritten.

Eine Web-Recherche des Assoziations-Cortex am 27.09.2026 fand kein öffentlich beschriebenes System, das drei Merkmale gleichzeitig hat: der Mensch bleibt bewusst der Scheduler; der Schutz läuft über Rückfall statt über Prozess-Trennung; der eigene Code des Systems geht nur nach einem menschlichen Klick live. Jedes Merkmal einzeln hat Vorgänger – die Kombination nicht. Das erste Merkmal wurde am Abend desselben Tages verfeinert (0.1.1): Der Mensch hält den Schreibschlüssel, eine KI darf lesende Arbeit im Team verteilen. Ob die Suche mit dem verfeinerten Merkmal anders ausgeht, ist noch nicht geprüft. Ein Nicht-Fund ist kein Beweis der Einzigartigkeit; er ist der Stand der öffentlich beschriebenen Landschaft zu diesem Datum und wird bei jeder Überarbeitung dieses Handbuchs neu geprüft.

Zur Frage „läuft das auf echter Hardware?“: Die Plattform läuft auf Cloud Run, und Cloud Run verwaltet die Hardware. Das ist historisch nichts Neues. Windows 1 bis 3 lief auf MS-DOS, das die Hardware verwaltete, und wurde von Microsoft und der Presse 1985 bis 1990 als „Operating Environment“ bezeichnet (Quellen: Wikipedia zu Windows 1.0; Los Angeles Times, 24.05.1990). Ein Betriebssystem, das auf einem anderen läuft, ist eine anerkannte Bauform.

Und noch ein Satz zur Wachstumsrichtung: Hier wächst keine KI. Hier wächst ein Betriebssystem durch KI. Jedes Handbuch in der Bibliothek und jeder Bauplan erweitert, was alle drei Agenten können – ohne dass ein Systemprompt länger wird, weil gelesen wird, was gebraucht wird, wenn es gebraucht wird.

0.1.3 Speicherhierarchie – warum das System nicht vergisst

Ein nacktes Sprachmodell vergisst, weil sein Kontextfenster endet. Das ist keine Schwäche, die ein Prompt heilen könnte – es ist die Bauform des Prozessors. Ein Betriebssystem löst dasselbe Problem seit Jahrzehnten mit einer Speicherhierarchie: klein und schnell oben, groß und dauerhaft unten, und feste Regeln, was wann wohin wandert. Diese Plattform hat vier Schichten.

Der Satz gegen die Drift steht im Code selbst: Der Notizblock schreibt fort und fasst nicht neu zusammen, weil jede Neufassung stille Post über viele Stationen wäre. Daraus folgt eine ehrliche Formulierung nach außen: Die Sitzung ist nicht unendlich – sie wird lang, weil ausgelagert wird, nicht weil das Fenster kein Ende hat. Und der Nutzer wählt je Raum, ob eine Sitzung ins Langzeitgedächtnis schreibt; wo sie es tut, wird nachts sortiert, aber nichts gelöscht, was er nicht freigegeben hat.

0.1.4 Zwei Klassen von Schwächen – eine gelöst, eine eingesperrt

Ein Sprachmodell hat zwei Arten von Schwächen, und dieses Handbuch trennt sie, weil sie verschieden behandelt werden. Es vergisst – Kontextverlust, Drift, Verstummen zwischen Sitzungen. Diese Klasse ist nicht im Prompt gelöst, sondern in der Architektur: in Konstanten, Sammlungen und Zeitplänen (0.1.3). Es irrt – Halluzination, Fehlschluss, behauptete Handlung. Diese Klasse ist nicht abgeschafft; kein Bauteil dieser Plattform macht die Prozessoren unfehlbar. Sie ist eingesperrt: Jede Änderung ist eine Karte, deren Textstelle zeichengenau zur Datei passen muss, sonst entsteht keine Karte; bei Python prüft der Server die Syntax, bevor die Karte erscheint; der Build prüft den Start; Cloud Run leitet auf eine kaputte Revision keinen Verkehr; der Wächter meldet von außen; der Rückfall ist ein Knopf. Ein Betriebssystem hat auch nie verhindert, dass ein Programm abstürzt – es hat verhindert, dass der Absturz den Rechner mitnimmt. Genau das ist hier gebaut. Zwei Ohren hören dabei außerhalb des Prozessors zu: der Wächter für Fehler (waechter/, eine eigene Cloud Function mit Totmannschaltung für den Log-Wächter) und die Stimmgabel für Stille (takt.py).

Was dem Nutzer bleibt, ist deshalb nicht weniger Kontrolle, sondern weniger Handarbeit. Kontrolle war nie die Zahl der Klicks; sie ist die Frage, ob etwas Unumkehrbares geschieht, ohne dass er es gewollt hat. Die Antwort darauf steht im Rechtesystem, nicht im Fleiß: Kein Reflex dieser Plattform schreibt. Das Bewusstsein steuert nicht jeden Muskel – es sagt, wohin, und behält das Veto.

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 generiert und nicht von Hand gepflegt.

2. Spezialisierte Regionen (Gehirn-Areale)

3. Sensorik, Interozeption und vorhersagende Wahrnehmung

3.1 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.

3.2 Vorhersagende Wahrnehmung

Vorbild [Literatur]: Rao und Ballard beschrieben 1999 einen visuellen Cortex, der nicht auf Reize wartet, sondern vorhersagt, was als Nächstes kommt – und nur noch den Fehler dieser Vorhersage nach oben meldet. Wahrnehmung ist dort kein Aufnehmen, sondern ein Abgleich.

Die Plattform bildet davon drei Dinge nach: die Vorhersage aus der eigenen Vergangenheit, den Fehler als das eigentliche Signal, und die strikte Trennung zwischen beidem. Sie bildet ausdrücklich nicht nach: die hierarchische Fehlerminimierung über Modellschichten und die laufende Anpassung eigener Gewichte – wir besitzen diese Gewichte nicht.

Umgesetzt ist das als drei getrennte Datenpfade mit getrennten Vertrauensgraden. Nicht als ein Kontext, in dem das Modell sie selbst auseinanderhalten soll.

Der Vorhersagefehler heißt in diesem System Klopfer: Jeder Zustandspunkt eines Agenten hat einen Mechanismus außerhalb des Modells, der widerspricht, wenn der Punkt nicht gehalten wird – die Syntaxprüfung vor jeder Karte, der Abgleich zwischen behaupteter und tatsächlich gelaufener Werkzeugnutzung, der Build-Status, die getakteten Wächter-Funktionen. Keiner davon steht im Prompt. Sie klopfen auch dann, wenn eine Anweisung im langen Kontext verblasst ist.

Die Grenze gehört zur Eigenschaft selbst: Nichts wird still mitgelegt. Jedes vorweggenommene Fundament steht benannt in der Vorschau-Karte, bevor der Nutzer klickt – er sieht es und kann es streichen. Der gefährlichste Fehlermodus vorausschauender Systeme ist nicht die falsche Vorhersage, sondern die ausgeführte falsche Vorhersage. In dieser Plattform gibt es keine Ausführung ohne Klick.

→ Ausführlich, mit Prüfprotokoll und Selbstkritik: Vorhersagendes Bauen

3.3 Die Stimmgabel – Interozeption auf Funktionsebene

Vorbild: 3.2, angewandt auf den eigenen Körper. Jede Funktion sagt aus ihrer eigenen Vergangenheit voraus, wie lange sie dauern wird – gemeldet wird nur die Abweichung. Keine Schwelle ist ausgedacht; jede entsteht aus den Messwerten der Funktion selbst.

• Messnetz ohne Liste: Beim Start umhüllt takt.verkabeln() jede Funktion der Projekt-Module selbsttätig (zuletzt gemeldet: 567 Adern). Neue Module sind ohne Eintrag dabei. Aufschlag je Aufruf: rund eine halbe Mikrosekunde.
• Kammerton als Lineal: Eine feste Rechenaufgabe misst, wie schnell der Container gerade überhaupt ist. Dauern werden als Vielfaches davon gelesen (ton_mittel, ton_p95) – ein allgemein langsamer Container gilt so nicht als kaputte Funktion.
• Selbstausmessung: Je Ader Median und Streuung (MAD). Auffällig ist, was mehr als TAKT_AUSREISSER_GRENZE = 3.5 Streuungen vom eigenen Typischen abweicht. Eine eng streuende Ader schlägt früh an, eine ohnehin schwankende spät – mit derselben Regel.
• Vier Befunde als TAKT-WARNUNG: Fehler, Ausreißer, Verstimmung über mehrere Bilanzen und Schweigen – eine sonst lebhafte Ader verstummt, während das Gesamtsystem normal arbeitet. Diese Bedingung unterscheidet einen stillen Ausfall von bloßer Ruhe.
• Gedächtnis über Deploys: Je Revision ein Fingerabdruck in Firestore (takt_revisionen), verglichen mit bis zu fünf Vorgängerinnen. Gewertet werden nur Revisionen mit genug Messungen; es bleiben nur die letzten 50 Blätter. Der Arbeitsspeicher ist gedeckelt: 30-Minuten-Fenster, höchstens 3.000 Werte je Ader.

Beleg aus dem Betrieb (26.09.2026): Nach der Modularisierung fehlte im Prisma ein einziger Name (MEMORY_TOP_K). Der parallele Gedächtnisabruf scheiterte bei jedem Aufruf, fiel lautlos auf den Einzelabruf zurück und blieb für Nutzer unsichtbar. Die Antwort kam pünktlich, kein Wächter schlug an. Die Stimmgabel zählte die Fehler an _prisma_budget_liste; der Fix war eine Import-Zeile (e3911e2f).

Grenzen, bewusst benannt: Sie hört nur Fehler, die aus einer Funktion herausfliegen – was die Funktion selbst verschluckt, wirkt gesund. Aufrufe unter 5 ms ohne Fehler werden nicht gemeldet. Endpunkt-Funktionen, später geladene Module und Generatoren tragen keine Hülle. Eine Warnung erscheint bis zu 30 Minuten später. Sie misst, sie deutet nicht: Die Erkennung ist eine Wenn-Dann-Regel ohne Sprachmodell. Deuten tun die Agenten, und nur dann, wenn eine Regel angeschlagen hat.

→ Vollständig, mit Zeilenarten, Konstanten und Lesebeispielen: Bibliothek/HANDBUCH_STIMMGABEL.md

4. Gedächtnis (Hippocampus-Analog)

4.1 Multiple Zeitskalen – implementiert, nicht geplant

Vier Speicher, vier Verfallsgeschwindigkeiten, vier Abrufwege – die Zeitskalen-Architektur des Vorbilds, im Code nachweisbar. Alles Erinnerte gilt dabei als Indiz, nie als Beleg: geprüft wird am Code.

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).

Alles bisher Genannte ist Mathematik: Abstände, Gewichte, Schwellen. Seit dem 17.09.2026 hat der Nachtlauf eine zweite Stufe, in der das Gedächtnis nicht mehr rechnet, sondern liest – das Destillat (_memory_destillat_erzeugen in app.py). Ein Bericht ist voll von Angaben, die binnen Tagen veralten: Zeilennummern, Commit-Kürzel, Revisionsnamen, Zwischenstände. Das Destillat schreibt in drei bis fünf Sätzen auf, was von diesem Bericht auch dann noch wahr ist, wenn der Code längst umgebaut wurde – die Lehre, nicht das Protokoll.

• Bewusst das stärkste Modell: Das Destillat ist die einzige Stelle, an der das Gedächtnis nachts denkt – deshalb läuft hier nicht das vom Reranker geborgte Flash-Lite, sondern dasselbe Modell wie die stärkste Chat-Stufe (MEMORY_DESTILLAT_MODEL, derzeit gemini-3.1-pro-preview; Umgebungsvariable gleichen Namens als Notausgang ohne Deploy). Host und Region werden nicht geraten, sondern aus vertex_endpunkt_fuer(modell) abgeleitet – ein global verfügbares Modell läuft über die globale Adresse, ein EU-Modell über die EU-Adresse. Die Begründung ist wirtschaftlich, nicht romantisch: Nachts ist Rechenzeit die billigste Ressource, und ein besseres Destillat spart am Tag jeden Abruf erneut.
• Harte Grenzen statt offener Rechnung: nur Berichte vom Typ protokoll oder lehre, erst ab 700 Zeichen Volltext (MEMORY_DESTILLAT_MIN_ZEICHEN), höchstens 24.000 Zeichen Eingabe, höchstens 900 Zeichen Ausgabe, höchstens 15 Destillate je Nacht (MEMORY_DESTILLAT_MAX_JE_LAUF), 90 Sekunden Zeitlimit je Aufruf und 1,5 Sekunden Pause danach (MEMORY_DESTILLAT_PAUSE) – letzteres genau deshalb, weil fünfzehn Aufrufe an ein starkes Modell Schlag auf Schlag das Muster sind, das eine Ratenbegrenzung auslöst.
• Der Bericht wird nicht angefasst: Das Destillat ist ein eigenes Dokument vom Typ lehre mit fester ID destillat__<source_id> – derselbe Bericht kann dadurch nie zwei Destillate bekommen. Es trägt destillat_von und destillat_modell als Herkunft und eine Wichtigkeit von mindestens 0.8. Der Originalbericht bleibt unverändert und erhält lediglich einen Verweis (destillat_id, destillat_at). Findet das Modell keine überlebende Lehre, antwortet es LEER; dann wird genau das vermerkt und nichts geschrieben – ein erzwungener Merksatz wäre schlechter als keiner.
• Wirkung beim Abruf: Das Prisma zieht Treffer vom Typ lehre innerhalb ihres Anliegens nach vorn (Stufe 5 der Abruf-Kette). Die Lehre steht damit vor dem Rohbericht, aus dem sie stammt.
• Prüfbar am Morgen, nicht nur zählbar: Jedes Destillat schreibt eine eigene Log-Zeile RAG_DESTILLAT mit Ablage, Quelle, Zeichenzahl, Modell, Laufzeit und einer 400 Zeichen langen Textvorschau; Fehlschläge stehen als DESTILLAT-FEHLER mit benanntem Grund (http404, http429, netz, kein_embedding …), und die Sammelzeile RAG_CONSOLIDATION_GESAMT führt destillate= und destillat_fehler=. Die Textvorschau ist bewusst das letzte Feld der Zeile, damit die auswertbaren Felder auch bei Kürzung erhalten bleiben. Zählen konnte man vorher schon – beurteilen erst jetzt.
• Rückweg in einem Schritt: Destillate löschen (ID-Präfix destillat__), kein Wiederaufbau nötig. Die Berichte selbst sind unberührt.
• Ehrliche Grenze: Der Altbestand trägt den Typ lehre nicht. Diese Schicht wirkt zuerst nur für das, was ab jetzt destilliert wird, und wächst mit jeder Nacht – sie ist kein rückwirkender Umbau des Gedächtnisses.

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.

4.5 Was ins Gedächtnis geschrieben wird – zwei Kanäle, zwei Regeln

Ein Gedächtnis entsteht nicht dadurch, dass viel hineinfließt, sondern dadurch, dass entschieden wird, was hineinfließt. Diese Plattform beantwortet die Frage an zwei Stellen unterschiedlich – und der Unterschied ist die eigentliche Aussage.

• Baustellen-Kanal (Umsetzer): automatisch. Jeder abgearbeitete Schritt einer Roadmap wird als Paar aus Auftrag und tatsächlicher Antwort ins Langzeitgedächtnis geschrieben, ebenso der Abschlussbericht des ganzen Laufs (store_memory_batch in app.py, feste Konversation UMSETZER_CONV_ID = "umsetzer-baustelle"). Der immer gleiche Regel-Vorspann bleibt bewusst draußen – er wäre Ballast im Vektorraum. Beide Schreibwege stehen in einem eigenen try: ein Fehler im Gedächtnis darf den laufenden Umbau nicht anhalten.
• Wächter-Kanal: ausdrücklich nicht automatisch. Im gesamten Wächter-Pfad gibt es keinen einzigen Schreibaufruf ins Langzeitgedächtnis. Was aus einem Alarm gelernt wird, gelangt nur dorthin, wenn der Mensch den Abschlussbericht bewusst übergibt. Das ist keine fehlende Funktion, sondern eine Entscheidung.

Die Begründung ist biologisch und messbar zugleich. Das Vorbild unterscheidet Nozizeption von Schmerz: Rezeptoren feuern ständig, die allermeisten Signale erreichen das Bewusstsein nie. Erst was wiederkehrt, überwindet das Tor – und die Instanz, die Wiederholung erkennt, ist nie der Rezeptor selbst. Ein Organismus, der jeden Reflex ins Langzeitgedächtnis schriebe, wäre nicht aufmerksamer, sondern traumatisiert. Technisch dasselbe Argument: Jeder Deploy-Hickser und jeder 429, der automatisch abgelegt wird, senkt die Trennschärfe des Vektorraums – die Abstände zwischen gutem und schlechtem Treffer schrumpfen, bis die Reihenfolge der Erinnerungen Rauschen ist. Diese Spannweite wird ohnehin gemessen (get_rag_bilanz); unkontrolliertes Lernen würde genau an dieser Zahl in die falsche Richtung drehen.

Die Asymmetrie folgt damit einer einzigen Regel: Ein Eintrag wird automatisch gespeichert, wenn er ein Paar ist – eine Absicht und ihr Ergebnis. Das ist auch dann lehrreich, wenn der Schritt scheitert, denn es sagt: das wurde versucht, das kam dabei heraus. Ein Wächter-Ausschlag dagegen ist ein Einzelreiz ohne Auftrag und ohne Ergebnis; ob er etwas bedeutet, weiß in diesem Moment niemand.

Entscheidend für die Wirkung: Der Abruf filtert nicht nach Herkunftskanal (find_nearest kennt nur die Trennung nach Besitzer). Was auf der Baustelle schiefging und wie es behoben wurde, ist deshalb später im normalen Gespräch auffindbar, sobald ein neues Vorhaben semantisch in die Nähe kommt. Damit schließt sich der Kreis der vorhersagenden Wahrnehmung ohne menschliches Zutun – der Vorhersagefehler von gestern wird zum Kontext von morgen. Die ehrliche Abgrenzung gehört dazu: Es werden keine Gewichte angepasst, das Modell lernt nicht. Was lernt, ist der Kontext, den es beim nächsten Mal vorgelegt bekommt – keine Veränderung des Gehirns, sondern eine wachsende Bibliothek mit einem besseren Bibliothekar.

→ Ausführlich hergeleitet: Vorhersagendes Bauen

5. Motorik, Response und die Baustelle

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.

5.1 Der Baustellen-Kanal – Reflexbogen mit Rückmeldung

Vorbild: Der Miktionsreflex. Das Großhirn beschränkt sich auf die Freigabe; Blasenkontraktion, innerer Schließmuskel und deren Koordination laufen über einen Reflexbogen in Rückenmark und Hirnstamm. Entscheidend ist die Afferenz: Der Bogen prüft laufend, ob der Zustand wirklich eingetreten ist, den er ausgelöst hat. Passt die Rückmeldung nicht, hält er an und meldet nach oben.

Genau so arbeitet der Baustellen-Kanal. Eine mehrstufige Umsetzung wird nicht in der laufenden Sitzung abgearbeitet, sondern in einen eigenen, dauerhaften Raum ausgelagert – die Sitzung bleibt frei. Der Mensch gibt jeden Schritt per Klick frei; die Kette dazwischen läuft ohne ihn.

• Fester Raum, selbstheilend: Die Baustelle hat eine feste Adresse (UMSETZER_CONV_ID = "umsetzer-baustelle"), keinen Zeitstempel im Namen. Fehlt sie, wird sie angelegt; ist sie archiviert, wird sie zurückgeholt; fehlt die Startnachricht, wird sie wieder vorangestellt. Bestehende Nachrichten werden dabei weder gelöscht noch umsortiert. Unlöschbar heißt hier ausdrücklich selbstheilend, nicht technisch gesperrt. Anker: app.py, _baustelle_bereitstellen().
• Der Zustand liegt außerhalb des Containers: Ein Lauf führt genau einen Schritt aus und endet. Alles, was der nächste Schritt wissen muss – Roadmap, Schrittzähler, Rolle des Auftraggebers, Commit-Nachricht der letzten Karte – steht in Firestore. Der Grund ist hart: Der nächste Schritt läuft in einem Container, der zum Zeitpunkt des Starts noch nicht existiert. Nur was im Dokument steht, überlebt einen Deploy.
• Erstes Tor – Vorprüfung im Auftrag: Ab Schritt 2 trägt jeder Lauf die Anweisung, zuerst per list_recent_commits zu prüfen, ob der Commit des vorigen Schrittes wirklich im Repository angekommen ist. Fehlt er, wird keine Karte gebaut, sondern angehalten und der Grund geschrieben.
• Zweites Tor – Abgleich der eigenen Commit-Nachricht: Nach jedem Container-Start läuft die Resume-Wache einmal an (rund 25 Sekunden Verzögerung). Ein Revisionswechsel allein zündet nichts: Beim Bauen der Karte wird deren Commit-Nachricht in Firestore hinterlegt und nach dem Deploy in der Historie gesucht. Fehlt sie, wartet die Wache weiter und protokolliert fremder Deploy … eigene Karte noch nicht im Repository. Ein Vergleich des obersten Commits hätte das nicht geleistet – der ändert sich bei einem fremden Deploy genauso. Unterscheidbar ist nur die selbst geschriebene Nachricht. Anlass war ein realer Zwischenfall am 08.09.2026, bei dem ein fremder Deploy die Kette überholte.
• Genau eine Zündung: Starten mehrere Instanzen derselben neuen Revision gleichzeitig, legt jede eine Claim-Marke per create() an. Das gelingt genau einmal, alle weiteren fallen durch. Die Marke trägt bewusst kein Änderungsdatum und bleibt dadurch in der Chatliste unsichtbar.
• Begrenzte Länge: Eine Roadmap ist auf UMSETZER_MAX_SCHRITTE Schritte gedeckelt (Standard 8, per Umgebungsvariable änderbar). Ein Reflexbogen ohne Endpunkt wäre ein Krampf, kein Ablauf.
• Die Freigabe bleibt beim Menschen: Der Kanal baut Karten, er übernimmt sie nicht. Ohne Klick geschieht in jedem Schritt nichts. Autonom ist die Kette zwischen den Klicks, nicht der Vollzug.

Bewusste Auslassung: Es gibt keinen Weg, die Kette ohne Klick durchlaufen zu lassen – auch nicht als Schalter. Damit ist der Baustellen-Kanal Motorik und nicht Vegetativum: Er läuft ohne Aufmerksamkeit, aber nie ohne Freigabe.

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 (Talk / 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, ELARA_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).

7.1 Das Stammhirn – Vorbewertung durch ein kleines Sprachmodell (seit 28.09.2026)

Feste Schwellen sehen Zahlen, aber keine Zusammenhänge. Deshalb urteilt im Log-Wächter nach jedem Regel-Lauf zusätzlich ein günstiges Sprachmodell (STAMMHIRN_MODELL, Vorgabe gemini-3.8-flash, über Umgebungsvariable änderbar). Es bekommt das Grundrauschen, die Grün-Bilanz, die jüngsten Zeilen der Stimmgabel und das jüngste Revisionsblatt und antwortet mit genau einem Wort: GRUEN, GELB oder ROT. Anker: waechter/log-check/main.py, Funktion stammhirn_lauf.

• Es handelt nicht, es weckt. Seine einzige Handlung ist der bestehende Startschuss an die Konsole (/api/system/waechter-alarm): GELB weckt Gemini, ROT startet die volle Kette. Es startet nichts neu, ändert keine Einstellung und rollt nichts zurück.
• Vier Riegel: ein Not-Aus in Firestore (Feld aus im Status-Dokument stammhirn), ein Tagesbudget von 4 Alarmen, eine Abklingzeit von 3 Stunden für GELB und 6 Stunden für ROT, und Schweigen, wenn in diesem Lauf schon die festen Regeln gegriffen haben.
• Scheitern ist harmlos: Fällt das Modell aus, läuft der Regel-Wächter unverändert weiter. Jedes Urteil hinterlässt eine Log-Zeile (STAMMHIRN urteil=…) und steht im Status-Dokument.
• Nachlesen: Was der Wächter ist, steht in Bibliothek/HANDBUCH_WAECHTER.md. Wie eine neue Fassung ausgerollt wird, steht in Blueprints/BLUEPRINT_WAECHTER_DEPLOY.md.

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 – im Wächter nicht als Metapher, sondern als Mechanismus implementiert (waechter/log-check/main.py, Funktion handle_gruen): Die Grün-Zone führt einen gleitenden Mittelwert des Log-Grundrauschens als Erwartung (baseline = 0.2·aktuell + 0.8·alt); nur was diese Erwartung um mehr als das Doppelte übersteigt, steigt als Überraschung auf – das Erwartbare wird unten vollständig verarbeitet und löst per Design nie einen Alarm aus. Habituation ist real umgesetzt: Gelb muss zwei Stunden über mindestens drei Prüfungen bestehen, Rot hat eine Abklingzeit je Fehlertyp. Der Reranker ist von dieser Aussage bewusst ausgenommen – er ordnet Treffer um, filtert aber nicht nach Überraschung.

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. Das Stammhirn (Kapitel 7.1) ist kein solcher Reflex: Es bewertet nur und zieht den vorhandenen Alarm, entscheiden tut weiter der Mensch.
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.
• Stammhirn im Log-Wächter (Vorbewertung durch Sprachmodell): live seit 28.09.2026.
• 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.