Verifikation vor Vertrauen: FTT und Poka Yoke

Frag in einem beliebigen Unternehmen, ob ein bestimmtes Arbeitsergebnis gut ist, und die Antwort kommt meistens als Gefühl. "Sieht gut aus." "Passt." "Kann raus." Jemand schaut kurz drüber, nickt, und das Ding ist freigegeben. Qualität ist in diesem Modell ein Urteil, das eine Person im Vorbeigehen fällt (und die manchmal überhaupt nicht die fachliche Kompetenz, sondern nur die Epauletten auf den Schultern hat).

Das funktioniert, solange diese eine Person jedes Ergebnis selbst prüft und immer denselben Maßstab anlegt. Es geht in dem Moment kaputt, in dem mehr Arbeit durchläuft, als ein einzelner Kopf ansehen kann. Dann hängt "fertig" davon ab, wer hingeschaut hat und wie viel Zeit er gerade hatte. Mal ist der Maßstab streng, mal nachlässig, und keiner kann sagen, wie gut die Arbeit wirklich war, weil es keine Definition von "gut" gibt, die unabhängig vom Prüfer existiert. Qualität, die auf einem Urteil beruht, ist nicht steuerbar, sie ist eine Meinung mit Zeitstempel.

Sobald AI-Operatoren echte Arbeit produzieren, wird dieses Modell endgültig untragbar. Ein Operator erzeugt in einer Stunde mehr Output, als ein Mensch an einem Tag im Detail prüfen kann. Wenn die einzige Qualitätssicherung ein Mensch ist, der am Ende kurz drüberschaut, dann ist die Qualität genau so gut wie seine Aufmerksamkeit in genau diesem Moment. Das ist keine Qualitätssicherung, das ist Hoffnung mit einem Freigabe-Button.

Verifikation kommt vor Vertrauen

In Rocket Routine OS gilt ein hartes Grundprinzip: Nichts wird ausgeliefert ohne Quality Confirmation. Kein Output eines AI-Operators, kein Übergabepunkt, kein Arbeitsergebnis verlässt seine Stufe, bevor nicht gegen definierte Kriterien geprüft wurde, ob es den Standard erfüllt.

Das klingt nach einem Detail, ist aber eine Umkehr der üblichen Reihenfolge. Im Normalfall wird zuerst vertraut und dann (vielleicht!) stichprobenartig geprüft. Ein Mitarbeiter gilt als zuverlässig, also wird sein Output nicht mehr hinterfragt. Ein AI-Operator "läuft schon ganz gut", also lässt man ihn machen. Verifikation wird zu etwas, das man erst tut, wenn schon etwas schiefgegangen ist.

Rocket Routine OS dreht das um. Vertrauen ist nicht die Voraussetzung dafür, dass etwas ausgeliefert wird. Vertrauen ist das Ergebnis davon, dass die Verifikation wieder und wieder bestanden wurde.

Vertrauen ist kein Input von Qualität. Vertrauen ist ihr Output.

Die Quality Confirmation ist deshalb keine Ermessensfrage und kein nettes Extra am Ende. Sie ist eine Pflicht, die im Role Contract jedes AI-Operators verankert ist, mit definierten Kriterien und definierten Evidenz-Typen. Der Operator muss nicht behaupten, dass seine Arbeit gut ist. Er muss nachweisen, dass sie die Kriterien erfüllt.

FTT (First Time Through): Die Qualität bekommt eine Zahl

Verifikation als Prinzip reicht nicht, solange niemand misst, wie oft sie tatsächlich bestanden wird. Genau dafür gibt es die zentrale Qualitätskennzahl in Rocket Routine OS: die FTT, First Time Through.

Die FTT misst den Anteil der Arbeitsergebnisse, die ohne Nacharbeit durch die Quality Confirmation gehen. Nicht "nach zwei Korrekturschleifen okay". Nicht "im Großen und Ganzen brauchbar". Beim ersten Durchlauf bestanden, ohne Nacharbeit. Eine Zahl, kein Gefühl.

Die Idee dahinter ist nicht neu. Philip Crosby hat schon in den 1960er Jahren "do it right the first time" formuliert, lange bevor irgendjemand an AI-Operatoren dachte. Sein Punkt war einfach und unbequem: Qualität ist nicht das, was am Ende durch Prüfen und Aussortieren übrig bleibt, sondern das, was von vornherein richtig gemacht wird. Nacharbeit ist in dieser Sicht kein normaler Teil der Arbeit, sondern der messbare Preis dafür, dass etwas beim ersten Mal den Standard verfehlt hat. Die FTT ist genau dieser Gedanke als Zahl: der Anteil der Arbeit, die beim ersten Mal richtig war.

Das verändert das Gespräch über Qualität von Grund auf. "Sieht gut aus" lässt sich nicht vergleichen, nicht über Wochen verfolgen, nicht einer Domäne oder einem Operator zuordnen. Eine FTT von 72 Prozent dagegen ist ein Fakt. Sie sagt dir, dass fast drei von zehn Ergebnissen Nacharbeit gebraucht haben, und sie zwingt die nächste Frage auf den Tisch: warum diese drei?

Solange Qualität ein Gefühl ist, kannst du über sie reden. Erst als Zahl kannst du sie verbessern.

