Rekursive Selbstverbesserung, erklärt anhand eines Projekts, das sie tatsächlich umsetzt

„Rekursive Selbstverbesserung“ ist eine dieser Wendungen, die meistens verwendet wird, um ein Gefühl zu meinen. Ohne Mystik definiert, ist sie enger als das und interessanter: ein System, das sein eigenes nächstes Experiment vorschlägt, es ausführt und das Ergebnis nach einer im Voraus festgelegten Regel behält oder ausmustert, wobei die Ergebnisse in die nächste Runde einfließen. Die Rekursion ist keine Magie, und sie ist nicht unbegrenzt — sie ist eine Schleife mit einer Bewertungsfunktion, und ihre Qualität hängt vollständig davon ab, wie ehrlich diese Bewertungsfunktion angewendet wird. RSI-Jev, das offene Drittanbieterprojekt, das Jev-artige Entscheidungsmodelle für System One entwickelt, ist ein seltener Fall, in dem man die Schleife lesen kann, statt über sie zu streiten: jede Hypothese, jeder fehlgeschlagene Arm und jedes Release wird mit seinen Zahlen veröffentlicht, und das Repository wird Tag für Tag datiert. Das Modell, das diese Seite als durchgerechnetes Beispiel verwendet, ist RSI-Jev v6.0-VL, ein typisiertes 4B-Entscheidungsmodell, veröffentlicht am 2026-10-06, also innerhalb der letzten Woche. Es ist nicht das Jev von TypeSafe und nicht mit TypeSafe AI verbunden — die eigene Lizenzzeile des Projekts sagt genau das, und was wir bei OrcaRouter ausliefern, ist das andere, typesafe/jev-1.13, auf unserem systemone-Endpunkt.

Eine Klarstellung, bevor das Wort „selbstverbessernd" irgendetwas bewirkt, gefolgt von einem Datum. Das hier ist kein Modell, das sich selbst ohne Grenzen umschreibt, und nichts auf dieser Seite sollte so gelesen werden. Die Schleife, um die es geht, schreibt ein Rezept um: Sie schlägt eine Trainingsänderung vor, registriert, was sie von dieser Änderung erwartet, investiert GPU-Zeit und behält die Änderung dann entweder bei oder hält fest, warum sie verloren hat. Das Modell ist ein Qwen3.5-4B-Base-Turm mit trainierten Entscheidungs-Heads — eine feste Architektur, trainiert von einem festen Trainingsskript, wobei die Suche über Daten, Ziele und Phasen läuft. Die Schleife führt ihre eigenen Experimente durch und mustert ihre eigenen Champions aus. Menschen entscheiden, was es wert ist, gemessen zu werden. Und das Datum: v6.0-VL wurde am 2026-10-06 veröffentlicht, und seitdem hat das Projekt eine weitere Version veröffentlicht — die Linie bewegt sich etwa täglich, und die Zahlen auf dieser Seite sind die, die zu der hier genannten Version gehören, datiert dort, wo sie gelesen wurden. Das sollte man vorab sagen auf einer Seite, deren Thema eine Schleife ist, die immer weiterläuft.

Was der Begriff bedeutet, nüchtern ausgedrückt.

Zerlegt man den Ausdruck, bleiben drei Teile übrig, und alle sind gewöhnlich. Erstens ein Suchraum: die Menge der Dinge, die geändert werden könnten. Zweitens ein Bewerter: etwas, das sagt, ob eine Änderung geholfen hat. Drittens ein Protokoll: was versucht wurde, was geschah und was verworfen wurde. Ein System betreibt rekursive Selbstverbesserung, wenn der Output von Runde N der Input für Runde N+1 in allen drei genannten Bereichen ist, ohne dass ein Mensch jedes Mal den Suchraum neu herleitet oder den Schwellenwert neu festlegt.

Was die meisten Texte zu diesem Thema auslassen, ist der zweite Teil, und genau darin liegt die ganze Frage. Eine Schleife mit einem schwachen Scorer optimiert den Scorer. Sie wird eine monoton steigende Linie hervorbringen und ein System, das die Form seiner eigenen Prüfung gelernt hat. Dieses Versagen setzt weder Böswilligkeit noch einen Fehler voraus – es ist das, was standardmäßig passiert, wenn dieselbe Zahl sowohl auswählt als auch berichtet. Wenn Sie also eine Behauptung lesen, irgendein System verbessere sich selbst, lautet die nützliche Frage nie: „Um wie viel besser ist es geworden?“ Sie lautet: „Wer hat die Messlatte gesetzt, wann, und konnte sie sich verschieben, nachdem das Ergebnis gesehen wurde?“

