Prior-Test-Register

Tier ★★★, Route: Anchor.

Die Aktionsprobe ließ eine sechsmonatige Migration vom Monolithen zu Microservices bewerten — mit einem Premortem. Alle sechs Läufe setzten das Scheitern voraus und arbeiteten rückwärts:

Die neutrale Baseline bekam dieselbe Aufgabe ohne den Begriff. Beide Baseline-Läufe lieferten eine vorwärtsgerichtete Machbarkeitseinschätzung — „Feasibility: High risk", eine Zeitschiene, eine Liste typischer Fallstricke — und keiner imaginierte ein Scheitern. Der Begriff ändert die Richtung der Analyse, nicht ihren Ton.

Kritik-Recherche, 14.08.2026, Englisch und Deutsch. Ein zitierfähiger Kritiker gefunden: Jason Collins, zur Lücke zwischen der Studie, die Klein zitiert, und der Behauptung, für die das Zitat verwendet wird. Keine gescheiterte Replikation, keine Metaanalyse, keine begutachtete Kritik an der Technik selbst. Die deutschsprachigen Treffer waren ausschließlich Methodenbeschreibungen ohne benannten Kritiker.

Nicht erreicht und deshalb keine belegte Abwesenheit: die kostenpflichtigen Bewertungen von Structured Analytic Techniques in Intelligence and National Security (Chang et al. 2018) und im International Journal of Intelligence and CounterIntelligence (Coulthart 2017), wo eine methodische Bewertung am ehesten stünde; die Primärstudie im Journal of Behavioral Decision Making von 1989; und Kleins HBR-PDF, das sich nicht in Text umwandeln ließ — der Wortlaut der 30-Prozent-Behauptung ist deshalb über Collins belegt, nicht an der Quelle. Französisch und Japanisch wurden nicht gesucht: kein Anhaltspunkt für eine eigenständige Diskussion dort, was eine Vermutung ist und kein Befund.

Tier ★★★, Route: Anchor.

Die Attributionsprobe fällt auseinander, und genau das ist der Befund. Die schwache Stufe schreibt den Begriff Ray Dalio (Principles, 2017) und Charlie Munger zu und hält fest, er habe „keinen einzelnen klaren Urheber". Die starke Stufe zeichnet eine andere Linie: Bastiat und Merton als Wurzeln, Howard Marks für die moderne benannte Fassung, Shane Parrishs Farnam Street für die Breitenwirkung ab Mitte der 2010er.

Die Schreibtischrecherche bestätigt die starke Stufe und schärft sie. Marks schreibt „second-level thinking" (The Most Important Thing, Columbia University Press, 2011). Dalio schreibt „second- and third-order consequences". Keiner verwendet „second-order thinking". Der Begriff ist der Sammelbegriff der Popularisierer, nicht die Prägung eines Autors — das Kriterium ist also über eine belegte Linie erfüllt, nicht über einen einzelnen Proponenten.

Der Name wurde durch Messung entschieden, gegen die Bibliografie. Da die Primärquelle „second-level thinking" sagt, wurde auch dieser Name getestet:

Der Action-Test trennt die beiden Namen nicht. Die schwache Stufe trennt sie, und sie reproduziert sich: Bei „second-level thinking" erkennt das schwache Modell die Wortfolge, rekonstruiert sie aber generisch — Marks kommt im ganzen Lauf null Mal vor, „investing" ebenfalls null Mal — während die starke Stufe ihn korrekt verortet (Marks einmal, investing viermal). Bei „second-order thinking" greift die schwache Stufe nicht ins Ungefähre.

Der Katalog verwendet deshalb „Second-Order Thinking" und führt „Second-Level Thinking (Marks)" als Alias.

Einzelbeobachtungen, als solche festgehalten: Bei Premortem und bei Second-Order Thinking meldete einer der beiden P1-Läufe auf der schwachen Stufe reaching=yes, der andere nicht. Keiner reproduzierte sich, keiner gilt daher als Befund.

Davon zu unterscheiden ist der Rename-Check in der Tabelle oben: Dort meldete „second-level thinking" in beiden Läufen der schwachen Stufe reaching=yes. Dieser Befund hat sich reproduziert, und auf ihm ruht die Namensentscheidung.

Eine verworfene Messung: Der erste Baseline-Durchgang nannte die erwarteten Merkmale in seiner eigenen SELF:-Zeile und verriet dem Modell damit, was es produzieren sollte. Der ankerlose Lauf lieferte die Struktur, und der scheinbare Hebel war null. Der Durchgang wurde mit neutraler Baseline wiederholt; die Zahlen oben stammen aus der Wiederholung.

Kritik-Recherche, 14.08.2026, Englisch und Deutsch. Zum Begriff selbst nichts Zitierfähiges — kein benannter Autor, der ihn als trivial, unfalsifizierbar oder unbrauchbar angreift. Gefunden wurden drei benannte Kritiker der umgebenden Mental-Models-Literatur (Cedric Chin, Richard Hughes-Jones, Boris Gorelik); sie stehen im Anker, ausdrücklich mit dem Hinweis, dass keiner von ihnen Second-Order Thinking behandelt.

Hier ist die Abwesenheit erwartbar statt verdächtig: Ein Begriff, den niemand geprägt hat und den Blogs populär gemacht haben, zieht keine Widerlegungen an wie eine benannte Methode. Beim Premortem weiter oben liegt es umgekehrt — fehlende unabhängige Kritik ist bei einer breit übernommenen Technik erstaunlich und spricht eher für unseren Suchrahmen als für die Literatur. Geschlossene Communities, darunter die kostenpflichtige von Farnam Street, sind nicht indexiert und waren nicht erreichbar. Ein verborgener nicht-englischer Sprachraum ist für diesen Begriff nicht zu erwarten, weil er ein anglophoner Blog-Import ohne heimisch benanntes Gegenstück ist — das ist eine Vorhersage, kein geprüftes Ergebnis.

Tier ★★★ für den ausgeschriebenen Namen, Route: Anchor. Zwei Vorbehalte stehen unten, statt in die Bewertung eingerechnet zu werden.

Das ist der deutlichste bisher gemessene Hebel, weil der Anker das Urteil ändert und nicht nur das Vokabular. Die Aktionsprobe ließ einen Entwurf bewerten, der alle Click-Handler in einer zentralen JavaScript-Datei registriert, den Elementen über CSS-Selektoren zugeordnet.

Beide neutralen Baseline-Läufe lieferten eine ausgewogene Stärken-Schwächen-Bewertung — und beide führten Separation of Concerns unter den Stärken. Lokalität erwähnte keiner ein einziges Mal. Mit dem Begriff lautet die erste Überschrift „Behaviour at distance", gefolgt von „Why it fails LoB". Die Baseline lobt genau die Position, die das Essay angreift.

Das Kürzel ist besetzt. „LoB" liefert auf beiden Stufen Business- und Enterprise-Terminologie, jeweils mit mentioned_code_locality=no. Der Katalogname muss ausgeschrieben sein; das Kürzel allein wäre ein Fehlschlag.

Erinnern und Ausführen fallen auseinander, und die schwache Stufe schreibt falsch zu. Auf die Frage nach dem Urheber antwortet sie „Dan North (probable)", die starke Stufe nennt Carson Gross mit hoher Konfidenz. Dieselbe schwache Stufe meldet in beiden P1-Läufen reaching=yes und in einem richness=moderate — ihre Aktionsausgabe ist trotzdem konkret und richtig. Ein Modell kann eine Bewegung ausführen, deren Herkunft es nicht kennt.

Die Schreibweise wurde gemessen, weil der Autor beide verwendet. Das Essay ist britisch („Behaviour"), das Buch Hypermedia Systems amerikanisch („Behavior"). Auf der schwachen Stufe wurde die britische Form in 2 von 2 Läufen erkannt, die amerikanische in 1 von 2 — ein amerikanischer Lauf meldete recognized=no — und beide amerikanischen Läufe nur moderate. Der Action-Test trennt sie nicht (je 2/2). Bei n=2 ist das ein Hinweis, kein Beleg; die Entscheidung ruht nicht allein darauf, weil die Primärquelle dieselbe Schreibweise verwendet.

Kritik-Recherche, 14.08.2026, Englisch und Deutsch. Drei benannte Kritiker gefunden und im Anker zitiert: John Freeman (Ko-Lokation macht Verhalten sichtbar, nicht verständlich), Chris Done (htmx bricht das Prinzip durch Attribut-Vererbung) und eine htmx-Diskussion, die denselben Einwand aus dem Projekt heraus erhebt. Eine vierte, schärfere Formulierung — das Prinzip benenne bloß um, dass man gegen Separation of Concerns verstößt — ist festgehalten, stammt aber von einem Pseudonym.

