Signal

Die zentrale Intuition von XCAP ist brutal und für alle, die aus der SaaS-Welt kommen, wenig naheliegend: In einem Trading-Research-System ist das Netz keine Bequemlichkeit, sondern die grösste Angriffsfläche, die du hast. Jeder Endpoint mit Schlüssel ist ein Credential, das leaken kann; jeder schreibende Call ist ein Trade, der durch einen Bug losgehen kann. Deshalb kollabiert XCAP seine gesamte Netzwerk-Exposition auf einen einzigen Punkt: eine read-only, keyless und GET-only Ingest-Edge. Der Rest des Systems ist deterministisch von der Disk. Wenn du das verstehst, verstehst du auch, warum `binance_public.py` nur klines (historische OHLCV-Kerzen) per HTTP GET anfragt – ohne API key, ohne etwas zu signieren, ohne jemals einen Account- oder Order-Endpoint anzufassen.

Konkret sieht das Muster so aus: eine abstrakte Quelle (in XCAP eine `OHLCSource`-Hierarchie) mit zwei Implementierungen. `LocalCSVSource` liest CSVs, die schon auf der Disk liegen – null Netz, der Default-Fall, der von ALLEN automatischen Loops genutzt wird. Und `HttpOHLCSource` (gestützt auf `binance_public.py`), die nur dann aktiv wird, wenn ein Caller explizit `allow_network=True` übergibt oder den Befehl `data-fetch` aufruft. Die Asymmetrie ist gewollt: Der sichere Weg ist der Default, und der Weg mit Netz verlangt bei jedem Call eine explizite Option. Niemals ein globales Umgebungs-Flag, niemals eine Umgebungsvariable, die eingeschaltet bleibt.

Der Binance-Endpoint, den du nutzt, ist der öffentliche Markt-Endpoint: `GET https://api.binance.com/api/v3/klines?symbol=BTCUSDT&interval=1d&limit=1000`. Er liefert ein Array von Arrays: `[openTime, open, high, low, close, volume, closeTime, ...]`. Achte darauf, was hier NICHT vorkommt: kein Header `X-MBX-APIKEY`, kein Query-Param mit HMAC-Signatur, kein signierter Timestamp. Dieser Endpoint kann physisch weder dein Guthaben lesen noch eine Order platzieren, weil die Account-API von Binance auf einer anderen Route lebt und eine Signatur verlangt. Sicherheit ist kein Versprechen von dir, dich brav zu verhalten: Sie ist eine Eigenschaft des Endpoints, den du gewählt hast.

Die zweite Säule ist die Normalisierung am Rand. Echtweltdaten kommen dreckig an: Timestamps in Millisekunden, Zahlen als Strings, duplizierte Kerzen, Lücken. Deine Edge muss auf EIN kanonisches Format normalisieren, bevor irgendetwas downstream sie anfasst. In XCAP sind die CSVs von `data/real` lowercase (`open,high,low,close,volume`), Timestamps zu Daten geparst, und `LocalCSVSource` liest sie immer gleich. Genau diese Disziplin macht das System reproduzierbar: Der Regime-Klassifikator (SG-02) und das Market Memory (SG-03) lesen von der Disk ein stabiles Format, nicht eine volatile HTTP-Antwort, die zwischen Durchläufen wechselt.

Die Verifikation ist der Abschluss. XCAP hat einen Befehl `check` (läuft mit `PYTHONPATH=src python3 -m xcap.control check`), der als Invariante behauptet, dass der Connector keyless und read-only ist, nicht handeln kann und kein Geld bewegen kann. Das ist kein Test, der einmal durchläuft: Es ist eine Behauptung, die bei jedem `check` läuft, sodass der `check` rot wird, falls jemand einen Schlüssel oder eine Schreibmethode hinzufügt. So verwandelst du eine Design-Absicht in eine Eigenschaft, die das System selbst verteidigt. Die goldene Regel: Sicherheit, die davon abhängt, dass du dich an etwas erinnerst, ist keine Sicherheit; Sicherheit, die dich ein roter Test zu respektieren zwingt, schon.