Die populären Versionen dieses Konzepts – die, die heute für diesen Begriff ranken – sind überwiegend zukunftsgerichtet: Der Wikipedia-Eintrag beschreibt ein System, das seinen eigenen Code in Richtung einer „Intelligenzexplosion“ umschreibt, und die breitere Berichterstattung dreht sich meist darum, ob dieser Zeitrahmen näher oder weiter entfernt liegt als prognostiziert. Das ist ein legitimes Argument, und es lässt sich mit den Belegen, über die derzeit irgendjemand verfügt, nicht beantworten. Beantwortbar ist die kleinere Frage, nämlich ob eine geschlossene Schleife der oben beschriebenen Art schon jetzt gebaut und an ihre eigenen Regeln gehalten werden kann. Dafür schlägt ein Projekt mit öffentlichen Artefakten ein Jahrzehnt voller Spekulation, und darum geht es im Rest dieser Seite.

Geschlossen, nicht bloß iterativ: fünf Mechanismen

Eine Schleife ist nicht deshalb geschlossen, weil sie sich wiederholt. Viele automatisierte Pipelines wiederholen sich, ohne jemals geschlossen zu sein, denn eine Pipeline, die ihren Schwellenwert anpassen kann, nachdem sie das Ergebnis gesehen hat, tut etwas grundlegend anderes als eine, die dazu nicht in der Lage ist. Die Regeln von RSI-Jev selbst sind ungewöhnlich explizit, was diesen Unterschied betrifft, und sie lassen sich als Definitionen statt als Manifest lesen. Fünf von ihnen erledigen den Großteil der Arbeit.

Vorhersagen werden vor dem Lauf registriert. Eine Hypothese wird niedergeschrieben, zusammen mit der Zahl, die sie zu bewegen erwartet, und um wie viel, bevor GPU-Zeit aufgewendet wird. Eine Version, die ihre eigene Messlatte verfehlt, wird als Fehlschlag ausgeliefert, statt still und heimlich neu zugeschnitten zu werden. Das ist der Mechanismus, der verhindert, dass die Schleife zu einer Maschine zum Schreiben von Post-hoc-Erklärungen wird, und er kostet etwas Reales: Das Protokoll enthält Einträge, deren einziger Inhalt darin besteht, dass jemand nachweislich falsch lag.

Null-Böden werden gemessen, nicht angenommen. Das Team führt Arme aus, die nachweislich identisch mit der Kontrolle sind — verifiziert über Objektidentität, bevor auch nur GPU-Zeit anfällt — und die Streuung zwischen diesen Armen ist der Rauschboden. Eine Differenz, die kleiner ist als dieser Boden, ist kein Ergebnis, wie auch immer sie aussehen mag. Die eigene Messlatte des Projekts spiegelt dies wider: In der eigenen Suite liegt der Schwellenwert bei +0,006, bei einer Standardabweichung pro Seed auf einem einzelnen Benchmark von 0,011–0,016, sodass Einzel-Benchmark-Differenzen darunter keine Befunde sind. Das meiste Rauschen in diesem Geschäft wird gemessen, nicht statistisch.

Ein Held-out-Set ist verbraucht, sobald es gelesen wird. Jedes Release liest das Held-out-Set einmal, sodass zwei Releases weiterhin auf gleicher Grundlage verglichen werden können — und weil das Lesen es verbraucht, friert jedes Release den Vergleich des jeweils nächsten Releases ein. Es lohnt sich, die eigene Formulierung des Projekts unverändert beizubehalten: Das Held-out-Set „wird vom Training zurückgehalten, nicht von der Suche abgeschottet“. Es ist eine Prüfung auf Auswendiglernen, keine Garantie für Neuheit. Und die Suite-Zahl selbst weist eine Lücke auf, die das Projekt veröffentlicht hat: Eine interne Aufgabe überschnitt sich mit mehreren hundert Trainingszeilen, daher wird die Suite ab v6.0-VL ohne sie ausgewiesen — 0,770 — und der frühere Wert 0,764 von v5.0-VL wurde ohne sie als 0,763 neu ausgewiesen. Genau diese Neuausweisung ist der Punkt. Eine Zahl war aufgebläht, die Ursache wurde gefunden, und die Karte des älteren Releases wurde korrigiert statt unangetastet gelassen.

