Forschung
Unabhängiger Forscher · Wuppertal · ORCID 0009-0004-3834-8704 · Stand 30.09.2026
Ich arbeite an kombinatorischen Optimierungsproblemen, deren Ergebnisse sich mit Code nachrechnen lassen. Gesucht wird von KI-Agenten, die ich leite. Was eingereicht oder veröffentlicht wird, entscheide ich. Diese Seite hält fest, was davon draußen ist und in welchem Zustand, und darunter, wie gesucht wird.
Preprints
- Isufi, P. (2026). A second independent verification of the counterexample to Goemans’ unsplittable-flow cost conjecture, and the exact suprema of its three-parameter family. Zenodo. doi:10.5281/zenodo.22238190 · CC BY 4.0
Der Titel nennt die Prüfung die zweite. Das stimmt nicht: Vorher erschienen schon die Formalisierung von Ramos, Hulak und de Queiroz im Archive of Formal Proofs (22. Juli 2026) und die Prüfung von Santibañez-Leal auf Zenodo (25. Juli 2026). Außerdem bewies A. R. Caputo III am 23. Juli 2026 eine allgemeinere Fassung von Satz 2 des Preprints (TJC-LP/goemans). Auf Zenodo steht weiter die ursprüngliche Fassung. Stand 24.10.2026.
In Arbeit
- Certified beam-angle optimisation on open radiotherapy benchmarks. Exakte rationale Optimalitätszertifikate für die Wahl der Bestrahlungswinkel auf den offenen CORT-Fällen, dazu ein Prüfer, der den Ausschlussschritt im Browser nachrechnet. Vorgesehen für Physics in Medicine & Biology, Preprint in
physics.med-ph.
Rekordeinträge: das Grad-Durchmesser-Problem
Die Rekordtabelle von Comellas und Delorme (UPC Barcelona) führt zu jedem Paar aus Maximalgrad und Durchmesser den größten bekannten Graphen. Zwischen dem 13. und dem 27. August 2026 wurden zehn Zellen unter meinem Namen eingetragen. Beim Abruf am 30. September 2026 steht keine mehr unter meinem Namen. Am längsten hielt die unten aufgeführte Zelle (15,3); dort steht seit dem 25. September 2026 ein Graph mit 1.458 Knoten. Seitdem wurde sie noch zweimal überboten, zuletzt am 20. Oktober 2026 mit 1.620 Knoten (Abruf am 24. Oktober 2026).
| Grad | Durchmesser | Ordnung | Eingetragen | Vorgängerwert |
|---|---|---|---|---|
| 15 | 3 | 1.224 | 13. August 2026 | 1.215, C. Delorme, 1985 |
Der Graph entsteht aus dem 1.215-Knoten-Graphen des Vorgängereintrags, der unverändert bleibt, durch neun zusätzliche Knoten, die nur an Knoten mit freiem Grad hängen. Dharunish Yugeswardeenoo hat am 15. August 2026 unabhängig einen nicht isomorphen Graphen derselben Ordnung gefunden; die Tabelle führt beide.
Die anderen neun Zellen sind inzwischen überboten. Sieben davon, (15,2), (11,4), (13,4), (14,4), (15,4), (5,6) und (6,6), gingen an D. Yugeswardeenoo, zwei, (12,4) und (16,4), an eine Gruppe am Los Alamos National Laboratory mit dem Werkzeug URSA. Für (11,4), (13,4), (14,4), (15,4), (5,6) und (6,6) nennen die Detailseiten der Tabelle meinen Graphen als Ausgangspunkt des Nachfolgers, aus dem Knoten und Kanten gelöscht und neue Knoten angehängt wurden. Bei (15,2) baut der neue Eintrag auf einem eigenen Graphen von Yugeswardeenoo auf, bei (12,4) und (16,4) ist die Konstruktion unabhängig von meiner.
Wie geprüft wird
Jeder Fund wird vor der Einreichung zweimal geprüft. Einmal mit dem unveränderten Projektprüfer checker.py, der Ordnung, Maximalgrad und Durchmesser nachrechnet. Einmal mit einem eigenen Programm je Fund, das weder den Solver noch den Durchmessercode des Prüfers importiert und den Durchmesser von jedem Knoten aus selbst nachrechnet, meist per Breitensuche, bei einigen Funden mit Bitmengen. Beim Fund (15,3) prüft es zusätzlich, dass der Ausgangsgraph unverändert im Fund steckt und keine Kante umverdrahtet wurde.
Gerechnet wird durchweg in ganzen Zahlen. Beim Fund (15,3) ist die Knotenzugabe ein exaktes CP-SAT-Modell in OR-Tools; andere Funde entstanden auf anderen Wegen, (6,6) etwa durch eine Koordinatensuche. Die Durchmesserprüfung ist bei allen eine vollständige Prüfung über alle Knoten. An keiner Stelle, an der eine Entscheidung fällt, steht eine Fließkommazahl.
Jeder Fund liegt als eigenes Verzeichnis im Repository, auch die eigenen überholten Zwischenstände. Darin stehen die Kantenliste, der SHA-256 der kanonisch sortierten Kantenliste, das unabhängige Prüfprogramm und eine JSON-Datei mit Zelle, Ordnung und Konstruktionsweg. Wie genau der Suchlauf festgehalten ist, unterscheidet sich: Ein Teil der Funde nennt auch den Solver-Aufruf samt Zufallsstartwerten, die Versionen von Python und OR-Tools und den Commit des Repositorys. Beim Fund (15,3) ist der Entdeckungsweg nicht vollständig archiviert; das hält ein Nachtrag im selben Verzeichnis fest. Was ein Lauf nicht zeigt, steht in der JSON-Datei oder im Nachtrag, etwa dass ein Löschbudget erreicht und nicht ausgeschöpft wurde oder dass eine Rekonstruktion einer 1985 veröffentlichten Konstruktion deren Kennzahlen trifft, ohne dass Isomorphie zum Original belegt wäre.
Was das Kombinat ist
Im Kombinat suchen KI-Agenten nach Lösungen für exakt spezifizierte kombinatorische Probleme. Ein Kandidat wird erst zum Ergebnis, wenn ein unabhängiger Checker ihn annimmt. Zu den Problemen gehören LABS mit Binärfolgen minimaler Autokorrelationsenergie, degdiam, das Grad-Durchmesser-Problem, dessen Kandidat kein Graph ist, sondern ein Generatorprogramm, sortnet mit Sortiernetzen aus möglichst wenig Komparatoren und booleansens, Boolesche Sensitivität gegen den exakten reellen Grad.
core/loop.py rechnet einen Tick aus Eltern, Mutation, Bewertung und Archiv, core/sandbox.py sperrt fremde Kandidatenprogramme in bwrap mit rlimits, core/budget.py prüft vor jedem Modellaufruf das Budget. Die Checker bleiben absichtlich einfach: Standardbibliothek, exakte Arithmetik, keine Abhängigkeiten. Nichts im Suchpfad darf sich eine Bewertung selbst ausrechnen. Für die innere Schleife gibt es einen C-Zwilling desselben Urteils: am (16,3)-Rekordgraphen mit 1.600 Knoten und 12.800 Kanten schafft er 269 Bewertungen pro Sekunde mit einem Prozess je Kandidat und 442 über das Stromprotokoll. Der Python-Checker bleibt die Autorität und bestätigt jeden Kandidaten vor dem Archiv.
Agenten-Harnesse
Ein Harness ist das Gerüst aus Regeln, Skripten und Prüfschritten, in dem ein KI-Agent arbeitet. Mit meinen Harnessen verteile ich Aufgaben an mehrere Agenten und lasse ihre Ergebnisse in getrennten Läufen prüfen.
Eine Regelquelle für Claude, Codex und DeepSeek
Alle Agenten lesen dieselbe Datei. Sie liegt in ~/.agents/AGENTS.md; ~/AGENTS.md, ~/.claude/CLAUDE.md und ~/.codex/AGENTS.md sind Symlinks darauf, geändert wird nur das Original. Vier Coding-Regeln stehen dort. Denken vor Code heißt, Annahmen zu benennen statt stillschweigend eine Lesart zu wählen, und mir zu widersprechen, wenn es Grund dafür gibt. Simplicity First verlangt den kleinsten Code, der das Problem löst, ohne Abstraktion für Einmal-Code. Surgical Changes erlaubt nur Änderungen, die sich auf den Auftrag zurückführen lassen; fremder toter Code wird gemeldet, nicht gelöscht. Goal-Driven Execution übersetzt jeden Auftrag in prüfbare Erfolgskriterien und verlangt die Verifikation vor der Fertigmeldung.
Arbeitseinheit ist ein Claim mit eigenem Worktree
Im Haupt-Checkout wird nie gearbeitet, ein git switch dort zerschießt laufende Jobs. Ein Skript legt Branch, Worktree und Claim in einem Schritt an; erst der erfolgreiche Push gibt den Worktree frei, der Remote-Branch ist damit der Kollisionstest. Ein Scope gehört genau einem Claim, abgeschlossene bekommen status: done oder abandoned und bleiben liegen. Am 30.09.2026 zählt coordination/ 414 Claim-Dateien und 1.262 Job-Dateien; eine Job-Datei ist der Claim ihres eigenen Laufs.
Finder und Prüfer sind getrennt
$tick führt einen zielgebundenen Angriff aus und erzeugt Evidenz. Er verifiziert seinen eigenen Fund nie und endet mit einer typisierten Übergabe, einem Zeugen oder einem Beweis, oder mit einer datierten Notiz über Suchraum, Methode, Budget und Ausgang. Ein negatives Ergebnis zählt als Abschluss.
$tock prüft genau das übergebene, bytegenau gehashte Artefakt mit unabhängig geschriebenem Code und einer anderen Methode. Den Finder-Code zu importieren oder den beigelegten Replay-Befehl auszuführen genügt nicht. Mindestens eine Mutanten-Gegenprobe muss durchfallen. Erst danach wandert ein Fund nach records/. Beide Rollen starten mit demselben Lagebild aus lagebild.py: Sperren, Arme und offene Prüfungen, frisch aus dem Remote-Stand.
Für prüfkettenrelevante Änderungen gilt Autor ungleich Reviewer, mergefähig ist allein ein verdict: ok gegen den finalen Head. Die Checker, core/sandbox.py und core/budget.py sind unantastbar, problems/*/records/ ist append-only. Korrekturen kommen als Amendment daneben, das Original bleibt liegen.
Kostenbuch
Jedes Arbeitspaket trägt beim Claim-Abschluss eine Zeile ein; ohne Zeile gilt der Abschluss als unvollständig. Tokens misst kein Werkzeug im Kombinat zuverlässig, deshalb stehen dort keine. Das ist eine bewusste Lücke, Ersatzmaß sind Wandzeit und Codex-Runden. Nicht ableitbare Zellen tragen ein Fragezeichen, geschätzt wird nie. Fünf Zeilen aus dem September:
| Datum | Baustein | Wandzeit h | Subagenten | Codex-Runden | Ergebnis |
|---|---|---|---|---|---|
| 2026-09-05 | Hintergrund | 0,05 | ? | 0 | Vier Tabellenzellen nachgezogen, 8 von 10 eigenen Rekordzellen zu diesem Stand bestätigt. |
| 2026-09-08 | B1 | 9,0 | 3 | 3 (R3 ok) | Eigene Hypothese an der vorab gesetzten Latte falsifiziert, unabhängig repliziert. |
| 2026-09-08 | Hintergrund | 1,12 | 3 | 0 | Sieben Blockzahlen reproduziert, Gesamtschranke fremdcodebestätigt. |
| 2026-09-10 | Hintergrund | 48,4 | 0 | 5 (R5 ok) | Lambda-Gate auf vier weitere Stützstellen gezogen, Schlupf 0. |
| 2026-09-10 | B1 | 0,37 | 0 | 1 (R1 ok) | Vier als unerreichbar geführte Wachen mit Mutanten belegt. |
Die Spalte zählt nur Prüfrunden durch Codex; das Hintergrundpaket vom 08.09.2026 bekam zusätzlich ein inhaltliches Review durch Claude. Die 48,4 Stunden der vierten Zeile sind eine Kalenderspanne über drei Sitzungen, keine Rechenzeit. Was ein Modellaufruf kostet, steht in einer versionierten Preistabelle im Repo, mit Quelle und Datum in der Datei.
Wiederkehrendes läuft als systemd-Unit
Was regelmäßig laufen soll, läuft als systemd-Unit auf dem Server, nicht in einem Agenten. Am 30.09.2026 liegen im Betriebsordner 37 Service- und 28 Timer-Dateien. Drei der Service-Dateien sind Kopien der Vorlage notify-failure@.service, die eine Telegram-Meldung mit dem Namen der gefallenen Unit schickt; die übrigen 34 binden sie über OnFailure=notify-failure@%n ein. Ein Prüfskript listet Units ohne diesen Haken.
Dazu kommt eine Regel für Warteschleifen. Vom 10. bis 14.09.2026 lief ein until adb connect im Container ws-scrcpy vier Tage durch, weil niemand eine Abbruchgrenze gesetzt hatte. Seitdem bekommt jede Warteschleife ein timeout, auch in Container-Entrypoints und Subagenten-Skripten. Eine Schleife ohne Abbruchgrenze ist ein Befund.