Eine wichtige operative Nuance: Das Dashboard von XCAP bindet nur an `127.0.0.1`, niemals an `0.0.0.0`. Die Ingest-Edge ist die einzige ausgehende Oberfläche; die eingehende (das Dashboard) lauscht nicht am Netz. Und FileVault (AES-256) verschlüsselt die Disk im Ruhezustand. Die ganze Kette – verschlüsselte Disk, keyless read-only Ingest, lokal-only Dashboard, geschlossenes Capital Gate – ist es, was es erlaubt, ein Trading-Research-System auf einem Laptop zu haben, ohne dass es eine tickende Zeitbombe ist.

Der konzeptionelle Fehler, den XCAP in seinem Audit vom Juni 2026 korrigiert hat, ist subtil und Gold wert: operationelle Gesundheit mit Preis-Regime zu verwechseln. `market_state.py` misst die Gesundheit des Systems (Habe ich frische Daten? Stimmen die Flags?). `regime.py` misst etwas völlig anderes: In welchem ZUSTAND befindet sich der Markt selbst? Das sind orthogonale Achsen, und sie zu vermischen erzeugt einen Klassifikator, der nicht weiss, was er sagt. Die erste Disziplin lautet: Ein Regime-Klassifikator spricht nur über den Preis, niemals über den Zustand deiner Infrastruktur.

Das Design von XCAP klassifiziert entlang vier unabhängiger Achsen. Trend (steigt, fällt, seitwärts? – über die Steigung gleitender Durchschnitte oder den kumulierten Return über ein Fenster). Volatility (ruhig oder bewegt? – über die Standardabweichung der Returns, normalisiert). Behavior (persistent/trendend oder mean-reverting? – über die Autokorrelation der Returns). Und Stress (entwickelt sich gerade ein Drawdown?). Jede Achse wird rein berechnet: gleicher Input, gleicher Output, ohne verborgenen Zustand, ohne Zufall. Danach leitet eine dokumentierte Prioritätskaskade ein einziges, übergeordnetes `Regime` aus den vier Achsen ab.

Der schärfste Insight von XCAP steckt darin, wie es Panic definiert – und genau hier irren sich fast alle. Die Versuchung ist, Panik als 'hohe Volatilität' zu definieren (erhöhter Stdev-Ratio). Das ist falsch. Ein monotoner Crash – der Preis fällt fast in gerader Linie – hat eine niedrige INTERNE Volatilität, weil jede Kerze der vorigen gleicht. Wenn du Panik über Stdev definierst, verpasst du genau den gefährlichsten Crash. Die korrekte Definition von XCAP: Panik ist ein grosser Drawdown, der sich SCHNELL entwickelt, gemessen über einen stark negativen, scharfen jüngeren Return, nicht über die Streuung. Genau das unterscheidet einen Klassifikator, den jemand entworfen hat, der echte Crashes angeschaut hat, von einem, der eine Formel aus einem Buch kopiert hat.

Reinheit ist keine ästhetische Laune, sie ist die Grundlage des Vertrauens. `regime.py` ist eine reine Funktion: `classify(bars) -> Regime`. Sie liest in sich nicht von der Disk, ruft das Netz nicht auf, mutiert nichts Globales, hat keinen Zufallszweig. Das bedeutet: Du kannst sie tausendmal über dasselbe Fenster laufen lassen und erhältst dasselbe Label, du kannst sie mit deterministischen Fixtures testen, und du kannst exakt auditieren, warum sie an einem bestimmten Datum 'Panic' gesagt hat. Ein Klassifikator mit verborgenem Zustand ist ein Klassifikator, dem du nicht vertrauen kannst, um darauf Market Memory aufzubauen.