Fehlschläge werden ausgeliefert, einschließlich derer, die den eigenen Champion des Projekts zur Strecke gebracht haben.Die herausgestellten Zahlen des Repositorys, abgelesen am 2026-10-08, sind aus einem Guss: acht Releases in dreizehn Tagen und Hunderte Experimente, die mitsamt den Fehlschlägen dokumentiert wurden. Ein negatives Ergebnis wird als das Produkt behandelt. Der Leitfaden für Mitwirkende ist unverblümt, was den Grund angeht — der teure Teil einer Suche ist nicht, den Gewinner laufen zu lassen, sondern die Verlierer laufen zu lassen, daher entfernt ein sauber gemessenes negatives Ergebnis von außen einen Zweig und ist mehr wert als ein kleines positives Ergebnis.

Die Release-Kette ist das Projekt. Eine Karte pro Release, alle davon, dauerhaft auf dem Main-Branch. Jede Karte trägt die Zahlen ihres eigenen Releases, sodass Geschwindigkeit und Kalibrierung einer Version niemals die einer anderen überschreiben. Das Projekt nennt den Grund direkt: Diese Kette ist die einzige Möglichkeit zu sehen, ob sich eine selbstverbessernde Schleife verbessert. Alles andere – das Rezept, die Skripte, der gepinnte Stack – enthält nur das aktuelle Release, weil die umgekehrte Regel es unmöglich machen würde festzustellen, was aktuell ist. Ein veröffentlichter Checkpoint enthält seinen eigenen Code, damit alte Releases ohne alte Branches lauffähig bleiben.

Was die Disziplin kostet und was sie einbringt

Zwei Geschichten aus der Aufzeichnung sind das ehrliche Gegengewicht zu dem Wort „selbstverbessernd“, denn beide sind Fälle, in denen die eigenen Regeln der Schleife die Arbeit zugleich langsamer und besser machten.

Der erste ist der Bug hinter v1.0. Ihn zu finden, erforderte sieben registrierte Negativresultate. Jedes der sieben war eine Korrektur auf der Optimiererseite, die eine Trainingsinstabilität verringerte, ohne sie zu beseitigen, denn die Ursache war ein Präzisionsfehler, der nirgendwo in der Nähe des Optimierers lag – und die letztendliche Korrektur bestand aus einer einzigen Zeile. Keines der sieben war es wert, für sich allein veröffentlicht zu werden. Zusammen sind sie das, was die Ursache überhaupt erst auffindbar machte, und genau das ist das ganze Argument dafür, Negativresultate zu registrieren und aufzubewahren: Ihr Wert ist ein gemeinsamer, kein individueller.

Das Zweite ist weniger schmeichelhaft, und das Projekt veröffentlicht es trotzdem, in einer Fußnote. Ein früher Arm fiel bei genau einer Schutzprüfung durch – MMLU-Pro lag 0,026 unter der Messlatte, bei einem Grenzwert von 0,020 – und wurde als abgelehnt protokolliert. Der Laufverantwortliche erweiterte daraufhin den Grenzwert auf 0,030, mit der Begründung, dass MMLU-Pro eher ein Schutz gegen Vergessen als ein Ziel sei, und der Arm wurde mit vier frischen Seeds bestätigt und wurde zum nächsten Release. Die ursprüngliche Ablehnung blieb im Log stehen, zusammen mit dem Kommentar des Projekts, dass eine Messlatte, die nach der Einsicht in das Ergebnis verschoben wird, genau die Art von Sache ist, bei der ein Leser das Projekt dabei ertappen können sollte.

Diese Fußnote ist der nützlichste Absatz im Repository für alle, die diese Art von Behauptung in der Praxis einschätzen wollen. Eine verschobene Akzeptanzschwelle ist kein Beweis für böswillige Absicht – die angegebene Begründung ist vertretbar, und die erweiterte Schwelle musste anschließend vier frische Seeds überstehen. Aber eine Akzeptanzschwelle, die still verschoben wurde, ist ein Regelkreis, der nicht mehr geschlossen ist, und der Unterschied zwischen beidem besteht ausschließlich darin, ob dies schriftlich festgehalten wurde. Die allgemeine Regel, auf die sich das Projekt danach verständigt hat, ist diejenige, die es wert ist, auf andere Systeme übertragen zu werden: Ein Beinahefehler, der genau an einer Schutzabfrage scheitert, bekommt eine Diagnose und eine gezielte Reparatur, statt verworfen zu werden – und wenn die Reparatur fehlschlägt, wird er zu einer Sackgasse mit einem Eintrag.

