Kernziel 03 · kontrollierte Verbesserung
Das Cockpit verbindet die drei Programmziele mit Arbeitspaketen, Messgrößen und Freigabetoren. Es zeigt fehlende Baselines ausdrücklich als offen, statt Fortschritt aus Dokumentmenge, Agentenzahl oder Backtestgewinn abzuleiten.
Delegierte Agenten- und Menschenentscheidungen werden getrennt dokumentiert: Admin: AP-Abnahmen und Reviews. Ohne exakt gebundenes Abnahme-Envelope bleibt „Annehmen“ gesperrt.
Programmauftrag
Strategien, Indikatoren, Regime-Logik und Stop-/Exit-Systeme werden als getrennte, falsifizierbare Bausteine erforscht.
Zugeordnete Pakete: AP-04, AP-05, AP-10, AP-11, AP-13
Arbeitsbereich öffnenJede Hypothese, jeder Versuch, jedes negative Ergebnis, jeder Fehler und jede Entscheidung bleibt auffindbar.
Zugeordnete Pakete: AP-00 bis AP-09, AP-12
Arbeitsbereich öffnenDas Gehirn erzeugt Verbesserungsvorschläge für Research, Engineering und Betrieb, darf Schutzregeln aber nicht selbst umgehen.
Zugeordnete Pakete: AP-10, AP-12 bis AP-16
Arbeitsbereich öffnenErst diese Trennung macht verständlich, warum viel Code vorhanden sein kann, obwohl ein Messpilot oder produktiver Einsatz noch nicht zulässig ist.
Code oder Dokument liegt vor. Das beweist noch keine fachliche Richtigkeit.
Automatisierte Tests und definierte Exit-Kriterien sind für die exakten Bytes grün.
Der reale Nutzen ist über den vorgesehenen Zeitraum gegen eine Baseline beobachtet.
Unabhängige Prüfung und eine berechtigte Agenten- oder Menschenentscheidung erlauben den begrenzten Einsatz; Auto-Deployment ausschließlich auf IG DEMO.
Beschlossene Betriebslogik
Agentenentscheidungen sind erlaubt, aber nur innerhalb ihrer freigegebenen Hülle. Providerrolle, Entscheidung und technische Ausführung bleiben getrennt, damit kein Modell seine eigenen Ergebnisse ungeprüft in einen Slot schreibt.
Kontingent: Claude session usage
Literatur- und Empirie-Research, Strategiefindung und Strategieaufbau. Keine AP-, Governance- oder DEMO-Deployment-Entscheidung.
Kontingent: ChatGPT/Codex usage
Kuration, Evidenzprüfung sowie AP- und DEMO-Entscheidungen innerhalb E-11/E-12. Vorgeschriebene unabhängige Prüfung bleibt unersetzbar.
Kontingent: none
Tests, Attestationen und exakt genehmigte Writes. Sie treffen keine fachliche Entscheidung und verbrauchen kein LLM-Kontingent.
Kontingent: openai_codex_chatgpt
VA-/R-U-Gates laufen über getrennte read-only Codex-Sitzungen und Actor-Identitäten mit deterministischen Hard-Gates. Das ist Rollen- und Sitzungstrennung, keine behauptete Providerdiversität.
Steuerungsboard
„Prüfbereit“ wird nur noch für technisch vollständige Pakete mit offener formaler Prüfung verwendet. Laufende Remediation oder Assurance erscheint als „in Umsetzung“. Stand des Abschlussaudits: v1.5.0 · 2026-08-01 08:30.
| AP | Lieferung | Phase | Abhängigkeit | Ehrlicher Stand | Formales Review | Exit | Bereits belegt | Fehlt noch | Nächste konkrete Aktion |
|---|---|---|---|---|---|---|---|---|---|
| AP-00 | Baseline, Entscheidungen und Fallauswahl | P0 | — | prüfbereit | kein Review Annahme gesperrt | PR-001 fachlich vorbereitet; kein offener Scopekonflikt. | Builder-Dossier v3 · Baseline-Dokument | rollengetrennter VA-02-/Paritätsnachweis · delegierte Agenten-Abschlussentscheidung | Den eingefrorenen Baseline-/Paritätsumfang in einer separaten read-only Codex-Sitzung prüfen und anschließend agentisch entscheiden. |
| AP-01 | Zielarchitektur und Trust-Zonen | P0 | AP-00 | prüfbereit | kein Review Annahme gesperrt | Architekturreview gegen Read-only, M-087 und Ring 4 bestanden. | Architekturdokument · operatives Architektur-Overlay · Builder-Dossier v3 | rollengetrenntes Architekturreview · delegierte Agenten-Abschlussentscheidung | Basisarchitektur und operatives Overlay bytegenau in einer getrennten read-only Codex-Sitzung prüfen. |
| AP-02 | Quelleninventar und Nur-Lese-Adapter | P0 | AP-01 | in Umsetzung | kein Review Annahme gesperrt | PR-002 bestanden; Quelllücken sichtbar statt still übersprungen. | Quelleninventar 1.3 und datensparsamer Nur-Lese-Laufzeitadapter · laufende Nur-Lese-Belege · historische Claude-W2/K2-Annahme wegen Rollen- und Evidenzkonflikt append-only unwirksam · Numerische E-03-Schwelle mit acht Orakeln rollengetrennt geprüft und als Klassifikationspolicy angenommen | frischer Quellen- und Cursor-Freeze für Inventar 1.3 · rollengetrenntes Missing/Changed/Permission- und Exact-Byte-Review · getrennter Schutz- und AP-02-Entscheid · Abhängigkeit AP-01 | Inventar 1.3 frisch einfrieren, getrennt prüfen und danach agentisch entscheiden; keine Nutzerbestätigung erforderlich. |
| AP-03 | Pilotstore, Identität und Historie | P0 | AP-01 / AP-02 | bestanden | angenommen Agentenentscheidung · 2026-07-19 21:55 | PR-003 und P-001–P-014 bestanden. | 19 exakt gebundene grüne Oracles · Codex-E-11-Review · append-only Acceptance-Envelope | nichts – formal angenommen | Pilotstore weiter beobachten; neue Abweichungen append-only dokumentieren. |
| AP-04 | Index, Negativwissen und Konflikte | P0 | AP-03 | bestanden | angenommen Agentenentscheidung · 2026-07-19 21:58 | P-015–P-018 bestanden; erste C2-/C4-Messwege erzeugen Daten. | 12 exakt gebundene grüne Oracles · C2/C4-Indexierungsoracles · Codex-E-11-Review · append-only Acceptance-Envelope | nichts – formal angenommen | C2/C4 über reale Pilotzeit messen; technische Abnahme nicht als Nutzenbeweis ausgeben. |
| AP-05 | Edge-Evidenzpaket und End-to-End-Fälle | P0 | AP-02 / AP-03 / AP-04 | prüfbereit | kein Review Annahme gesperrt | PR-008, P-019 und P-200 bestanden; fehlende Felder besitzen Owner und Folgeentscheidung. | Edge-Evidenzrenderer · Builder-Dossier v3 · End-to-End-Fallstruktur | formaler P-200-Abschluss · unabhängige R-S-/R-U-Paritäts- und Robustheitsevidenz | Historischen P-200-Fall schließen und eingefrorene Edge-Evidenz unabhängig reproduzieren lassen. |
| AP-06 | Schattenbeiträge und Agentenregeln | P0 | AP-03 | prüfbereit | kein Review Annahme gesperrt | PR-004 und P-020–P-023 bestanden. | E0-Schattenkanal · Agentenverträge · Builder-Dossier v3 | unabhängiges B-Review · autorisierte Abschlussentscheidung | PR-004 und P-020–P-023 durch eine unabhängige Rolle prüfen lassen. |
| AP-07 | Ring 4 und Entscheidungsschutz | P0 | AP-01 / AP-03 | in Umsetzung | kein Review Annahme gesperrt | PR-005 und P-100–P-110/P-114 bestanden. | Numerische E-03-Schwelle mit acht Orakeln angenommen · Genesis 1.5 bindet alle fünf aktuellen Schutzdateien bytegenau · Zwei Änderungen im 720-h-Fenster korrekt als K3 statt gesplittetem K2 klassifiziert · DEMO- und Ring-4-Suiten grün | rollengetrennte Exact-Byte- und Negativpfadprüfung des K3-Kandidaten · 24-Stunden-Karenz bis 25.07.2026 08:57:30 CEST · getrennter K3-Agentenentscheid und begrenzte Restart-Autorisierung · formale AP-07-Abnahme · Abhängigkeit AP-01 | K3-Prüfung jetzt ausführen; Entscheidung und DEMO-Neustart frühestens nach vollständig verstrichener Karenz. |
| AP-08 | Observability und Entkopplung | P0 | AP-02 / AP-03 / AP-07 | bestanden | angenommen Agentenentscheidung · 2026-08-01 08:10 | PR-006/PR-007 und P-111/P-202 bestanden. | 296,134261 reale gesunde Beobachtungsstunden und 1.147 geeignete Receipts · 7.201,307 Sekunden autorisierte isolierte Ausfallphase mit 24 Beobachtungen · Trading- und Research-Ursprungszustände einschließlich Main-PIDs unverändert · gesunder Pilot-Wiederanlauf und fortgeschriebenes Receiptledger · E-11-Risk-Operations-Entscheid accept über 23 exakte Bindungen | nichts – formal angenommen | AP-08 weiter beobachten; die Annahme startet weder AP-10 noch Produktion. |
| AP-09 | Automatisierte Abnahme und Pilot-Readiness | P0 | AP-02 / AP-03 / AP-04 / AP-05 / AP-06 / AP-07 / AP-08 / AP-11 | blockiert | kein Review Annahme gesperrt | Vollständiger Preflight grün; Messpilotfreigabe dokumentiert. | AP-09-Closure v1.1 bindet 49 Zusatzabhängigkeiten · Library-Migration besitzt Rollback- und Flat-Gates · direkter Aktivierungs-CLI ist gesperrt · deterministischer Wartungsexecutor verlangt eine gültige Ring-4-Restart-Autorisierung | AP-02 sowie AP-05 bis AP-07 formal geschlossen · AP-11 rollengetrennt abgeschlossen · gültiger Library-K3-Entscheid und installierte Policy · gültig akzeptierte Folge-Genesis · neues natives AP-09-Manifest mit finalem Bytebestand | AP-11 und die verbleibenden P0-Gates schließen; AP-10 nicht starten. |
| AP-10 | Messpilot über vier bis acht Wochen | P | AP-09 | in Umsetzung | kein Review Annahme gesperrt | P-201, alle übrigen P-Fälle und Go/Change/Stop-Entscheidung. | Messkatalog · Kollektor im Preflight-Modus · Startgate fail-closed · 0 angerechnete Messwochen | AP-09-Freigabe · AP-11 unabhängig abgeschlossen · exakte Startautorisierung · mindestens vier reale Messwochen · P-201 und Go/Change/Stop | Preflight gesund halten; Messzeit nicht vor AP-09 zählen. |
| AP-11 | Unabhängige Verifikation VA-01–03 | P/PB | eingefrorene Inputs / frische E-03-/Topologieevidenz / unabhängige Exact-Package-Rollen | in Umsetzung | kein Review Annahme gesperrt | Exakt gebundener Kandidat ist versiegelt, neue 86.400-Sekunden-Frist vollständig verstrichen, Post-Wait-W2/K2-Entscheidung und AP-11-Acceptance-Envelope liegen vor | v1.9 bindet 31 Dateien; öffentlicher Validator grün · 123 kombinierte Governance-Tests bestanden · Evidence- und Conflict-Rollenbefunde vollständig dokumentiert · keine Root-, Trading-, Broker-, Slot- oder LIVE-Mutation · Webstand v1.0.0 aktuell | frischer v2.0-Preseal-Kandidat · unabhängiger Exact-Package-Audit · PRESEAL_OK und Seal · volle neue 86.400-Sekunden-Frist · Post-Wait-W2/K2-Entscheidung · formales Acceptance Envelope | v2.0 getrennt bauen und die zehn im v1.9-Vertrag genannten Gates schließen; aus v1.9 weder PREPARE noch Seal ausführen |
| AP-12 | Pilotentscheidung und PB-Backlog | P | AP-10 / AP-11 | vorbereitet | kein Review Annahme gesperrt | Dokumentierte Entscheidung mit Evidenz und Ownern. | geschlossener Zukunftsphasenvertrag | AP-10 abgeschlossen · AP-11 abgeschlossen · reale Go/Change/Stop-Entscheidung | Vertrag geschlossen halten und nach AP-10/11 reale Evidenz binden. |
| AP-13 | Produktbaseline | PB | Pilot-Go | vorbereitet | kein Review Annahme gesperrt | Alle PB-Anforderungen und PB-Abnahmen bestanden. | PB-Inventar- und Promotionvertrag | Pilot-Go · vollständiges PB-Inventar · PB-Abnahmen · kontrollierte reale W1-Promotion | Erst nach Pilot-Go die Produktbaseline und erste kontrollierte Promotion ausführen. |
| AP-14 | Kontextprodukt und Agentenskalierung | A1 | PB | vorbereitet | kein Review Annahme gesperrt | Zwei Agentenrollen arbeiten mit nachweisbarem SIP-Kontext ohne Pflichtkernverstoß. | Kontextprofil-Entwurf · Pflichtkern-Assembler | PB · Owner-abgenommene Pflichtkerne · reales Auditfenster mit zwei Rollen | Nach PB sechs Pflichtkerne abnehmen und zwei Rollen real auditieren. |
| AP-15 | Kontrollierte Evolution | A2 | A1 | vorbereitet | kein Review Annahme gesperrt | Ein Destillat und je ein angenommener und abgelehnter Engineer-Vorschlag durchlaufen AT-14a–c. | Destillat- und Engineer-Grenzvertrag | A1 · realer Destillatpfad · angenommener AT-14-Vorschlag · abgelehnter AT-14-Vorschlag | Nach A1 die drei realen AT-14-Pfade auditierbar durchführen. |
| AP-16 | Zielausbau und Gesamtabnahme | Z | A2 | vorbereitet | kein Review Annahme gesperrt | Kein unerfülltes Ziel ohne dokumentierte Scope-Entscheidung. | Intake- und Vollständigkeitsvertrag | A2 · individuelle AT-12-Aufnahmen · alle acht Gesamtabnahmedimensionen | Nach A2 jede Anwendung einzeln aufnehmen und alle Gesamtdimensionen real belegen. |
Echtgeld-Governance · getrennt vom AP-Programm
Diese Pakete dokumentieren Kandidatenvorschläge aus DEMO, die alleinige menschliche Echtgeldentscheidung, Schutzgates, Zwei-Runner-Topologie und Credential-Closure. Agenten dürfen würdige DEMO-Kandidaten vorschlagen und den Betreiber benachrichtigen; was tatsächlich in Echtgeld gelangt, entscheidet ausschließlich der Betreiber. Die Projektion muss mindestens alle sieben Tage erneuert werden und wird danach sichtbar als stale markiert.
| Paket | Lieferung | Ehrlicher Stand | Bereits belegt | Fehlt noch | Nächste konkrete Aktion |
|---|---|---|---|---|---|
| WP-LIVE-01 | DEMO-Kandidateneignung und Vorschlags-Outbox | in Umsetzung nicht formal angenommen | Origin-v2-Vertrag und adversariale Tests vorhanden; aktuell null geeignete Kandidaten. | Producer-/Consumer-Migration, reale v2-Ledger und externer Chain-Head-Anchor. | Content-addressed Schema-/Producerarchive bauen und origin-native v2-Ereignisse erzeugen. |
| WP-LIVE-02 | Betreiberbenachrichtigung und Zustellbeleg | in Umsetzung nicht formal angenommen | Benachrichtigungs- und Proposal-Kern getestet; keine aktuelle Zustellung erzeugt. | Freigegebener Transport, Betreiber-Receipt-Kanal und externer Ledger-Anchor. | Transportvertrag ohne Credential-Offenlegung und mit exaktem Delivery-Receipt binden. |
| WP-LIVE-03 | Exakter menschlicher Echtgeld-Aufnahmeentscheid | vorbereitet nicht formal angenommen | Operator-Decision-Schema v2 und Validator vorhanden. | Keine v2-Entscheidung und keine exakte Operator-Session-Attestation vorhanden. | Erst nach einem würdigen DEMO-Kandidaten einen konkreten menschlichen Entscheid erfassen. |
| WP-LIVE-04 | Broker-Schutzstop und begrenzte Positionsgröße | vorbereitet nicht formal angenommen | Isolierter Schutzkandidat und Negativtests vorhanden. | Nicht in Runner oder Brokeradapter integriert; keine Broker-Null-Call-Evidenz. | Exakten Integrationspfad als wirkungslosen Ring-4-Kandidaten bauen und unabhängig prüfen. |
| WP-LIVE-05 | Fail-closed Konto- und Portfolioverlustgate | vorbereitet nicht formal angenommen | Isoliertes Verlustgate und Tests vorhanden. | Kontenweite Verlustquelle, persistenter Zustand und Runtimeintegration fehlen. | Minimierte kontenweite Risikoprojektion und Recovery-Vertrag implementieren. |
| WP-LIVE-06 | Kontenweites Cross-Process-Singleton | vorbereitet nicht formal angenommen | Isolierter Singleton-/Positionsgate-Kandidat ist getestet. | Exakter Runtime-Lockpfad, Berechtigungen und Multi-Prozess-Probe fehlen. | Fail-closed Lock-/Recovery-Design gegen beide Runner und alle Positionen prüfen. |
| WP-LIVE-07 | Ring-4/AP-08-Nachfolger für Zwei-Runner-Topologie | blockiert nicht formal angenommen | Projektionsanforderungen vollständig; AP-08-Risikoreceipt lautet CHANGE_REQUIRED. | Collector, geschützter Pseudonymisierungsschlüssel, frischer Snapshot und integrierte Schutzgates fehlen. | Collector und Key bereitstellen, danach frischen Snapshot und neue AP-08-Entscheidung erzeugen. |
| WP-LIVE-08 | Parallelbetrieb, Betreibersouveränität und Evidenzkette | in Umsetzung nicht formal angenommen | WP v1.4, Inventory v1.8, Ring-4 v1.6, PE-170 und PREPARE v1 dokumentiert. | Formatschema/-validator, PREPARE-Nachfolger, Seal, externer Anchor, E-03 und E-11 fehlen. | PREPARE-Nachfolger mit Zeitkorrektur und eigenständiger Formatvalidierung bauen. |
| WP-LIVE-09 | Notification-Credential rotieren und Secret-Store migrieren | blockiert nicht formal angenommen | Incident ist ohne Secretwert dokumentiert. | Widerruf, Rotation, Secret-Store-Migration und redigierter Zustelltest sind Betreiberaktionen. | Betreiber rotiert das Credential und liefert anschließend ausschließlich redigierten Closeout-Beleg. |
AP-12 bis AP-16
Die späteren Verträge sind implementiert und negativ getestet. Eine Phase öffnet trotzdem erst, wenn jeder hier aufgeführte Realnachweis exakt vorliegt. Fehlend bedeutet geschlossen – niemals automatisch bestanden.
Spätere Lieferung: signed Go/Change/Stop decision, benefit-effort balance and prioritized PB backlog
Zum Öffnen fehlen reale Nachweise
Abnahmebezug: SRS 12.2; AP-12
Spätere Lieferung: product baseline and first controlled real W1 promotion
Zum Öffnen fehlen reale Nachweise
Abnahmebezug: SRS 12.3; M-103; AP-13
Spätere Lieferung: two role-specific context profiles used without mandatory-core violation
Zum Öffnen fehlen reale Nachweise
Abnahmebezug: SRS 8; AT-04; AP-14
Spätere Lieferung: AT-14a-c evidence, one completed distillate path and accepted plus rejected engineer proposals
Zum Öffnen fehlen reale Nachweise
Abnahmebezug: M-097-M-099; AT-14a-c; AP-15
Spätere Lieferung: individually accepted intake contracts and complete SRS 13.3 mandate reconciliation
Zum Öffnen fehlen reale Nachweise
Abnahmebezug: S-025; AT-12; SRS 13.3; AP-16
Messkatalog
Die Messung beantwortet drei Fragen: Hilft das Gehirn bei besseren Entscheidungen? Lernt die Edge-Forschung schneller und ehrlicher? Spart das Ergebnis nachweisbar Aufwand oder verbessert es nach Freigabe den risikoadjustierten Produktionsnutzen?
Ist jede Aussage bis zu Quelle, Version, Versuch und Entscheidung zurückverfolgbar?
Werden widerlegte und inkonklusive Versuche genauso wiedergefunden wie positive?
Welche bekannten Pflichtinformationen fehlen im gelieferten Kontext?
Hat vorhandenes Wissen eine unnötige Wiederholung, einen Fehler oder eine falsche Freigabe verhindert?
Lässt sich ein behaupteter Befund aus den gebundenen Inputs erneut erzeugen?
Wurden unterschiedliche Erkenntnisse fälschlich als Dublette behandelt?
Bleiben Ursprungssysteme bei SIP-Ausfall vollständig arbeitsfähig?
Wurde eine schutzrelevante Änderung zu niedrig eingestuft?
Wie schnell wird eine nicht tragfähige Hypothese sauber beendet?
Sind auch schlechte, abgebrochene und fehlgeschlagene Varianten sichtbar?
Blieben ungesehene Daten bis zur festgelegten Prüfung wirklich ungesehen?
Wie viel des vorgeschriebenen Edge-Evidenzpakets ist belegt?
Verhindert vorhandenes Negativwissen redundante Versuche oder schärft es neue Hypothesen?
Wie gut sagen Researchurteil und Unsicherheit die echte Vorwärtsbewährung voraus?
Wie viel Arbeit wurde durch Wiederverwendung oder frühe Falsifikation gespart?
Was kostet ein belastbares Stop-/Change-/Go-Urteil?
Verbessert eine freigegebene Änderung das Ergebnis nach Kosten und Risiko?
Researchgewinn und realer Tradingnutzen sind verschiedene Ebenen. Der erste spart Fehlversuche und Reviewzeit. Der zweite darf erst nach einer kontrollierten Promotion gegen eine eingefrorene Produktionsbaseline gemessen werden.
Vermiedene Duplikate, frühere Falsifikation, weniger Fehlersuche und geringerer Provider-/Computeaufwand.
Verhinderte Fehlfreigaben, kleinere Drawdowns, weniger Drift und schneller erkannte BT/Live-Abweichungen.
Nur inkrementelle Forward-/Live-Wirkung nach Kosten gegen die vorab festgelegte Baseline.