Die wichtigste Regel, und die, die mit der gesamten Konstellation verbindet: Der Klassifikator ist label-only. Er dimensioniert oder handelt NIEMALS. Er gibt ein Label zurück und sonst nichts. Der Grund ist eine Architektur der Ehrlichkeit: Wenn dasselbe Modul, das das Regime diagnostiziert, auch die Positionsgrösse entscheidet, hast du einen Anreiz, dass die Diagnose den Trade rechtfertigt, den du ohnehin machen wolltest. Diagnose von Aktion zu trennen ist das, was es in SG-03 erlaubt, ehrlich zu messen, ob das Regime prädiktiven Wert hat – weil das Label erzeugt wurde, ohne zu wissen, was du damit machen würdest.

Um es gut zu implementieren, dokumentiere die Prioritätskaskade als lesbaren Code, nicht als Knäuel von ifs. Zum Beispiel: Wenn Stress Panic auslöst, gewinnt Panic über alles andere; wenn nicht und Volatility hoch ist bei starkem Trend, ist es Trending-Volatile; wenn Behavior mean-reverting ist und der Trend seitwärts läuft, ist es Range; usw. Jeder Zweig sollte einen Kommentar haben, der das Warum des Marktes erklärt, nicht nur den Schwellenwert. Genau dieser Kommentar ist das, was ein Reviewer – oder du selbst in sechs Monaten – braucht, um dem Label zu vertrauen.

Der zentrale Befund des XCAP-Audits war vernichtend: Jedes vorige Modul war entweder stateless Berechnung oder ein passiver Akkumulator; NICHTS registrierte eine falsifizierbare Vorhersage vor dem Ausgang und bewertete danach seine eigene Kalibrierung. Genau dieser fehlende Loop macht ein Research-System schwer zu täuschen, und er ist die einzige ehrliche Quelle für Edge-Evidenz. Market Memory (`market_memory.py`) ist dieser Loop. Wenn du dieses Modul nicht baust, ist alles andere Theater: hübsche Berechnungen, die nie mit der Realität konfrontiert werden.

Das Herz ist `advance_market_memory(universe, state_dir, horizon_days=5, ...)` und seine Sequenz ist heilig in dieser Reihenfolge: neue Daten beobachten → das Regime klassifizieren (mit dem `regime.py` aus SG-02) → einen GESPERRTEN Forecast registrieren (ein vom Regime abgeleitetes Baseline, mit seiner Wahrscheinlichkeit und seinem Horizont) → die bereits gereiften Forecasts gegen den realisierten Forward-Return auflösen → bewerten. Sperren ist das Schlüsselwort: Sobald du 'am Datum T sage ich prob_up=0.62 auf 5 Tage voraus' registrierst, ist dieser Eintrag unveränderlich. Du darfst ihn nicht mehr anfassen, wenn du das Ergebnis siehst. Genau diese Unveränderlichkeit verwandelt das Ledger in Evidenz und nicht in eine nachträgliche Rationalisierung.

Die Metriken sind nicht eine einzige; sie sind ein ehrliches Panel. Hit-Rate (welcher Anteil der direktionalen Vorhersagen war richtig?). Brier-Score (wie gut waren die Wahrscheinlichkeiten kalibriert? – er bestraft sowohl Überkonfidenz als auch Unterkonfidenz). Kalibrierung nach Konfidenz-Bucket (wenn du 70% gesagt hast, lagst du in 70% der Fälle richtig?). Und das Juwel: Hit-Rate NACH REGIME. Letztere ist die, die wirklich informiert: Sie sagt dir, ob deine Vorhersage im Trend Wert hat, aber in der Range Müll ist, oder ob du nur in der Ruhe triffst. Eine globale Hit-Rate von 55% kann 70% im Trend und 40% in der Panik verstecken – und genau diese Zerlegung sagt dir, wo es, falls überhaupt, einen Edge gibt.