Wie oft die Schleife falsch ist: vierzehn Setups, zwei behalten

Hier ist die Zahl, die man sich merken sollte. Mit dem Release, das Bilder liest, zählt das Projekt vierzehn Reinforcement-Learning-Setups und 63 belohnungstrainierte Arme. Zwei wurden behalten.

Jedes Setup wurde gegen eine überwachte Kontrolle bewertet, die auf denselben Elementen über dieselbe Anzahl von Schritten trainiert wurde, was der Vergleich ist, der die Zählung aussagekräftig macht — ein RL-Arm, der eine Baseline schlägt, mit der er nie hätte gleichziehen müssen, beweist nichts. Die lehrreichen Verluste, in den eigenen Worten des Projekts:

• Binäre-Korrektheit-RL — die Wahrscheinlichkeitsausgabe kollabierte auf 0 und 1. Wenn man die Handlung des richtigen Ratens belohnt statt die Ehrlichkeit der angegebenen Wahrscheinlichkeiten, treibt das eine Verteilung in die Extreme, und ein Entscheidungsmodell, dessen Konfidenz stets total ist, ist nutzlos für genau das, wofür Entscheidungsmodelle da sind.

• Proper-Score-RL, die Rekonstruktion der Laya-artigen Zielfunktion — bei 300 Schritten in Ordnung, bei 1.500 divergiert. Stabil, solange sie nicht viel bewirkte, und instabil genau dann, als sie anfing, von Bedeutung zu sein.

• RLCR — bei der Genauigkeit gleichauf, bei der Rohkalibrierung schlechter. Es brachte keinen Fähigkeitszuwachs und bezahlte dafür mit der einen Eigenschaft, für die das Modell überhaupt da ist.

• Bandit RLCD, bei dem nur das Ergebnis der gewählten Option offengelegt wird – nicht besser als überwachtes Training mit demselben Feedback. Das Projekt brachte hier seinen eigenen vorregistrierten Test zu Fall: Die Versuchsbedingung musste das überwachte Training bei mindestens zwei von vier Kalibrierungsmetriken übertreffen und gewann eine.

Der Gewinner – und der Grund, warum er gewonnen hat – ist der am besten übertragbare Befund auf der Seite. Es handelt sich um eine listenweise Belohnung – Rangqualität, gemessen über die Reihenfolge vieler separat bewerteter Kandidaten, statt jeden isoliert zu behandeln. Die Reranking-Trefferquote an erster Position stieg von 0,192 für das überwachte Elternmodell auf 0,308, mit Gewinnen und Verlusten in einem gepaarten Test. Die Erklärung des Projekts ist keine Tuning-Geschichte: Ein Trainingsziel pro Element bewertet jeden Kandidaten für sich, und kein einzelnes Label kodiert die Qualität einer Reihenfolge über Kandidaten. Wo die Belohnung etwas ausdrückte, was die Labels nicht ausdrücken können, übertraf RL das überwachte Training auf denselben Zeilen. Wo nicht, war das überwachte Training gleichauf.

Das verallgemeinert sich zu einer Regel darüber, wann diese Art von Loop überhaupt etwas finden kann. Mit einem Gold-Label zur Hand entspricht das erwartete Policy-Gradient-Update dem Gradienten eines überwachten Verlusts — der eigenen Formulierung des Projekts —, sodass ein „RL-Arm“, der anhand gelabelter Entscheidungen bewertet wird, in Wahrheit ein Loss-Design-Arm ist. Und Änderungen auf Loss-Ebene bewegten die interne Suite um höchstens 0,002, während neue Daten sie um 0,13 bewegten. Zusammen gelesen: Die Hebelwirkung des Loops lag nie in der Zielfunktion. Sie lag darin, was gemessen wurde und was eingespeist wurde.

Was die ehrliche Antwort auf eine Frage ist, die ein Leser zu Recht stellt. RL-Setups werden an anderer Stelle als Belege für Selbstverbesserung im Allgemeinen angeführt; hier sind sie Belege für eine einzelne Schleife bei Entscheidungsaufgaben. Das Listwise-Ergebnis ist ein einzelner Seed, und das Projekt sagt das auch: Der gepaarte Vergleich zwischen RL und überwachtem Lernen wurde mit einem anderen Parent durchgeführt als dem, auf den das Release ihn angewendet hat, und dieses Release „hat keine gematchte überwachte Kontrolle“. Ein Befund, der mit diesem Vorbehalt versehen ist, ist mehr wert als einer ohne ihn, und deshalb verallgemeinert die Seite, die Sie gerade lesen, ihn nicht.