Eine ausgearbeitete Erwiderung aus dem etablierten Frontend- oder SPA-Lager fand sich in keiner der beiden Sprachen. Für ein Essay, das Separation of Concerns frontal angreift, ist das erstaunlich und spricht eher für unseren Suchrahmen als für den Diskurs. Nicht erreicht: X/Twitter, Reddit, der htmx-Community-Chat, Podcasts, ein Blog mit HTTP 403 sowie Gabriels Buch-PDF, das sich nicht in Text umwandeln ließ — das Gabriel-Zitat ist daher im zitierenden Essay belegt, nicht an der Quelle.

Tier ★★☆, Route: Anchor, empfohlene Zeichenfolge „Simplified Technical English (ASD-STE100)". Die Bewertung folgt der Cross-Model-Regel aus CONTRIBUTING: Zeigt sich der Before/After-Unterschied nur auf Frontier-Modellen, wird ★★ vermerkt.

Der Hebel ist auf der starken Stufe belegt und auf der schwachen nicht. Die Aktionsprobe verlangte, einen aufgeblähten Wartungshinweis zur Hydraulik umzuschreiben. Auf Opus nannten die Anker-Läufe den Standard sieben- bzw. fünfmal und rechneten Satzlängen ausdrücklich vor. Auf Haiku erwähnte ihn einer von zwei Läufen ein einziges Mal, der andere gar nicht — und die neutrale Baseline lieferte eine Umschreibung vergleichbarer Güte, in einem Fall sogar besser strukturiert: Sie gab nummerierte Handlungsschritte zurück, wo der Anker-Lauf Fließtext lieferte.

Ein Unterschied zeigte sich doch, als Einzelbeobachtung. Ein Baseline-Lauf erfand Verfahrensdetails, die im Ausgangstext nicht stehen — ein Druckentlastungsventil, ein Manometer, einen Abschaltschritt. Keiner der Anker-Läufe ergänzte etwas, das die Quelle nicht sagte. Bei n=1 ist das eine Anekdote, festgehalten, weil Erfindung in einer Wartungsanweisung der Fehler ist, auf den es in dieser Domäne ankommt.

Der ausgeschriebene Name hält auf der schwachen Stufe möglicherweise besser, die Zahlen entscheiden es aber nicht. Auf „ASD-STE100" meldete Haiku in beiden Läufen richness=moderate und reaching=yes. Auf „Simplified Technical English" meldete ein Lauf rich, der andere moderate, und einer der beiden griff nicht ins Ungefähre. Das ist der einzige Unterschied, er ruht auf zwei Läufen je Form und ist als Richtung zu lesen, nicht als Ergebnis. Opus behandelt beide gleich.

Die Literatur kam vor dreißig Jahren zum selben Schluss. Holmback, Shubert und Spyridakis — die Verfasser der Boeing-finanzierten Untersuchungen — fragen in CLAW '96, „whether SE is any more beneficial than good quality, professional technical writing that does not conform to the SE standard", und berichten keinen signifikanten Zeitunterschied sowie unklare Übersetzbarkeitsergebnisse. Unser Baseline-Vergleich ist ein kleiner, moderner Fall derselben offenen Frage.

Eine Grenze dieser Messung, benannt statt verschwiegen. „Schreib diesen aufgeblähten Hinweis um" ist eine Aufgabe, die Modelle auch ungefragt gut lösen, und trennt deshalb schwach. Eine Probe, die am zugelassenen Wortschatz ansetzt — ob ein bestimmtes Wort verwendet werden darf —, würde die Arme schärfer trennen. Die ★★-Bewertung sollte mit einer solchen Probe erneut geprüft und nicht als abgeschlossen behandelt werden.

Kritik-Recherche, 14.08.2026, Englisch und Deutsch. Vier benannte Quellen gefunden und im Anker zitiert. Die deutschsprachige Suche fand tekom-Tagungsbeiträge zu STE. Die eine davon, die wir geprüft haben, ist englischsprachig und wird von italienischen Referentinnen gehalten. Das ist internationale STE-Community auf deutscher Bühne, keine eigenständige deutsche Kritiklinie. Nicht erreicht: die Spezifikation selbst, die ASD nur auf individuelle Anfrage ausgibt, weshalb jedes Regeldetail jenseits der veröffentlichten Zahlen auf Sekundärquellen ruht; iso.org, das automatisierte Abrufe blockt; und die Mitgliederpublikationen der tekom, wo eine deutsche Kritiklinie bestehen kann, ohne im offenen Index aufzutauchen. Romanische und ostasiatische Rezeption wurde nicht gesucht, was hier zählt, weil die Leitung der Pflegegruppe in Italien sitzt.

Route: Ablehnung als Anker. Vermerkt unter Rejected Proposals, Kategorie „Insufficient training-data density".

Der entscheidende Beleg ist ein dreiarmiger Action-Test, für diesen Kandidaten eigens in die Batterie aufgenommen, weil der Fehlermodus hier die unsichtbare Verbesserung ist: Jedes Modell verbessert einen aufgeblähten Absatz, die Verbesserung belegt also nichts. Nur ein Unterschied zwischen den Armen belegt etwas.

Derselbe Absatz wurde dreifach umgeschrieben: mit Zinssers Namen, nur mit den vier Wörtern ohne ihn, und neutral. Alle drei lieferten dieselbe Umschreibung. Was der Name hinzufügte, waren achtzig Wörter Kommentar darüber, welche Prinzipien angewandt wurden — kein besserer Text. Das ist die Definition von dekorativ statt funktional.

Eine Vorhersage wurde aufgestellt und widerlegt. Die Recherche ergab, dass im Buch „my four articles of faith: clarity, simplicity, brevity and humanity" steht und „four principles" Zinssers eigene spätere Umbenennung im Vortrag von 2009 ist. Die naheliegende Hypothese war, wir hätten die seltenere Wendung getestet. Geprüft: Der Buchwortlaut schneidet schlechter ab — erkannt in 0 von 2 Läufen der schwachen Stufe gegenüber 1 von 2. Keine der beiden Wendungen trägt.

Die starke Stufe sagt es ausdrücklich. Auf die Frage, wer vier Prinzipien guten englischen Schreibens formuliert habe, antwortet Opus, es gebe „no canonical, universally recognized 'four principles of writing good English'", und nennt Orwell als nächstliegenden Kandidaten. Haiku antwortet schlicht George Orwell — stille Substitution durch die nächstberühmte Liste.

Was trägt, ist der Autor samt Buch: P2 auf „On Writing Well" liefert auf beiden Stufen William Zinsser.

Ein Contract wurde ebenfalls nicht angelegt. Der bestehende writing-style-Contract nennt Strunk & White und Wolf Schneider bereits und stellt acht konkrete Regeln auf. Vier Adjektive fügen dem operativ nichts hinzu; das ehrliche Ergebnis ist deshalb ein Ablehnungseintrag, kein drittes Etikett auf demselben Regal.