Die Anti-Fabrikations-Eigenschaft ist by construction (wir vertiefen sie in SG-04, aber hier ist sie strukturell): Es werden nur Forecasts aufgelöst, deren Horizont bereits mit Daten gereift ist, die NACH dem Forecast-Datum existierten. Es ist Out-of-Sample by design. Du kannst niemals ein Datum 'vorhersagen', dessen Ergebnis du bereits kennst, weil der Forecast bei T gesperrt wurde und erst aufgelöst wird, wenn T+horizon mit echten Daten eintrifft. Das state dir ist gitignored – die Historie wird nicht versioniert, damit keine Versuchung besteht, sie von Hand zu editieren und Ergebnisse zu schönen.

Die drei Integritäts-Eigenschaften, die XCAP erzwingt und die du replizieren musst: akkumuliert (das Ledger wächst zwischen Durchläufen, es setzt sich nie zurück), idempotent (den Tick zweimal über dieselben Daten laufen zu lassen dupliziert keine Forecasts und löst sie nicht zweimal auf) und Gate-closed (handelt niemals). Das ist dieselbe Familie von Invarianten wie das Capital Invariant aus SG-05: Der Systemzustand ist die Summe echter Ereignisse, niemals ein Replay oder ein frisches Baseline. Das CLI `market-memory-tick` orchestriert das und liest CSVs im Format `data/real` (lowercase) über `LocalCSVSource` – null Netz, alles deterministisch von der Disk.

Ein Punkt, der den Ingenieur vom Amateur trennt: Das Baseline, das du registrierst, muss ehrlich und bescheiden sein. XCAP registriert ein 'regime_baseline' – eine vom Regime abgeleitete Wahrscheinlichkeit, kein ausgeklügeltes Modell, das du bereits durch den Blick in die Vergangenheit optimiert hast. Warum bescheiden anfangen? Weil das Baseline dein Massstab ist. Wenn ein ausgefeilter Forecaster das Regime-Baseline out-of-sample nicht schlägt, hast du keinen Edge, du hast Overfitting. Market Memory existiert, um deine Ideen zu widerlegen, nicht um sie zu bestätigen. Und ein gutes Forecast-Register ist Evidenz, niemals Beweis – deshalb bleibt das Capital Gate geschlossen, egal wie gut die Hit-Rate aussieht.

Die Frage, die dieses Modul definiert: Wie baust du ein System, das dich nicht über das Vorhandensein eines Edge belügen KANN? Die Antwort von XCAP ist nicht 'vorsichtig sein'. Sie besteht darin, strukturelle Gegenspieler einzuführen – Null-Controls –, gegen die jede Edge-Behauptung antreten muss. Das Hypothesis Lab (`hypothesis_lab.py`) hat ein Register echter Forecaster (regime_baseline, trend_follow, momentum_follow, mean_revert) UND zwei bewusste Null-Controls: `always_up` (das DRIFT-Null – der Markt steigt im Mittel, fängt dein Forecaster nur das ein?) und `coin_flip` (das ZUFALLS-Null – geseedet und deterministisch, schlägst du einen Münzwurf?). Ein Forecaster, der nicht BEIDE Nulls schlägt, hat keinen Edge, er hat eine Illusion.

Die zweite Säule ist die Signifikanz mit Korrektur für multiple Vergleiche. Wenn du zwanzig Forecaster testest, wird einer durch puren Zufall gut aussehen – das ist das Problem des Data-Snoopings. XCAP neutralisiert das mit einem Bonferroni-korrigierten z-Schwellenwert, der mit K SKALIERT (der Anzahl der evaluierten Forecaster): je mehr Hypothesen du testest, desto höher die Latte, die jede überspringen muss. `evaluate_forecasters(universe, names, horizon_days, min_samples, alpha)` vergleicht jeden echten Forecaster gegen beide Nulls (Δzufall und Δdrift) und vergibt `candidate_edge` nur, wenn er den Zufall UND die Drift schlägt UND den korrigierten Schwellenwert überspringt UND mindestens `min_samples` Beobachtungen hat. Die vier Bedingungen, alle gemeinsam. Eine wegzunehmen öffnet eine Tür zur Fabrikation.