Wo der Mensch sitzt

Das Projekt ist explizit, und das Explizite ist der interessante Teil: Die Schleife führt ihre eigenen Experimente durch und mustert ihre eigenen Champions aus, aber sie entscheidet nicht, was es wert ist, gemessen zu werden, und sie bemerkt nicht von selbst, wenn eine Zahl technisch wahr und praktisch irreführend ist. Das machen Menschen.

Zwei der eigenen Regeln des Projekts existieren, weil jemand Widerstand geleistet hat. Der MMLU-Pro-Guard wurde erweitert, statt einen Beinahe-Treffer zu verwerfen. Die Seed-Anforderung skaliert jetzt mit der Effektstärke, statt vier Seeds für jeden Unterschied aufzuwenden – denn der Bestätigungs-Seed, die eine Zahl, anhand derer ein Arm nicht ausgewählt wurde, ist der tragende, und Rechenleistung für Unterschiede aufzuwenden, die man bereits sehen kann, bringt nichts. Eines der Releases in der Kette begann als Weigerung, einen Arm fallen zu lassen, der an einem Guard gescheitert war. Das Projekt würdigt die Personen, die dieses Feedback geschickt haben, namentlich in den Danksagungen.

Also beschreibt „selbstverbessernd“ hier die Mitte der Schleife, nicht ihre Gesamtheit. Die Schleife ist eine Suche, die abläuft, ohne dass ein Mensch die Kurbel dreht. Der Mensch steht nach wie vor oben in der Schleife, wo er das Ziel wählt, und unten, wo er das Ergebnis kritisch liest – und genau diese Anordnung verhindert, dass die Schleife zu einer Maschine wird, die ihre eigenen Präferenzen bestätigt. Jede Darstellung rekursiver Selbstverbesserung, die diesen Platz auslässt, beschreibt ein anderes System als dieses – und wahrscheinlich ein hypothetisches.

Was die eigenen Zahlen des Projekts nicht zeigen

Die Disziplin oben ist nur dann eine Beschreibung wert, wenn ihre Grenzen im selben Atemzug genannt werden, und RSI-Jevs Bilanz nennt sie von selbst.

• Es ist ein Projekt, jeweils eine Modellgröße, ein Seed. Der veröffentlichte Checkpoint stammt von einem einzelnen Seed und wurde im Voraus als primär festgelegt, statt danach ausgewählt zu werden, am besten abzuschneiden. Die RL-Evidenz ist ein Seed.

• Es sind Entscheidungsaufgaben, keine Generierung: eine Ja/Nein-Frage, eine Auswahl einer von k Optionen oder eine Bewertung anhand eines Rubrikfragenkatalogs über ein Dokument, einen Chat oder ein Bild, beantwortet in einem einzigen Vorwärtsdurchlauf mit einer kalibrierten Wahrscheinlichkeit pro Option. Es wird nichts generiert, es gibt also keine Reasoning-Tokens zu verbrauchen. Was die Schleife hier zeigt, ist, dass sie einen Scorer dieser Form verbessern kann.

• Ein Teil davon ist allein aus dem Repository nicht reproduzierbar. Die Trainingskorpora und die Policy-Development-Sets sind nicht öffentlich, und das Projekt sagt das in der Release-Karte unverblümt: „Die Stages können nicht allein aus diesem Repository erneut ausgeführt werden.“ Ein Corpus-Builder benötigt etwa 96 GB Arbeitsspeicher und wurde nicht durchgängig erneut ausgeführt.

• Nicht alles ist überhaupt überprüfbar. Die interne Suite wurde nie vollständig zurückgehalten. Von den fünfzehn Benchmarks liefern zehn in irgendeiner Form Trainingsdaten, also ist keine dieser Zahlen Zero-Shot — das Hold-out-Set ist der Vergleich, der zurückgehalten wird, und es ist der einzige.

Und die externen Teile haben ihr eigenes Narbengewebe. Ein Audit nach einem Release fand grob tausend Einträge der Testzeilen des öffentlichen Benchmark-Kits in den Trainingskorpora – etwa 0,3 % der Zeilen des Kits, wobei der größte Einzelbeitrag ein paar hundert Zeilen aus einer Quelle umfasste. Ohne sie neu bewertet, verschiebt sich der Index um höchstens 0,04. Diese Korrektur wurde in der Karte des nächsten Releases veröffentlicht, statt still angewendet zu werden, unter der Regel, die das Projekt als „keine Kontamination, geprüft statt behauptet“ angibt. Es ist eine Regel, die sie eine Zahl kostet, und das ist die einzige Art von Regel, die es wert ist, zu haben.