Die FTT ist auch die Kennzahl, an der sich entscheidet, ob ein AI-Operator mehr Verantwortung bekommt. Steigt sie in einer Domäne stabil über einen definierten Schwellenwert, rechtfertigt das den nächsten Schritt. Sinkt sie, ist die Rückstufung die richtige Antwort. Daten schlagen Meinungen, gerade bei der Frage, wem man wie viel Ausführung überlässt.

Poka Yoke: Den Fehler strukturell unmöglich machen

Eine niedrige FTT zeigt, dass etwas wiederholt schiefgeht. Die entscheidende Frage ist, was man dann tut. Der übliche Reflex ist, die Person enger zu führen. Mehr Kontrolle, mehr Reminders, mehr "pass besser auf". Das ist der teuerste und unzuverlässigste Weg, weil er gegen die menschliche Natur arbeitet und bei jedem neuen Durchlauf neu aufgebracht werden muss.

Rocket Routine OS geht den anderen Weg, und der kommt direkt aus der Fertigung. Das Prinzip heißt Poka Yoke: Gestalte den Prozess so, dass der Fehler gar nicht erst entstehen kann. Nicht "merk dir, das Kabel richtig herum einzustecken", sondern ein Stecker, der nur in einer Richtung passt. Der Fehler wird nicht mehr abgefangen, er wird konstruktiv ausgeschlossen.

Übertragen auf Wissensarbeit heißt das: Wenn ein bestimmter Fehler wiederholt auftritt, wird nicht der Operator ermahnt, sondern die Routine umgebaut. Eine Pflichtprüfung wird eingezogen, ein Schritt in der Reihenfolge erzwungen, ein Output ohne ein bestimmtes Pflichtfeld gar nicht erst zugelassen. Der Role Contract eines AI-Operators ist nach genau diesem Prinzip entworfen.

Dahinter steht die Überzeugung, die das ganze System trägt: Prozesse sind das Problem, nicht Menschen. Wenn ein Fehler wiederholt passiert, ist nicht der Akteur unfähig, sondern der Prozess schlecht designt. Das ist keine nette Haltung gegenüber Mitarbeitern, das ist die einzige Variante, die skaliert. Einen Menschen kannst du ermahnen. Einen Prozess kannst du reparieren.

So greifen die drei Teile ineinander. Die Verifikation legt fest, dass geprüft wird. Die FTT macht sichtbar, wie oft die Prüfung bestanden wird. Das Prinzip Poka Yoke sorgt dafür, dass die häufigsten Durchfaller beim nächsten Mal strukturell nicht mehr möglich sind. Verifikation ohne Messung bleibt eine Geste. Messung ohne Poka Yoke bleibt eine Diagnose ohne Therapie.

Company 0

Bei Rocket Routine lag die FTT des Content-Marketing-Operators eine Zeit lang bei rund 72 Prozent. Das hieß, fast jeder dritte Output ging zurück in die Nacharbeit. Statt den Operator enger zu führen, habe ich mir die Verteilung der Nacharbeit angeschaut, also nicht nur, wie oft etwas zurückging, sondern warum.

Die größte einzelne Ursache war nicht Stil und nicht Faktentreue. Es war Scope-Drift: Der Operator zog in abgeleitete Posts immer wieder Konzepte herein, die der Quell-Artikel der Woche gar nicht behandelt hat. Ein LinkedIn-Post über Adoption Levels erwähnte plötzlich den Control Tower, ein X-Post brachte OMPRIKL ins Spiel, obwohl der Artikel davon kein Wort sagte. Jedes Mal ging der Output zurück.

Die Lösung war kein Reminder. Sie war ein Poka Yoke im Role Contract. Bevor irgendein abgeleiteter Output die Quality Confirmation erreicht, muss der Operator zuerst die Liste der Konzepte ausgeben, die der Quell-Artikel tatsächlich abdeckt, und jede inhaltliche Aussage gegen diese Liste prüfen. Ein Output, der ein Konzept außerhalb der Liste nennt, wird gar nicht erst zur Freigabe durchgelassen.

Der Fehler verschwand nicht, weil der Operator besser wurde. Er verschwand, weil der Prozess ihn nicht mehr zuließ.

Über die folgenden drei Wochen stieg die FTT dieses Operators von 72 auf 91 Prozent und blieb dort. Die Kategorie Scope-Drift tauchte in der Nacharbeit nicht mehr auf. Nicht, weil ich besser kontrolliert habe, sondern weil der Fehler keinen Weg mehr durch die Routine fand.

Was als Nächstes kommt

Verifikation, FTT und Poka Yoke sind zusammen der Grund, warum man AI-Operatoren in einem Unternehmen überhaupt steuern kann, ohne ständig hinter ihnen herzuräumen. Qualität ist in diesem Modell kein Urteil, das am Ende jemand fällt. Sie ist eine strukturelle Voraussetzung, die vor der Auslieferung erfüllt sein muss.

Damit ist der konzeptionelle Bogen fast geschlossen. In der nächsten Woche schaue ich mir an, was am ersten Tag tatsächlich passiert, wenn ein Unternehmen mit Rocket Routine OS startet. Kein Framework im Abstrakten, sondern der konkrete Einstieg: was du am Tag eins in der Hand hast und was in der ersten Woche läuft.

Wenn du ein gründergeführtes B2B-Unternehmen mit 15 bis 50 Mitarbeitern führst und willst, dass Qualität eine überprüfbare Zahl ist statt einer Meinung: rocket-routine.com