Das Detail, das zeigt, dass das System ehrlich und nicht frisiert ist: `edge_demonstrated` ist IMMER False. Das Lab kann `candidate_edge` vergeben – 'das verdient weitere Untersuchung' – aber es erklärt niemals einen bewiesenen Edge, denn kein Backtest, so gut er auch ist, beweist zukünftigen Edge. Das ist eine Designentscheidung, die gegen deinen eigenen Optimismus schützt: Das System hat buchstäblich keinen Code-Pfad, der sagt 'ja, du hast Edge, handle'. Das Capital Gate bleibt by construction geschlossen, nicht durch deine Disziplin.

Die Verifikation, dass das Scoreboard nicht gezinkt ist, ist elegant und du musst sie replizieren: XCAP hat geprüft, dass auf synthetischen Trends `trend_follow` gross gewinnt (es erkennt das echte Signal), `mean_revert` signifikant NEGATIV wird (es erkennt einen Anti-Edge – gegen den Trend zu wetten verliert) und `coin_flip` bei ~50% landet (der Zufall wird nicht belohnt). Wenn dein coin_flip mit 60% Hit-Rate herauskäme, ist deine Pipeline kaputt oder du hast Leakage. Die Nulls sind nicht nur Gegenspieler: Sie sind Kalibrierungs-Sonden deines eigenen Mess-Systems. Ein coin_flip, der nicht ~50% ergibt, ist ein System, das sich selbst belügt, und du musst alles stoppen, bis du verstehst, warum.

Das gemeinsame Fundament verhindert den Trick, das Tor zu verschieben: `scoring.py` ist die einzige Quelle der Wahrheit für die Primitiven (prob_up, is_hit, brier, conf_bucket, hit_rate_z). Sowohl Market Memory (SG-03) als auch das Hypothesis Lab bewerten mit DEMSELBEN Code. Hättest du zwei Implementierungen von 'hit', könntest du – bewusst oder nicht – die grosszügigere für deinen Lieblings-Forecaster nutzen. Eine einzige geteilte Primitive schliesst diese Tür. Das ist Anti-Fabrikation by construction: Du kannst nicht die Regel wählen, die dir passt, weil es nur eine Regel gibt.

Jede Evaluation ist out-of-sample durch dieselbe Mechanik wie SG-03: Jede Bar wird genau einmal klassifiziert, der Forecast wird erzeugt, ohne die Zukunft zu sehen, und er wird gegen den echten Forward-Return aufgelöst. Das Doc `docs/HYPOTHESIS_LAB.md` und die 4 Invarianten des `check` kodieren diese Garantien. Die grundlegende Lektion, die die These der gesamten Signal-Konstellation ist: Die bindende Bedingung, um echtes Kapital zu handeln, ist BEWIESENER Edge, und diese Werkzeuge messen Edge ehrlich (Null-Controls + Signifikanz), statt ihn zu behaupten. Ein System, das nur `candidate_edge` und niemals `edge_demonstrated` ausgeben kann, ist ein System, das respektiert, was es nicht weiss.

Dieses Modul entstand aus einem echten und schmerzhaften Fehler in XCAP, und genau deshalb lehrt es so gut. Ein geplanter Autorun setzte stillschweigend das Ledger auf das Anfangsguthaben von 500 ZURÜCK und spielte alle 5 Minuten dasselbe identische Fixture ab. Das System zeigte Aktivität, sich ändernde Zahlen, es wirkte lebendig – und war komplett falsch. Drei Regeln wurden gleichzeitig verletzt, und das sind die drei, die das Capital Invariant definieren. Merk dir diese Regeln, denn sie sind der Kern: akkumuliert, realized-only, und re-entry setzt vorige Sessions fort.

Regel 1 – Akkumuliert. Das Kapital setzt sich NICHT zwischen Durchläufen oder Sessions zurück. Wenn du gestern die Session mit 547.30 beendet hast, beginnst du heute mit 547.30. Ein frisches Baseline bei jedem Start ist keine Buchführung, es ist eine verkleidete Demo. Das Ledger wird beim Start von der Disk geladen und beim Beenden persistiert; der Zustand lebt zwischen Ausführungen.