Wo es tatsächlich ausgeführt werden kann – und wo nicht

Hier wird nichts von OrcaRouter bereitgestellt. Unser Katalog enthält keine RSI-Jev-ID und keine Modellkarte dafür, und es wird auch keine geben, bis jemand es bereitstellt. RSI-Jev wird aus seinem eigenen Repository installiert und betreibt seinen eigenen Server, der die Jev API spricht: Du richtest einen vorhandenen Jev-Client darauf aus und änderst die Basis-URL. Es läuft auf Linux, Windows und macOS, auf einer CUDA-GPU, Apple Silicon oder einer einfachen CPU.

The one model we do host is the other side of that contract. TypeSafe's Jev 1.13, which we serve as typesafe/jev-1.13, is the commercial decision model whose request and answer shapes RSI-Jev reproduces, and it is reached on our dedicated systemone endpoint rather than through the chat-completions shape. That is the whole relationship, and it is a structural one rather than a quality claim: one is a hosted commercial model on a vendor's endpoint, the other is a checkpoint you download and serve yourself. Nobody has run an independent head-to-head between them, and this page is not going to declare a winner from two different harnesses.

Wenn Sie ein Entscheidungsmodell wie dieses hinter eine Anwendung legen wollen, ist die Routing-Frage von der Modell-Frage getrennt, und sie ist der Teil, der darüber entscheidet, ob das Experiment überhaupt lohnt.eine API für über 200 Modelle mit 0 % Aufschlag — der Listenpreis des Anbieters wird durchgereicht, sodass eine Preisänderung eines Anbieters am selben Tag Ihr Preis ist — plus automatisches Failover und eine Routing-DSL, um mehrere Modelle in einem Aufruf zu kombinieren. Bei einem Loop-Modell, das Sie noch nicht über eine allgemeine API aufrufen können, ist das auf eine ganz bestimmte Weise relevant: Es bedeutet, dass die alternativen Kandidaten, gegen die Sie es benchmarken würden, bereits hinter einem einzigen Schlüssel liegen und der Vergleich eine Konfigurationsänderung statt einer zweiten Integration ist.

Der Teil, den es sich zu behalten lohnt

Der Grund, über rekursive Selbstverbesserung durch ein Projekt wie dieses zu schreiben – statt durch das Argument, ob sie zu etwas Dramatischem führt –, ist, dass die Regeln der Schleife der übertragbare Teil sind und die Spekulation nicht. Registrierte Vorhersagen, gemessene Null-Untergrenzen, verbrauchte Hold-out-Sets, veröffentlichte Fehlschläge, eine unveränderliche Release-Kette: Nichts davon ist eine Eigenschaft einer Superintelligenz. Sie sind Eigenschaften eines Labors, das sich entschieden hat, überprüfbar zu sein, und sie stehen jedem Team zur Verfügung, das heute automatisierte Suche betreibt, in jedem Maßstab, mit jedem Modell.

So gelesen ist die interessante Behauptung in RSI-Jevs Aufzeichnung nicht die Punktzahl. Sie besteht darin, dass das eigene Hauptbuch des Loops besagt, dass er weitaus häufiger falsch als richtig lag – zwei beibehaltene Rezepte aus vierzehn Setups, sieben Negativergebnisse, um einen einzeiligen Bug zu finden, ein Balken, der sich bewegte und aufgeschrieben wurde – und dass das Projekt das Hauptbuch veröffentlicht hat. Ein Anstieg von 38,38 auf 46,24 auf einem öffentlichen Index in einem einzigen Release ist eine Kuriosität ohne die Fehlschläge daneben. Die Fehlschläge sind es, die der Zahl Bedeutung verleihen.

Was die ehrliche Position zum Begriff selbst ist. Die Frage ist nicht, ob ein System sich selbst verbessern kann. Sie ist, ob die Verbesserung durch etwas gemessen wird, das hätte Nein sagen können. Wo diese Trennung real und schriftlich festgehalten ist, ist die Schleife lesenswert. Wo sie es nicht ist, ist eine steigende Linie eine Beschreibung eines Bewerters, nicht eines Systems, das besser wird – und keine noch so große Rekursion behebt das.