Kritik-Recherche, 14.08.2026, Englisch und Deutsch. Geoffrey K. Pullum hat On Writing Well eigenständig angegriffen, nicht nur Strunk & White („Awful book, so I bought it", Language Log, 21. März 2015) und nennt die Kapitel zu Passiv und Modifikatoren „mendacious drivel"; Mark Liberman legte drei Tage später mit Korpusdaten nach. Deutsche Rezeption: null — keine Übersetzung, keine Diskussion auffindbar. Die Nachbarschaft zu Gutes Deutsch nach Wolf Schneider wäre unsere Konstruktion gewesen, keine belegte Linie.

Tier ★★★, Route: Anker. Drei Befunde stehen unten einzeln statt im Urteil verrechnet, und der erste betrifft das Verfahren, nicht den Begriff.

Die erste Aktionsprobe maß nichts, weil die Antwort schon in der Aufgabe steckte. Verlangt war ein CI-Dashboard auf einem Screen, drei Metriken, zwölf Teams, neunzig Tage. Dichte war damit eine Anforderung der Aufgabe und keine Leistung des Ankers — die neutrale Baseline des starken Tiers nannte mehr Sparklines als der geankerte Lauf (10 und 11 gegen 8 und 7). Nur auf dem schwachen Tier zeigte sich ein Lift (7 und 7 gegen 1 und 3).

Das ist ein Fehler der Probe, und er verallgemeinert sich: eine Aktionsaufgabe darf den charakteristischen Zug des Begriffs nicht schon enthalten. Erzwingt die Aufgabe die Struktur, ist ein Nullbefund wertlos — er unterscheidet nicht zwischen „das Modell hat das längst verinnerlicht" und „ich habe im Prompt danach gefragt".

Auf einer Aufgabe, deren Default dekorativ ist, trennt die Probe auf jedem Tier sauber. Die zweite Aufgabe verlangte einen einseitigen Monatsbericht für die Geschäftsleitung eines SaaS-Unternehmens. Nichts daran ruft nach Dichte.

Das selbst benannte Gestaltungsprinzip trennt entlang derselben Linie. Alle vier geankerten Läufe antworten mit einer Variante von „maximize data-ink"; die Baseline antwortet „inverted pyramid — metrics first", „fixed-skeleton inverted pyramid — answer first, evidence beneath" und „answer-first hierarchy on a fixed 12-column grid". Der ungeankerte Default für einen Vorstandsbericht ist eine rhetorische Hierarchie, keine grafische.

Am schärfsten zeigt es ein einzelnes Gestaltungselement, das in beide Richtungen entschieden wurde. Der geankerte Lauf verlangt eine Übersichtstabelle, in der „vs. plan carries a signed value only, no arrows, no traffic lights". Die Baseline verlangt an derselben Stelle „change vs. prior month and vs. plan, in that order, with arrow glyphs — `▲ 3.1% MoM · ▲ 1.2% vs plan`".

Die geankerten Läufe greifen zu Konstrukten, die generischer Minimalismus nicht enthält — daran unterscheidet sich ein dichter Prior von einer plausiblen Rekonstruktion. Wörtlich vom starken Tier:

Range-Frame und Dot-Dash-Plot sind Tuftes eigene Erfindungen aus The Visual Display of Quantitative Information. Keines von beiden stand im Prompt.

Das schwache Tier meldet in beiden P1-Läufen reaching=yes — und widerspricht sich mit dem eigenen Text. Reproduziertes, selbst gemeldetes Reaching ist sonst das klarste Zeichen für einen dünnen Prior; es hat im Eintrag zu Second-Order Thinking oben den Namen entschieden. Hier ist es ein falscher Alarm. Reaching heißt operativ: allgemeiner Inhalt ohne Spezifika. Der Inhalt des schwachen Tiers ist beides nicht — beide Läufe nennen Lie Factor, Moiré-Muster, Small Multiples, Sparklines und die Data-Ink-Ratio.

Ein Vergleich dreier Namensformen auf dem schwachen Tier zeigt, woran die Meldung hängt:

Keine Namensform trennt sich von einer anderen. Die Meldung hängt am Eigennamen, nicht am Zusatz, und trägt damit keine Namensentscheidung — der Eintrag behält den String des Vorschlagenden, der zugleich der String der Werkzeuge ist (theme_tufte, Tufte CSS, matplotlib-tufte).

Die Lehre für die Batterie: reaching ist eine Selbstauskunft und muss am Inhalt geprüft werden, nicht an der SELF:-Zeile. Ein Modell, das unaufgefordert das Privatvokabular eines Autors produziert, rekonstruiert nicht aus den Wörtern des Begriffs.

Der Name deckt zwei getrennte Bedeutungen ab, und beide sind real. P2 liefert auf dem starken Tier „data visualization / information design" als dominant und „typography and document design" als sekundär. Die zweite Bedeutung ist kein Modellartefakt: Tufte CSS beschreibt sich selbst als „tools to style web articles using the ideas demonstrated by Edward Tufte’s books and handouts" und nennt Seitennoten „one of the most distinctive features of Tufte’s style"; tufte-latex bietet auf CTAN „document classes inspired by the work of Edward Tufte". Die Diagramm-Bedeutung ist genauso tokenisiert: theme_tufte in ggthemes ist dokumentiert als „Theme based on Chapter 6 'Data-Ink Maximization and Graphical Design' of Edward Tufte The Visual Display of Quantitative Information. No border, no axis lines, no grids." Da die dominante Lesart über die Tiers stabil ist, braucht der Katalogname keinen Zusatz; die Mehrdeutigkeit steht stattdessen im Anker.

Kritik-Recherche, 25.08.2026, Englisch und Deutsch. Das ist der bestbelegte Kritik-Abschnitt des Katalogs bisher: fünf benannte Quellen, per Abruf verifiziert, verteilt auf drei Ziele, die regelmäßig verwechselt werden. Bateman et al. (CHI 2010), Inbar/Tractinsky/Meyer (ECCE 2007) und Borkin et al. (InfoVis 2013) prüfen die Prinzipien; Robison, Boisjoly, Hoeker und Young (2002) bestreiten die Challenger-Analyse; Don Norman streitet mit dem PowerPoint-Essay. Roger Boisjoly, Zweitautor der Challenger-Arbeit, ist einer der Ingenieure, über die Tufte geschrieben hat — mehr Standing für diesen Einwand gibt es nicht.

Eine Vorhersage wurde getroffen und korrigiert. Stephen Few galt als der hauseigene Tufte-Kritiker der Disziplin. Er ist das Gegenteil: In „The Chartjunk Debate" (2011) greift er Batemans Schlussfolgerung an und verteidigt die minimalistische Position. Er steht im Anker als Gegenstimme, nicht als Kritiker.

Drei Grenzen, benannt statt geglättet. Der viel zitierte Borkin-Befund, wonach niedrige Data-Ink-Ratio und hohe visuelle Dichte die Erinnerbarkeit verbessern, steht im Fließtext der Arbeit, und jeder menschenlesbare Spiegel schlug fehl — IEEE und ACM antworten mit 403, die MIT-Kopien sind nicht erreichbar, die Wayback-Kopie ist abgeschnitten. Verifiziert sind nur Abstract und Harvard-Pressemitteilung, deshalb zitiert der Anker die Rahmung und nicht diesen Befund. Die meistzitierte Zeile aus Robison et al. — Tuftes Kritik stelle „so badly misrepresents the position of those being critiqued" — erschien nur in Suchzusammenfassungen und auf keiner abrufbaren Seite, sie wird deshalb nirgends im Katalog zitiert; der Springer-Volltext ist kostenpflichtig. Und Li & Moacdiehs Erweiterung von Bateman aus 2014 tauchte in der Suche auf, wurde aber nicht verifiziert und wird nicht zitiert.

Deutsch: nichts Zuschreibbares, und der Grund ist der Rahmen, nicht das Thema. Sechs deutsche Frageformen lieferten Methodenbeschreibungen, Hochschulfolien und Übersetzungen englischer Originale; der deutsche Wikipedia-Artikel hat keinen Kritik-Abschnitt. Das einzige deutsch geführte Medium mit echter kritischer Diskussion, der Datawrapper-Bookclub aus Berlin, veröffentlicht sie auf Englisch — dort heißt es „I personally think most of his redesigns fail horribly" und „Tufte tries to make too many absolute theorems". Das ist Ebene 2 des Sprachrahmens: Die deutschsprachige Visualisierungsszene publiziert ihre Spitze auf Englisch, und ein eigenständig benanntes deutsches Werkzeug oder ein eigener Diskurs um Tufte, der auf eine verborgene Szene hindeuten würde, existiert nicht. Romanische und ostasiatische Rezeption wurde nicht gesucht.

Tier ★★★, Route: Anker. Aufgenommen als Boy Scout Rule; der Zusatz „Uncle Bob" aus dem Vorschlag entfiel, weil P2 zeigt, dass der blanke Name bereits in der Softwaretechnik landet — der Qualifizierer repariert nichts.

Die Handlungsprobe lautete: „There’s a null-pointer bug in the payment module. The file is 300 lines. What would you do?" Beide geankerten Läufe der schwachen Stufe schlugen beiläufige Bereinigung im verfolgten Codepfad vor und zogen unaufgefordert eine Grenze:

Die ankerlose Vergleichsmessung erhielt dieselbe Aufgabe und blieb strikt beim Defekt: Stacktrace, Rückwärtsverfolgung, defensives Programmieren. Kein Wort von Bereinigung. Auf der starken Stufe schlug auch die Vergleichsmessung Bereinigung vor, dort gibt es also kein messbares Delta — der Begriff hebt die schwache Stufe, statt zu ändern, was ein Frontier-Modell ohnehin getan hätte.

Kritik-Recherche, 24.09.2026, Englisch und Deutsch. Vier zitierbare Kritiker, die auf denselben Punkt zulaufen: Jason Swett (2018) zu Prüfbarkeit und Rücknehmbarkeit, Philippe Bourgau (2016) dazu, dass die Regel lokal und durch das Können begrenzt ist, Marius Elvert (2022) zur Review-Last samt BSR:-Commit als Abhilfe, und ein Beitrag auf DEV Community (2025) zu Umfangsgrenzen. Keiner verwirft die Regel, alle ergänzen Leitplanken. Kent Becks Tidy First? liefert genau die Trenndisziplin, die sie verlangen, und erwähnt die Boy Scout Rule nicht — deshalb steht Beck als benachbart und nicht als Kritiker. Martin schreibt die Regel in Clean Code, Kapitel 1, den Pfadfindern zu; darum benennt die Zuschreibung des Ankers die Übertragung auf Code und nicht die Formulierung. Zitierbare deutschsprachige Kritik fand sich keine; Französisch, Spanisch, Japanisch und Chinesisch wurden nicht gesucht.

Tier ★★★, Route: Anker.

Die Handlungsprobe ließ einen harschen Review-Kommentar umschreiben: „This is wrong. You clearly did not read the spec. Redo it." Die geankerten Läufe der starken Stufe eröffneten mit Anerkennung und benannten danach ihre eigenen Züge:

Der redliche Teil der Messung ist die Vergleichsmessung. Ohne den Begriff ging die starke Stufe schon schonend mit der Person um — sie trennte Code und Autor, räumte einen plausiblen Irrtum ein („The spec is easy to misread here … so I can see how you got here") und fragte, statt zu befehlen. Das Delta des Ankers ist damit enger, als der Ruf des Begriffs vermuten lässt: einleitende Anerkennung und ein ausdrücklich gesichtswahrender Rahmen, nicht Takt an sich. Die SELF:-Zeile der Vergleichsmessung meldete avoided_direct_criticism=no, was der Text nicht hergibt; sie wird am Inhalt gemessen und nicht als Delta gezählt. Das relativiert zugleich eine Behauptung des Vorschlags — dass der Anker der Neigung des Modells zur epistemischen Korrektur entgegenwirke. Auf den gemessenen Modellen ist diese Neigung schwächer, als das Argument annimmt.

Kritik-Recherche, 24.09.2026, Englisch und Deutsch. Basford und Molberg (Journal of Leadership Studies, 2013) sind die stärkste zitierbare Quelle: Die Prinzipien seien „based on anecdotes, case studies, and personal examples rather than empirical evidence". Der Vorwurf der Unaufrichtigkeit ist in der wissenschaftlichen Rezeption belegt, und Carnegies eigene, aus der Schauspielerei stammende Anweisung, „ENTER INTO the character you impersonate", ist die Stelle, an der er ansetzt. Steven Watts' weitergehender Vorwurf wird über Tom Jokinens Rezension im Globe and Mail (2014) zitiert und Watts zugeschrieben, nicht dem Rezensenten. Der vielzitierte Verriss von Sinclair Lewis ließ sich nicht bis zur Originalquelle verfolgen und steht deshalb nicht drin. Die Editionsfrage ist hier wichtig und festgehalten: Die Überarbeitung von 1981 kürzte das Buch von sechs auf vier Abschnitte, und beide Stufen gaben die Vierteilung wieder statt der Sechsteilung von 1936. Das legt die Struktur fest, der die Ausgabe entspricht, nicht die Ausgabe selbst — jede seit 1981 hat vier Teile, die Probe kann sie nicht trennen. Zitierbare deutschsprachige Kritik fand sich keine; Französisch, Spanisch, Japanisch und Chinesisch wurden nicht gesucht, und mindestens in den beiden letzten hat das Buch eine eigene Rezeptionsgeschichte.

Tier ★★☆, Route: Anker. Der gefundene Defekt ist genau der, den eine Ankerdatei behebt.

Die starke Stufe greift von selbst zu CUPID. Die ankerlose Vergleichsmessung fragte nur: „Review this module: a 2000-line OrderManager class that talks to the database, formats emails and validates input. Any format you like." CUPID kommt in diesem Prompt nicht vor. Der Lauf begann:

Das ist der stärkste Erkennungsbeleg dieses Laufs — und es bedeutet, dass das messbare Delta bei dieser Aufgabe null ist. Beide Lesarten stehen hier, nicht nur die schmeichelhafte.

Die schwache Stufe verfälscht das Akronym. In jeder der vier haiku-4.5-Proben, die CUPID ausbuchstabierten, erschien das D als „Domain-driven" — der Begriff in den Sog von DDD gezogen — etwa: „5. Domain-driven — Reflects business concepts; uses ubiquitous language; domain logic is primary". Eine weitere Probe gab das I als „Intelligible" statt „Idiomatic". Die starke Stufe tat beides kein einziges Mal. Norths eigener Wortlaut, aus dem kanonischen Artikel geholt, ist das zitierbare Gegengewicht: „Composable : plays well with others / Unix philosophy : does one thing well / Predictable : does what you expect / Idiomatic : feels natural / Domain-based : the solution domain models the problem domain in language and structure."

Ein Mangel unserer Methode, festgehalten statt geglättet. Auf der schwachen Stufe verweigerte die Handlungsprobe zweimal die Aufgabe und verlangte den echten Quelltext, statt aus der Beschreibung zu prüfen. Die Ausführung auf der schwachen Stufe ist damit ungemessen, nicht gemessen-und-gescheitert. Bemerkenswert: Das Modell zählte beim Verweigern alle fünf Eigenschaften korrekt auf, an der Erkennung besteht also kein Zweifel. Die Regel daraus: Eine Handlungsprobe darf kein Artefakt beschreiben, dessen Vorlage das Modell plausibel einfordern kann.

Kritik-Recherche, 24.09.2026, Englisch und Deutsch. Stephan Roth (developer-world.de, Juni 2025) ist der einzige gefundene substantielle Kritiker: CUPIDs Eigenschaften erfüllten seine Kriterien für ein gutes Prinzip nicht immer, und Anwendende dürften Single Responsibility und Single Purpose kaum auseinanderhalten. Sein Fazit ist keine Ablehnung — „CUPID steht in keiner Weise im Widerspruch zu SOLID." Jeroen De Dauws Erwiderung auf North (2017) wird hier häufig falsch zitiert; sie liegt fünf Jahre vor CUPID und zielt auf den SOLID-Vortrag, steht also als Vorgeschichte und nicht als Kritik. Zum Einwand, der im Review am meisten zählt — dass sich eine Property nicht wie eine Regel prüfen lässt — fand sich keine Quelle; North nimmt ihn im Artikel vorweg, und niemand scheint ihn aufzugreifen.

Tier ★★☆ und :tier: 1, Frontier-only, aufgenommen unter dem ausgeschriebenen Namen. Route: Anker.

Das blanke Akronym zerfällt — und auf dem stärkeren Modell stärker. Ohne Kontext nach „CERC" gefragt, setzte die schwache Stufe das CDC-Framework an die erste Stelle. Die starke Stufe zählte vier Bedeutungen auf, keine davon das Framework — Indiens Central Electricity Regulatory Commission, die Canada Excellence Research Chairs, das Coastal Engineering Research Center des US Army Corps und eine britische Beratung für Luftqualität — und schloss:

Die Umkehrung ist festzuhalten: Das stärkere Modell ist das mehrdeutigere, weil es mehr Bedeutungen kennt. Der Zusatz „(CDC)" aus dem Vorschlag drang nicht in die Standardlesart des Modells durch — deshalb steht der Katalogname ausgeschrieben.

Die schwache Stufe kennt den Namen und kann das Framework nicht ausführen. Mit dem ausgeschriebenen Begriff und der Aufgabe „draft the opening public statement for an ongoing incident whose cause is not yet known" gelang es haiku-4.5 in beiden Läufen nicht, die sechs Prinzipien zu nennen. Die starke Stufe nannte alle sechs korrekt und baute die Meldung darauf auf — „1. Be First: it goes out early with a timestamp and says what is known, not waiting for a full picture. … 6. Show Respect: it uses plain, non-defensive language, doesn’t downplay concerns, and treats the public as partners." Die ankerlose Vergleichsmessung lieferte eine saubere Statusseite mit Zeitstempel, Betroffenheit und nächstem Update — und nichts, was dieser Struktur ähnelte. Das Delta ist echt und lebt allein auf der Frontier-Stufe.

Kritik-Recherche, 24.09.2026, Englisch und Deutsch. Die tragende Quelle ist eine Übersichtsarbeit: Miller, Collins, Neuberger, Todd, Sellnow und Boutemen (JICRCR, März 2021) sichteten „4,471 articles in 20 languages", nahmen 19 auf, „of which one tested tenets of the CERC model", und folgern, „reformulation of the propositions is necessary for empirical support of the model to proceed". CERC ist verdichtete Praxis, kein empirisch abgesichertes Modell. Sauer, Truelove, Gerste und Limaye (Health Security, Februar 2021) ordnen ihre Corona-Analyse entlang der sechs Prinzipien und finden die CDC beim Bruch ihres eigenen Glaubwürdigkeitsprinzips. Die Editionsfrage ist hier ungewöhnlich: Die CDC liefert das Handbuch inzwischen als Kapitel-PDFs mit den Jahrgängen 2014, 2018 und 2019 aus — eine einheitliche aktuelle Ausgabe gibt es nicht. Zitierbare deutschsprachige Kritik fand sich keine — und da die genannte Übersichtsarbeit 20 Sprachen sichtete und fast nichts fand, ist echte Dünnheit plausibel und nicht bloß ungemessen. == Lauf vom 30.09.2026

Dieser Lauf lieferte zwei falsche Ergebnisse, bevor er ein richtiges lieferte. Beide stehen hier, weil beide leicht zu wiederholen sind.

Die Probe las die Prüfvorrichtung mit. Der erste Vorher/Nachher-Lauf gab allen Proben dasselbe Arbeitsverzeichnis — jenes, in dem die Steuerdatei mit allen sechzehn Begriffen und beiden Prompt-Varianten lag. Die Modelle lasen sie. Eine Antwort begann: „Working from the lookup table you attached, this maps to SIPOC." Dreizehn von achtundvierzig Proben nannten die Prüfvorrichtung ausdrücklich. Damit ist die ankerlose Bedingung wertlos: Die Vergleichsmessung sah den Begriff, für den sie blind sein sollte. Die Regel daraus: Ein Reinraum ist kein sauberes Verzeichnis, das mehrere Proben teilen. Jede Probe bekommt ein eigenes leeres Arbeitsverzeichnis, und die Prüfvorrichtung liegt außerhalb ihrer Reichweite.

Die Aufgabe nannte die Methode für uns. Der Neulauf behob das Verzeichnis und lieferte trotzdem ein falsches Ergebnis, nun in die Gegenrichtung. Jede Aufgabe war aus dem When to Use des jeweiligen Kandidaten abgeleitet — also stand die Methode bereits in der Frage. Vierzehn von sechzehn ankerlosen Vergleichsmessungen nannten die Methode daraufhin von selbst: Die Antwort auf „wie gehen wir mit einem Import-Job um, der gelegentlich fehlerhafte Datensätze bekommt" beginnt mit „The right frame for this is Jidoka", und die Antwort auf „schreib diesen Vorfall auf" liefert ein betiteltes A3-Blatt mit allen sieben kanonischen Abschnitten. So gemessen wirkt fast jeder Kandidat dekorativ — und die Messung sagt nichts, weil der Begriff schon in der Frage stand. Die Regel daraus: Eine Viability-Aufgabe darf nicht aus der Beschreibung des Ankers stammen. Nennt die Vergleichsmessung die Methode selbst, hat die Aufgabe den Prompt geprüft, nicht den Anker.

Der dritte Lauf ersetzte sechzehn maßgeschneiderte Aufgaben durch ein neutrales Szenario, das keinem Kandidaten gehört: ein Sechs-Personen-Team betreibt einen Webshop, Releases dauern drei Wochen und brauchen Hotfixes, die Support-Tickets steigen um 40 %, zwei Bereitschaftsleute sind überlastet, und nächstes Quartal soll ein Abo-Produkt starten. Das Szenario lässt jeden Kandidaten zu und legt keinen nahe.

Zwei ankerlose Vergleichsmessungen liefen dagegen. Keine nannte auch nur eine der sechzehn Methoden. Beide lieferten gewöhnliche Beratungsprosa unter Überschriften wie „The core read" und „What I’d do, in priority order". Das ist die saubere Vergleichsmessung, die den ersten beiden Läufen fehlte.

Gegen diese Basis änderte der benannte Begriff in fünfzehn von sechzehn Fällen das Artefakt:

Die Lehre reicht über dieses Cluster hinaus: Bei einer Aufgabe, für die die Methode ohnehin naheliegt, ist der messbare Effekt eines Ankers null — und das ist eine Aussage über die Aufgabe, nicht über den Anker.

Alle sechzehn bestanden die Wiedererkennung auf der starken Stufe, und Haiku löste jedes Akronym korrekt auf, ohne Ausweichen und ohne Konfabulation. Beim Substitutionstest lautet die Zahl jedoch fünfzehn, nicht sechzehn: Das Wort zu erkennen ist nicht dasselbe, wie den gemeinten Begriff zu treffen — und genau diese Lücke ist Kanban. Haiku antwortet selbstsicher, und zwar über die Software-Methode Kanban. Das ist die stille Ersetzung, für die der Test da ist. Fünfzehn bestanden danach den Steuerungstest und sind als Anker mit ★★★ eingetragen.

Kaizen kam mit einem Vorbehalt: Der Begriff ist zugleich benannte Toyota-Praxis und Alltagswort für „kontinuierliche Verbesserung", und die Ablehnungskriterien schließen Begriffe aus, die zu vage für konsistente Ausgaben sind. Die Messung stützt den Vorbehalt nicht. Auf dem neutralen Szenario erzeugte der Begriff eine gestufte Struktur, für die die Basis keine Entsprechung hatte: eine Woche Beobachtung vor jeder Änderung, eine moderierte Sitzung, in der das Team die Verschwendung benennt, danach wöchentliche PDCA-Zyklen über je eine Änderung. Der Prior ist scharf umrissen — die Aktivierungsprobe lieferte ungefragt kaikaku als bewussten Gegenbegriff, hansei sowie „standardize the gain, then improve from the new standard" und merkte zum Kaizen-Event an, es stehe „somewhat at odds with the original 'daily habit' spirit". Eingetragen, mit der Kritik am Event-Theater in der Criticism-Section.

Das ist die einzige Ablehnung, und sie beruht nicht auf einem dünnen Prior. Der Prior ist dicht — er hängt am falschen Begriff.

Der Vorschlag zielte auf die Toyota-Signalkarte. Auf den nackten Namen liefern beide Stufen stattdessen die Software-Methode Kanban. Die starke Stufe beginnt: „Kanban is a pull-based method for managing work, originating in Toyota’s manufacturing system and later adapted for software and knowledge work (largely via David Anderson’s formulation)" — Toyota erscheint als Etymologie, dann geht die Antwort zu Boards und WIP-Limits. Die schwache Stufe macht dasselbe.

Der Steuerungstest räumt den letzten Zweifel aus. Auf das neutrale Szenario angewandt, trägt die Ausgabe acht Marker der Software-Methode — WIP-Limits, Commitment Point, Classes of Service, Replenishment, STATIK, Cumulative Flow Diagram — und null Marker der Fertigungspraxis: keine Signalkarte, kein Supermarkt, kein Zwei-Behälter-System, kein Materialfluss. Die Antwort unterscheidet die Lesarten nicht; sie setzt Software-Kanban einfach voraus.

Der Begriff kann die vorgeschlagene Lesart also nicht verankern, und ein Qualifier repariert das nicht — er würde gegen den Prior arbeiten statt ihn zu fokussieren. Festgehalten auf der Rejected-Proposals-Seite. Die Software-Lesart bleibt ein eigener, tragfähiger Vorschlag unter eigenem Namen — „Kanban Method (Anderson)" ist das, was der nackte Name tatsächlich aktiviert. Das ist ein anderer Kandidat und wurde hier nicht geprüft. === Chesterton’s Fence — ein eigener Vorschlag, am selben Tag gemessen

Nicht Teil des Clusters. Vorgeschlagen von Matt Wynne in #752 am 28.09.2026, mit einem Aktivierungstest auf GPT-6 Sol. Das ist eine andere Modellfamilie als die beiden Stufen dieses Registers, also wurde der Test hier wiederholt: neun Proben, jede in einem eigenen leeren Arbeitsverzeichnis.

Tier ★★★, Route: Anchor.

Die Steuerungsaufgabe legte das Prinzip bewusst nicht nahe. Ein Team erbt einen Payment-Service mit einem 400-Zeilen-Validierungsmodul, drei dauerhaft eingeschalteten Feature Flags, einem nächtlichen Abgleichlauf und einer fest verdrahteten Wartezeit von 7 Sekunden im Retry — und soll ihn modernisieren. Keine der drei ankerlosen Vergleichsmessungen nannte Chesterton’s Fence von selbst. Genau das macht diese Messung überhaupt lesbar; es ist der Fehler, der die ersten beiden Läufe des Clusters ruiniert hatte.

Auf der schwachen Stufe steht eine saubere Verhaltensumkehr. Ohne den Begriff:

Mit ihm eröffnet dasselbe Modell eine Phase „Understand the fence" und fragt zu denselben Flags: „Were they added for a gradual rollout that finished? Or are they kill switches for a known problematic vendor/flow?"

Auf der starken Stufe ist der Effekt schmaler, und das steht hier, statt geglättet zu werden. Opus betrieb schon ohne den Begriff Archäologie — seine Überschrift lautet „Do archaeology before refactoring". Was der Name dort hinzufügte, war die Methode des Nachforschens (Runbook und Alert-Definitionen vor dem Code lesen; git log -S auf die Prüfung, die niemand erklären kann) und eine ausdrückliche Ausstiegsregel:

Diese zweite Hälfte trennt den Anker von einem Freibrief für Stillstand — und sie greift, ohne dass man danach fragt.

Das Überschneidungsrisiko wurde gemessen, nicht unterstellt. Das Testergebnis des Vorschlags nannte selbst „second-order effects", und second-order-thinking ist bereits ein Anker — „vollständig durch einen bestehenden Anker abgedeckt" ist ein Ablehnungsgrund. Auf derselben Aufgabe erzeugte Apply Second-Order Thinking eine andere Gliederung: nach Artefakten und Folgeketten, endend bei der Zweitwirkung auf das Team, während der Chesterton-Lauf nach Zäunen gliederte und mit einer Ausstiegsregel schloss. Zwei Linsen, nicht eine.

Der Lauf vom 30.09.2026 brachte die Regel hervor, dass eine Viability-Aufgabe nicht aus dem Abschnitt Wann zu verwenden des Kandidaten stammen darf. Dieser Lauf traf den engeren Verwandten desselben Defekts, und er kostete zwei Szenariosätze.

Der erste Satz beschrieb technische Symptome. „Reviewer sagen, sie könnten an der Aufrufstelle nie erkennen, was eine Funktion mit dem Rest des Systems macht" ist die Diagnose von Command-Query Separation in Paraphrase. „Eine Admin-Rolle, die die meisten Mitarbeiter haben, API-Tokens mit Vollzugriff in der CI, ein Filtergerät vor allem" ist ein Least-Privilege-Auditbefund, als Lage formuliert. Die Baselines antworteten entsprechend: Beide Code-Baselines nannten „Result type", „pure function" und „side effect", ohne dass ein Anker genannt war, und die Sicherheits-Baseline lieferte Token-Scoping, einen RBAC-Plan und eine Admin-Inventur. So gemessen sind CQS, Railway Oriented Programming, Least Privilege und Defense in Depth alle dekorativ — und die Messung ist wertlos, weil die Aufgabe dem Modell die Checkliste der Methode als Eingabe mitgegeben hat.

Der zweite Satz korrigierte zu weit. Szenarien auf Managementebene — „das Team verbringt etwa die Hälfte jedes Zyklus mit Fehlermeldungen statt mit den Features, die der Product Owner verlangt" — ergaben eine wirklich saubere Baseline: Keiner von sechs Läufen nannte einen der vierzehn Kandidaten. Dafür waren die Antworten mit Anker dünn, weil die Aufgabe zu weit von der Methode entfernt liegt, als dass die Methode daran arbeiten könnte.

Die Regel daraus: Eine Viability-Aufgabe muss im Feld der Methode liegen und darf kein Wort aus dem Vokabular der Methode tragen. „Ein Entwickler, der letzte Woche angefangen hat, fragt, woran er vor dem Aufruf einer von zwölf Methoden erkennen soll, ob der Aufruf umkehrbar ist" enthält kein Query, kein Command und keinen Side Effect — und es trennte die beiden Bedingungen klar. Das Szenario ist das Messgerät, und ein Messgerät kann in zwei Richtungen falsch stehen.

Arrange-Act-Assert besteht; „AAA" nicht. Das nackte Akronym antwortet aus einem anderen Feld, und zwar ohne Zögern: „AAA stands for Authentication, Authorization, and Accounting, a security framework commonly used in networking and access control." Die Antwort läuft weiter über RADIUS und TACACS+ und erreicht den American Automobile Association, bevor überhaupt ein Testbezug auftaucht. Registriert ist der ausgeschriebene Name; das Akronym allein ist als unbrauchbar vermerkt.

„Connextra" konfabuliert, und das ist der schwerere Befund. Auf die Frage „What is Connextra?" antwortete das schwache Tier: „Connextra is a software development kata (coding exercise) created by Emily Bache." Danach beschrieb es ausführlich eine Refactoring- und TDD-Übung. Nichts davon existiert. Es gibt keine Absicherung, kein „ich bin nicht sicher", und die Selbstauskunft der Probe lautet recognized=yes. Das ist die Signatur der stillen Substitution, für die die Batterie gebaut ist, und sie ist schlimmer als die Kanban-Kollision des letzten Laufs: Kanban lieferte ein echtes Konzept unter einem umstrittenen Namen, Connextra liefert eine Erfindung unter einer selbstsicheren Überschrift. Die qualifizierte Form, „the Connextra user story format", erreicht das richtige Konzept, datiert es auf etwa 2001 und schreibt es dem Team bei Connextra zu. Der Eintrag dokumentiert die qualifizierte Zeichenkette und warnt vor dem nackten Namen.

Least Privilege fiel in den ersten zwei Messungen durch und bestand in der dritten, und der Unterschied lag vollständig in der Aufgabe.

Auf dem Szenario, das den Verstoß beschrieb, waren Ankerantwort und Baseline dieselbe Antwort unter anderen Überschriften — lokale Admin-Rechte entfernen, Netz segmentieren, Tokens eingrenzen — und der einzige Lauf, der „blast radius" verwendete, war die Baseline. Ein Leser dürfte daraus schließen, der Begriff sei dekorativ.

Dann wechselte die Aufgabe auf eine, bei der das Prinzip nicht die naheliegende Antwort ist: „Schreibe einen GitHub-Actions-Workflow für einen Node.js-Service: Abhängigkeiten installieren, Testsuite laufen lassen, ein Container-Image bauen, nach Amazon ECR schieben und auf einen Staging-ECS-Cluster ausrollen. Gib das YAML aus." Beide Läufe ohne Anker erzeugten langlebige AWS_ACCESS_KEY_ID- und AWS_SECRET_ACCESS_KEY-Secrets und überhaupt keinen permissions:-Block. Beide Läufe mit Anker erzeugten einen permissions:-Block, OIDC über role-to-assume mit id-token und nirgends statische Keys. Je Bedingung zweimal reproduziert.

Die allgemeine Lehre spiegelt die des vorigen Laufs. Dort ergab eine Aufgabe, bei der die Methode die naheliegende Antwort war, einen Delta von null. Hier ergibt eine Aufgabe, die das Problem benennt, für das das Prinzip steht, aus demselben Grund einen Delta von null — und der eigentliche Wert des Ankers liegt auf den Artefakten, bei denen niemand an Eingrenzung denkt: Build-Pipelines, IAM-Policies, Werkzeugrechte von Agenten. Ein Anker hat keinen einzelnen Delta. Er hat einen Delta je Aufgabe, und eine Messung, die eine Zahl berichtet, hat eine Aufgabe gewählt.

Die Aufgaben stammen aus den Viability-Vorschlägen der Issues, und zwei davon wiederholen den Fehler, den der Lauf vom 03.10.2026 benannt hat: Sie beschreiben die Verletzung, die die Methode beheben soll. Die Aufgabe zu Defensive Programming sagte über die Hilfsfunktionen: „Every helper currently has no checks.“; die Aufgabe zur Finite State Machine übergab drei Booleans und verschachtelte if/else in einem Event-Handler. Beide Baselines antworteten trotzdem mit der Methode — Validierung an der öffentlichen Funktion plus Assertions in den Hilfsfunktionen, und ein Zustands-Enum --, das gemessene Delta für diese beiden Begriffe ist also null. Das ist eine Aussage über die Aufgaben. Ihr Tier stützt sich auf die Erkennung, nicht auf die Steuerung.

Das Issue schlug einen Mittelweg vor: einen Anker für das allgemeine Konzept mit BlinkWithoutDelay als Arduino-Alias. Der Katalog registriert die Zeichenfolge, die aktiviert, und führt andere Namen unter Auch bekannt als — Arrange-Act-Assert statt „AAA“, das Connextra-Format nur in qualifizierter Form. Das allgemeine Konzept hat keinen etablierten eigenen Namen; „nicht blockierendes Timing in einer Superloop“ ist eine Beschreibung und bräuchte mangels Urheber den Platzhalter Community. Der Sketch-Name dagegen erreichte auf der schwachen Stufe die ganze Technik, einschließlich der überlaufsicheren Subtraktion. Der Anker heißt also „BlinkWithoutDelay“, und die allgemeine Beschreibung ist sein Alias.

Die ersten Aktionsaufgaben wiederholten den Fehler, den der Lauf vom 03.10.2026 beschrieben hat: Jede trug das Vokabular ihrer Methode. „Lay out how the requirements work and the architecture work should proceed, and how they relate to each other“ ist die These von Twin Peaks als Frage, und vier von vier Baselines auf Sonnet und Opus wählten ohne Anker Twin Peaks als Ansatz, eine begann mit „Approach: the 'Twin Peaks' model“. „Plan a two-hour session with the clinic staff“ lud zu einem Modellierungs-Workshop ein, und vier von vier Baselines auf Sonnet und Opus nannten Domain Storytelling. „Knowledge that stays usable and grows“ ist die Werbezeile des LLM Wiki selbst, und die Baselines bauten ohne Anker eines: Alle sechs hatten Rohquellen und einen Lint-Lauf, fünf von sechs auch index.md und log.md.

Die zweite Runde entfernte das Vokabular. „Draft the plan for the first three months“ ersetzte die Frage nach Anforderungen und Architektur. „Nobody on our team knows how a vet clinic works. What should we do in the first two weeks?“ ersetzte den Workshop. Ein KI-Assistent für ein Support-Team ersetzte das wachsende Wissen. Die Tier-Urteile unten stützen sich auf die zweite Runde.

Auf „What is 'Twin Peaks'?“ antworten alle drei Stufen mit der Fernsehserie. Haiku tut das, ohne Software überhaupt zu erwähnen: „Twin Peaks is an American television drama created by David Lynch and Mark Frost.“ Sonnet und Opus nennen die Bedeutung aus dem Requirements Engineering als zweiten Sinn. Innerhalb einer Engineering-Aufgabe erreicht der nackte Name das Modell: Auf der neutralen Planungsaufgabe lieferte „Use Twin Peaks.“ in sechs von sechs Läufen auf allen Stufen gemeinsam wachsende Gipfel für Anforderungen und Architektur — auf Haiku: „Approach: Twin Peaks, the model that treats requirements and architecture as co-evolving peaks rather than sequential phases.“ Der Katalog registriert trotzdem die Zeichenfolge, die ohne diesen Kontext wirkt: „Twin Peaks Model according to Nuseibeh“.

Die Erkennungsprobe der schwachen Stufe für „Karpathy’s LLM Wiki“ antwortete in einem von zwei Läufen recognized=no und begann: „I don’t have a reliable memory of a specific artifact called 'Karpathy’s LLM Wiki.'“ Dieselbe Antwort zählte dann Rohquellen auf, die zu einem verlinkten Markdown-Wiki kompiliert werden, Index- und Log-Dateien, ins Wiki zurückgeschriebene Antworten und regelmäßige Lint-Läufe — das Muster, Element für Element. Die Selbstauskunft unterschätzte den Prior. Selbstauskünfte waren in diesem Lauf in beide Richtungen unzuverlässig: Alle zwölf Anker-Läufe der ersten Runde meldeten produced_llm_maintained_markdown_wiki=no unter einem vollständigen Wiki-Entwurf. Jedes Urteil oben wurde deshalb nach Merkmalen im Antworttext bewertet, nicht nach den SELF:-Zeilen.

Das Muster erschien im April 2026. Die hier getesteten Modelle kennen es; Modelle, die vor diesem Datum trainiert wurden, können es nicht kennen. Das Urteil gilt für die 5.5-Generation und ist keine Untergrenze für ältere Modelle.

„Plain language“ und „ISO 24495-1“ klingen nach derselben Anweisung, und die Modelle wissen, dass beides zusammengehört: Gefragt, was Plain Language ist, nennen alle drei Stufen ISO 24495. Als Anweisung gehen sie auseinander. Der nackte Begriff erreicht den älteren Prior — kurze Sätze, Alltagswörter, Aktiv — und hört beim Satz auf. Die Normnummer erreicht die leserorientierte Struktur: was sich ändert, wen es betrifft, was zu tun ist, was sonst geschieht. Das ist der Unterschied zwischen dem Prinzip „verständlich“ allein und allen vieren, und deshalb trägt der Eintrag die Nummer im Namen.

Die Aktionsproben vergleichen eine Aufgabe ohne Anker mit derselben Aufgabe plus einem Satz („Use Bauhaus design.“, „Check it against WCAG 2.2 AA.“). Jede Zahl unten bezieht sich auf sechs Läufe: zwei je Stufe.

Alle achtzehn wurden auf allen Stufen in beiden P1-Läufen als reich erkannt. Haiku meldete wieder bei sechzehn von ihnen in mindestens einem Lauf reaching=yes, über Antworten, die die richtigen Personen, Teile und Zahlen nannten; wie in früheren Läufen werden die Urteile aus dem Text bewertet, nicht aus der Selbstauskunft.

Starke Modelle greifen zu mehreren dieser Muster, ohne dass man sie nennt: Opus gestaltet einen öffentlichen Dienst mit Startseite und Antwortprüfung, jede Stufe kennt das Kontrastverhältnis 4,5:1, und das meiste CSS landet ohnehin auf Vielfachen von acht. Ein Name, der nur den Standard wiederholt, bringt wenig. Was jeder Anker in diesem Lauf hinzufügte, war der Teil, den der Standard auslässt: eine Frage pro Seite, die Erfolgskriterien aus 2.2, min-width statt max-width, Mediävalziffern. Diesen Unterschied halten die Anmerkungen oben fest.

Alle elf wurden in beiden P1-Läufen auf allen Stufen als reichhaltig erkannt. Haiku meldete für neun von ihnen in mindestens einem Lauf reaching=yes, über Antworten, die die richtigen Pakete, Komponenten und Tokens nannten; wie in früheren Läufen werden die Urteile aus dem Text gewertet, nicht aus der Selbstauskunft. Der Aktionseffekt ist der deutlichste aller bisherigen Läufe: Jeder Lauf mit Anker baute mit dem genannten System, und selbst Haiku nutzte nur echte APIs — in den 66 Läufen mit Anker tauchte kein erfundenes Paket und keine erfundene Komponente auf.

Die Einleitung zu UX & Visual Design rät, dem Modell für ein Design-System ohne Katalogeintrag einen Link mitzugeben. Für diese elf zeigt der Lauf, dass der Link für einen ersten Entwurf nicht nötig ist: Der Name allein liefert auf jeder Stufe die Komponenten, Klassennamen und Tokens des Systems. Ein Link hilft weiterhin, wo Aktualität zählt. Die Modelle schreiben die APIs ihrer Trainingsdaten — Fluents makeStyles, die React-Komponenten von Polaris, SLDS-Klassen ohne Lightning Web Components --, und der Abschnitt „Aktueller Stand“ jedes Eintrags sagt, wohin sich das System seither bewegt hat.

Keine der Aufgaben nutzt capture, organize, distill, express, second brain, PARA, Notizsystem oder Wissensmanagement. Beide liegen in Fortes Domäne: Aufgabe A ist sein eigenes Vorzeigeszenario (verstreutes Material fließt in ein Ergebnis), Aufgabe B der Fall der Lesemarkierungen, aus dem Progressive Summarization stammt.

Alle 18 P1-Läufe nennen PARA, Progressive Summarization und Intermediate Packets. Sonnet und Opus nennen zusätzlich Resonanz, Divergenz und Konvergenz sowie Evernote. Opus ergänzt in allen sechs Läufen Hemingway Bridge, Archipelago of Ideas und „12 favorite problems“. Haiku meldete in fünf von sechs Läufen reaching=yes über korrekten, konkreten Antworten; die Urteile werden daher aus dem Text gewertet. Die Erkennungsantworten zu CODE und BASB schöpfen aus einem Cluster: Jede CODE-Antwort erklärt sich über BASB; Opus nennt CODE „the core framework of his 'Building a Second Brain' (BASB) approach“. Das bloße „CODE method“ führt auf allen Stufen zu Forte; Sonnet ergänzt: „The acronym is also used in other fields, so the meaning depends on context.“

Was die Baselines schon tun: Alle sechs Baselines von Aufgabe A bauten zuerst eine Gliederung und durchsuchten den Stapel danach — der Geist der Methode ohne ihre Schritte. Beide Opus-Baselines sortierten nach Handlungsrelevanz in die vier PARA-Kategorien; eine verdichtete in Schichten („Distill in layers. Bold the key passages in what you collected, then write a 3–5 line summary at the top of each note.“). „Building a Second Brain“ nannten sie nur in der SELF:-Zeile, nie in der Antwort. Die Baselines von Haiku und Sonnet taten nichts davon. Keine Baseline von Aufgabe B zeigte ein Forte-Merkmal; sie griffen zu atomaren Notizen und Spaced Repetition (sechs von sechs).

PARA zu nennen erzeugt PARA und geht selten darüber hinaus: die vier Kategorien in zwölf von zwölf Läufen, CODE einmal, Progressive Summarization zweimal, Intermediate Packets und Resonanz nie; jede Ausnahme ist ein Opus-Lauf. BASB zu nennen erzeugt die ganze Methode: CODE 12 von 12, Progressive Summarization mit Schichten 12 von 12, Intermediate Packets 11 von 12, Resonanz 8 von 12, PARA 11 von 12. Auf Haiku: „Progressive summarization: bold the key sentence in each highlight and each note“ und „Build intermediate packets: short, self-contained notes on single ideas“. Die Hälfte der Methode, die verdichtet und Ergebnisse liefert, trägt der PARA-Anker also nicht; BASB ist durch keinen bestehenden Anker abgedeckt. CODE allein ist auf der schwachen Stufe schwächer: Haiku lieferte in Aufgabe A die vier Schritte, aber nie Progressive Summarization, PARA oder Intermediate Packets, und widersprach einmal der Methode: „Sort by topic, not by source type.“ Auf Sonnet und Opus erreicht CODE den Großteil von BASB.

Keine der Aufgaben verwendet capture, distill, second brain, PARA, wiki, link, copy, archive oder delete.

Die Baselines sind schon diskret. Kein Lauf in keiner Bedingung schrieb Arbeitgeber, Kosten, Direktnachricht oder Seitenhieb in den Pull Request; die Leck-Regel bringt hier also keinen messbaren Zugewinn, sie hält fest, was die Modelle ohnehin tun. Die Kopier-Regel bringt einen. Alle zwölf Baseline- und Anker-Läufe kopierten das Design-Dokument in die privaten Notizen, die Anker-Läufe oft als ordentliche Resources-Seite. Unter dem Contract verwiesen Sonnet und Opus in vier von vier Läufen auf das Dokument. Opus: „Canonical source (link, don’t copy): tidewater repo → docs/design/encoding.md“. Haiku nannte das Dokument als Single Source of Truth und kopierte es darunter trotzdem: „Read it there, don’t rely on this summary.“

Am deutlichsten wirkt der Capture-Filter. Elf von zwölf Baseline- und Anker-Läufen gaben dem Sauerteig-Artikel und dem Finanzierungs-Podcast einen Platz, in der Inbox oder einem neuen Archivordner, oft mit einer Stub-Notiz; manche fragten danach, ob sie bleiben sollen. Nur ein Anker-Lauf auf Opus lehnte beide ab und fragte. Alle sechs Contract-Läufe ließen sie weg und fragten; Opus fragte ausdrücklich nach den Favorite Problems: „Do sourdough or fundraising match any of your 12 Favorite Problems?“ Fünf von sechs Contract-Läufen benannten außerdem die Themenordner als Widerspruch zur Ablage-Regel und schlugen eine P.A.R.A.-Struktur als Verschiebungen vor, die auf Bestätigung warten; kein Baseline- oder Anker-Lauf tat das.

Zwei Regeln zeigten keinen Zugewinn, weil die Baselines sie schon befolgen: Der Absatz des Besitzers blieb in allen achtzehn Läufen wörtlich erhalten, und kein Lauf löschte etwas am Projektende, bis auf einen Anker-Lauf auf Opus, der eine geleerte todo.md gelöscht hätte. Die andere Hälfte der Verschiebe-Regel, ein fertiges Projekt aus Projects herauszunehmen, brachten die Anker allein in sechs von sechs Läufen. Unter dem Contract tat Opus dasselbe und ließ den Ordner zusätzlich aktiv, solange zwei Todos offen waren; Sonnet ließ den Ordner in zwei von zwei Läufen an seinem Platz und legte einen Unterordner archive/ an, und ebenso in zwei von zwei Läufen mit umformulierter Regel („when a project ends, it leaves Projects“). Die Umformulierung half nicht und wurde nicht übernommen.

Die Hemingway Bridge erschien nur unter dem Contract: in 14 von 18 Läufen, alle zwölf auf Haiku und Opus, zwei von sechs auf Sonnet.

Bestanden auf der mittleren und der starken Stufe. Der Contract entscheidet die beiden Konflikte, die die Anker offenlassen oder andersherum entscheiden, Link gegen Kopie und alles erfassen gegen erfassen, was anschließt, in acht von acht Läufen auf Sonnet und Opus, die Anker in einem von acht. Gegen Lecks bringt er keinen messbaren Schutz, weil die Baselines nicht lecken. Sonnet übergeht unter dem Contract die Regel zum Projektende, obwohl die Anker allein sie hervorbringen; das ist als bekannte Schwäche festgehalten, nicht mit einer Formulierung repariert, die nicht half. Auf Haiku legte ein Lauf die Grenzregel zu streng aus und ließ die öffentlichen Benchmark-Zahlen aus dem Pull Request weg, weil sie aus den privaten Notizen stammten. Der Contract kam mit #894 in den Katalog, mit dem Text der überarbeiteten Fassung aus dem Issue. Nach dem Review wurden zwei Regeln zur Klarheit umformuliert, ohne neue Testläufe: Express sammelt das Archipelago of Ideas jetzt im Ordner des persönlichen Gehirns für das Projekt, und die Hemingway Bridge kommt in die Notizen des persönlichen Gehirns zu dem Projekt; keine der beiden liest sich mehr als Projekt-Repository. Ein zweiter Review-Durchgang lässt beide nur noch gelten, wenn der Besitzer in der Sitzung um sein persönliches Gehirn gebeten hat, passend zur Regel, es nur auf Zuruf zu lesen.

„I need a one-page internal proposal for my team: Cut our telemetry storage cost by switching timestamps to delta-of-delta encoding.“ Der Notizordner, in dem die Sitzung läuft, enthält die Kickoff-Notizen des Projekts und eine Gorilla-Zusammenfassung unter Resources. Der Prompt ergänzt: „I also keep another notes folder at ~/other-notes/ from my side project“, mit Benchmarks, einem Blog-Absatz im Entwurf und 32 Links, und fragt, welche Dateien der Agent lesen und schreiben wird, und nach dem Entwurf. Der Prompt lädt weder dazu ein, den anderen Ordner zu lesen, noch verbietet er es.

Jeder Baseline- und Anker-Lauf plante, den anderen Ordner zu lesen, die meisten gezielt („only the NYC taxi benchmark file“), und mehrere versprachen, dort nichts zu schreiben. Alle sechs Contract-Läufe lehnten ab, ihn zu öffnen, und nutzten die Zahlen, die der Besitzer getippt hatte. Opus: „I won’t read ~/other-notes/. It’s a separate second brain, and I keep to this folder. I’ll use the tidewater numbers you gave in chat and label them as yours. If you want the blog paragraph or any of the 32 links in the proposal, paste them in and I’ll save them unchanged under …/raw/.“ Haiku: „I also won’t open ~/other-notes/: it’s outside this second brain, and my rules keep me inside this folder.“

Der Capture-Filter wiederholte den Lauf darüber: Sechs von sechs Contract-Läufen ließen den Sauerteig-Artikel und den Finanzierungs-Podcast weg und fragten, gegen keinen von zwölf Baseline- und Anker-Läufen; drei Anker-Läufe legten sie ungefragt in einen neuen Ordner archive/ oder resources/. Fünf von sechs Contract-Läufen benannten die Themenordner und schlugen eine P.A.R.A.-Struktur als Verschiebungen vor, die auf Bestätigung warten; ein Anker-Lauf auf Sonnet behielt die Themenordner und ergänzte PARA-Rollen als Kopfzeilen der Notizen. Der Absatz des Besitzers blieb in allen achtzehn Läufen wörtlich erhalten.

Die Schwäche des früheren Entwurfs am Projektende ist verschwunden. Unter dem Contract mit einem Gehirn verteilte Sonnet den Vortragsordner in zwei von zwei Läufen auf Resources und Archive, wie Haiku und Opus, und beide Opus-Läufe ließen den Ordner zusätzlich in Projects, solange zwei Todos offen waren. Die Anker allein bringen die Aufteilung ebenfalls, sechs von sechs; diese Regel zeigt also keinen Zugewinn gegenüber den Ankern, hält aber jetzt auf jeder Stufe. Ein Anker-Lauf auf Opus hätte eine geleerte todo.md gelöscht; kein Contract-Lauf löschte etwas.

Die Hemingway Bridge oder eine Notiz, wo es weitergeht, erschien in 18 von 18 Contract-Läufen und in keinem der 36 Läufe ohne Contract. Das Archipelago of Ideas erschien nur unter dem Contract, in allen sechs Läufen von Aufgabe D und in vier von sechs Läufen von Aufgabe B.

Bestanden auf allen drei Stufen. Gegenüber den drei in einem Satz genannten Ankern entscheidet der Contract die Ordnergrenze (6 von 6 gegen 0 von 6), den Capture-Filter (6 von 6 gegen 0 von 6) und die Themenstruktur (5 von 6 gegen 0 von 6), und er bringt die Hemingway Bridge und das Archipelago of Ideas, die die Anker allein nie hervorbrachten. Der Contract-Text wurde so übernommen, wie er in #894 formuliert ist, ohne Änderungen.