Regel 2 – Realized-only. Das Guthaben bewegt sich nur, wenn eine Position GESCHLOSSEN/verkauft wird. Das nicht-realisierte P&L (Mark-to-Market, der schwebende Wert einer offenen Position) bläht das Guthaben niemals auf. Die exakte Invariante, die du jederzeit behaupten können musst: `current_balance == starting_balance + realized_pnl`. Eine offene Position mit +200 schwebendem Gewinn ändert das Guthaben NICHT; das tut sie nur, wenn du sie schliesst und diese +200 realisiert werden. Das verhindert die älteste psychologische Falle des Tradings: die Gewinne zu zählen, bevor du sie eingestrichen hast.

Regel 3 – Re-entry setzt fort. Beim Neustart ist das Kapital das akkumulierte Ergebnis der Operationen voriger Sessions, keine neue Grundlinie. Das System muss tausendmal aus- und eingeschaltet werden können, und das Kapital muss immer die ehrliche Summe aller echten Closes sein, die passiert sind. Das ist dasselbe wie die Akkumulations-Eigenschaft von Market Memory (SG-03): Der Zustand ist die Summe echter Ereignisse, eine einzige Richtung, ohne Replay.

Die Architektur-Lektion ist die Unterscheidung zwischen zwei Befehlen, die XCAP bewusst getrennt hält. Der geplante Autorun läuft `sim-autopilot-tick`: Er lädt das bestehende Ledger, rotiert synthetische Regime und AKKUMULIERT auf dem Vorigen. Es gibt auch `sim-run-agent`, der zurücksetzt und ein Fixture abspielt – aber der wird NUR für deterministische Demos aufbewahrt und darf NIEMALS das sein, was der Autorun ausführt. Der Bug war genau, den Scheduler auf den falschen Befehl zu richten. Die Lehre: Ein Befehl, der zurücksetzt, und ein Befehl, der akkumuliert, dürfen nie verwechselbar sein; benenne sie so, dass der gefährliche herausschreit, was er tut.

Wie das gepanzert wird, damit es nicht wieder bricht: Die Invariante ist von `tests/test_sim_autopilot_tick.py` GELOCKT. Wenn du das Ledger oder den Autorun anfasst, müssen diese Tests grün bleiben. Das ist keine Dokumentation, es ist ein ausführbares Schloss. Die operative Regel, die der Nutzer nachdrücklich auferlegt hat: Wenn du die Buchführung anfasst, lässt du diesen Test laufen, und wenn er rot wird, hast du die Integrität des Kapitals gebrochen und stoppst. Das ist dieselbe Philosophie wie das Capital Gate und der `check` aus SG-01: Die Invarianten, die wirklich zählen, werden als Tests kodiert, die sich weigern, dich sie brechen zu lassen. Die Buchführung von XCAP ist nicht vertrauenswürdig, weil der Autor vorsichtig ist; sie ist vertrauenswürdig, weil ein roter Test ihn daran hindert, nachlässig zu sein.

Ein Autopilot-Tick ist Code, der läuft, ohne dass ein Mensch zuschaut, und genau das ist der Grund, warum er der DISZIPLINIERTESTE Code des Systems sein muss. Der Fehler, den XCAP am eigenen Leib erfahren hat, lehrt alles: ein geplanter Tick, der alle 5 Minuten das Ledger zurücksetzte und ein identisches Fixture abspielte. Von aussen betrachtet wirkte das System lebendig – sich bewegende Zahlen, ständige Aktivität. Innen war es eine Lüge in der Schleife. Die Frage, die einen guten Tick definiert: Akkumuliert dieser Loop, wenn er tausendmal läuft, etwas Wahres, oder erzeugt er nur den Anschein von Aktivität?

Eigenschaft 1 – Deterministisch von der Disk. Der Tick liest seinen Input von der Disk (CSVs `data/real` über `LocalCSVSource`), nicht aus dem Netz. Die automatischen Loops von XCAP aktivieren NIEMALS Netz – `allow_network` bleibt auf False, immer. Das ist direkte Kontinuität von SG-01: Das Netz ist explizites Opt-in pro menschlichem Call (der Befehl `data-fetch`), niemals etwas, das ein autonomer Loop selbst aktiviert. Ein Tick, der ohne Aufsicht ans Netz fasst, ist ein Tick, der leaken, nicht-reproduzierbar fehlschlagen oder beim Warten auf ein Socket hängen kann. Deterministisch von der Disk bedeutet, dass derselbe Zustand auf der Disk dasselbe Ergebnis produziert, prüfbar und reproduzierbar.

Eigenschaft 2 – Idempotent. Den Tick zweimal über dieselben Daten laufen zu lassen darf weder Forecasts duplizieren noch bereits Aufgelöstes erneut auflösen noch einen Close doppelt zählen. Das ist in Loops enorm wichtig, weil Scheduler fehlschlagen, neu versuchen, sich überlappen. Wenn dein Tick nicht idempotent ist, korrumpiert ein Retry den Zustand im Stillen. Der Weg dorthin: Jedes Ereignis (ein Forecast, ein Close) hat einen natürlichen Schlüssel (Datum+Symbol) und der Tick prüft die Existenz vor dem Schreiben. `advance_market_memory` und `sim-autopilot-tick` sind aus genau diesem Grund idempotent.

Eigenschaft 3 – Akkumuliert, setzt nicht zurück. Der Tick lädt den vorigen Zustand und baut DARAUF auf. `sim-autopilot-tick` lädt das Ledger, rotiert synthetische Regime und akkumuliert – genau die Regel des Capital Invariant aus SG-05 und von Market Memory aus SG-03. Das ist dieselbe Invariante, die zum dritten Mal in der Konstellation auftaucht, und das ist kein Zufall: Die Ehrlichkeit eines autonomen Systems IST seine Weigerung, sich zurückzusetzen. Ein Loop, der jedes Mal bei null beginnt, lernt nichts; ein Loop, der akkumuliert, ist das Einzige, das eine Kalibrierungs-Historie aufbauen kann, die etwas wert ist.

Eigenschaft 4 – Gate-geschlossen by construction. Der Tick handelt NIEMALS echtes Kapital. Das Capital Gate (`capital/broker/live_trading/automation` alle auf False) ist von `python3 -m xcap.control check` verifiziert. Ein Autopilot ist genau der Ort, an dem ein Trading-System seinen Besitzer tötet: Es läuft allein, und hätte es die Fähigkeit, echt zu handeln, würde ein Bug um 3 Uhr nachts das Konto leeren. Deshalb ist der Autopilot in XCAP sim-only, ohne Ausnahme, und `check` behauptet das bei jedem Durchlauf. Automatisierung und die Fähigkeit, echt zu handeln, sind zwei Dinge, die NIEMALS ohne eine bewusst getroffene menschliche Entscheidung koexistieren dürfen.

Wie das alles betrieben und gepanzert wird: Der Tick läuft über den Scheduler (in XCAP eine geplante Aufgabe, die `sim-autopilot-tick` aufruft, den akkumulierenden Befehl – NIEMALS `sim-run-agent`, den, der für Demos zurücksetzt). Das Verhalten ist von `tests/test_sim_autopilot_tick.py` GELOCKT: Wenn du den Autorun anfasst, bleiben diese Tests grün oder du hast die Integrität des Loops gebrochen. Und jeder Durchlauf endet mit einem `check`, der die Invarianten erneut bestätigt (keyless, Gate-geschlossen, Akkumulation). Das abschliessende Prinzip, das die ganze Konstellation besiegelt: Ein ehrlicher Loop ist einer, dessen Garantien nicht davon abhängen, dass jemand ihn bewacht, weil sie als Tests und Invarianten kodiert sind, die der Loop selbst bei jeder Runde verifiziert. Baue Loops, die sich weigern zu lügen, selbst wenn niemand zuschaut – das ist die einzige Automatisierung, der ein Research-System vertrauen kann.