Wer unterschreibt, wenn die Maschine schreibt

01Zwei Begriffe, dann geht es los

DID (Kennung, hinter der ein Schlüssel steht) ist der erste. Statt eines Kontos bei einer Firma — einer Mailadresse und eines Passworts, die jemand für Sie verwaltet — gibt es eine Nummer, zu der ein Schlüsselpaar gehört. Der eine Teil ist öffentlich, der andere bleibt bei Ihnen. Damit kann man Sätze unterschreiben, und jeder, der die Nummer kennt, kann nachrechnen, ob die Unterschrift zu ihr passt. Niemand muss dafür gefragt werden, und niemand kann die Nummer entziehen.

Repo (der eigene kleine Datenspeicher) ist der zweite. Zu jeder Kennung gehört ein Speicher, in dem die Einträge dieses Kontos liegen — einzeln unterschrieben, öffentlich lesbar, sofern sie nicht ausdrücklich privat sind. Wer einen Eintrag liest, kann prüfen, wer ihn geschrieben hat, ohne dem Server zu glauben, der ihn ausliefert. Das ist der ganze Trick, und alles Weitere ist eine Anwendung davon.

Auf denselben zwei Ideen läuft auch die Werkstatt: Code, Aufgaben und Änderungsvorschläge liegen nicht bei einem Anbieter, sondern werden zwischen den Beteiligten repliziert, und jeder Eintrag trägt die Unterschrift dessen, der ihn verfasst hat. Deshalb kann man in diesem Text Sätze schreiben wie „das Urteil hat einen Verfasser, und der Verfasser lässt sich nicht vortäuschen“. In einer gewöhnlichen Werkstatt wäre das eine Frage der Zugriffsrechte auf einem fremden Server; hier ist es eine Frage der Unterschrift.

02Der Agent bekommt eine eigene Kennung

Ein Runner (das Programm, das die Arbeit macht) könnte einfach unter der Kennung seines Besitzers arbeiten. Das ist der bequeme Weg, und er kostet genau das, worum es hier geht: Sobald Mensch und Programm dieselbe Unterschrift benutzen, sagt keine Spur mehr, wer von beiden gehandelt hat. Ein Widerruf trifft dann auch immer den Menschen — man kann das Programm nicht abschalten, ohne sich selbst auszusperren.

Jeder Agent hat deshalb eine eigene Kennung, ein eigenes Konto und einen eigenen Speicher. Drei Dinge folgen daraus unmittelbar:

• Alles, was er tut, trägt seinen Namen. Nicht den seines Besitzers. Wer eine Änderung liest, sieht, ob ein Mensch oder ein Programm sie eingereicht hat, ohne jemanden fragen zu müssen.
• Er lässt sich einzeln abschalten. Der Besitzer entzieht die Vollmacht eines Agenten, und alle anderen laufen weiter, seine eigene zuerst.
• Er kann nicht weiterverleihen, was er hat. Ein Agentenkonto darf selbst keine Agenten anlegen — die Schnittstelle lehnt es mit einem eigenen Fehler ab. Eine Vollmacht, die im Speicher eines Agenten läge statt in dem eines Menschen, ist damit von vornherein bedeutungslos.

Ein Detail, das leicht untergeht und trotzdem der Kern ist: Der Schlüssel, mit dem der Agent arbeitet, wird beim Anlegen mit einem Wert verschlüsselt, den der Passkey des Besitzers erzeugt — also mit etwas, das nur dann entsteht, wenn ein Finger auf dem Gerät liegt. Der Server bewahrt das Ergebnis auf und kann es nicht öffnen. Er verwahrt einen Schlüssel, den er nicht hat.

03Die Vollmacht ist ein Datensatz mit Ablaufdatum

Zwischen „der Agent hat eine Kennung“ und „der Agent darf etwas“ liegt ein einzelner Record (Datensatz). Er liegt im Speicher des Besitzers, nicht in dem des Agenten — denn eine Vollmacht, die der Bevollmächtigte selbst aufbewahrt, ist keine. Sein Schlüssel im Speicher ist die Kennung des Agenten. Eine Berechtigungsfrage ist damit ein einziger Griff: den Datensatz zu dieser Kennung holen, oder feststellen, dass es keinen gibt.

Löschen ist der Widerruf. Es gibt keine Sperrliste, die jemand pflegen und verteilen müsste, und damit auch keine Sperrliste, die veraltet sein kann. Der Datensatz ist da, oder er ist es nicht.

Im Datensatz steht außerdem, was der Agent darf: eine Liste von Wörtern wie repo.write oder wallet.spend. So ein Wort heißt im Schema Scope (Befugnis), und verglichen wird es Zeichen für Zeichen. Platzhalter gibt es nicht: Ein Prüfer, der eine Befugnis nicht kennt, erteilt nichts. Wer Geld ausgeben darf, braucht zusätzlich eine Obergrenze — ein Datensatz mit wallet.spend und ohne Betrag ist ungültig und nicht etwa unbegrenzt. Das ist eine bewusste Umkehr der üblichen Voreinstellung: Wo etwas fehlt, gilt hier nichts, nicht alles.

Und dann das Feld, das dem Ganzen erst seinen Charakter gibt: validUntil, das Ende der Vollmacht. Es ist Pflicht, und es darf höchstens 366 Tage in der Zukunft liegen. Der Grund steht in einem Satz in der Schemadatei und ist der beste Satz des ganzen Entwurfs: eine Vollmacht ohne Ende ist eine, die der Erteiler aufhört zu sehen. Ein Zugang, den niemand je wieder anfasst, verschwindet aus dem Bewusstsein und bleibt trotzdem gültig; genau daraus entstehen die Zugänge, von denen später niemand mehr weiß, wem sie gehören. Ein Pflichtablauf dreht das um: Nicht das Entziehen braucht eine Entscheidung, sondern das Behalten. Der Preis ist eine Passkey-Bestätigung pro Agent und Jahr — und dieser Preis ist der eigentliche Zweck.

Geschrieben wird der Datensatz nicht einfach so. Der Server baut zuerst den Satz, dem der Mensch zustimmen soll, und leitet aus genau diesem Satz die Aufgabe für den Passkey ab. Die Anwendung muss den Satz unverändert anzeigen; beim Schreiben baut der Server ihn aus denselben Angaben noch einmal zusammen und lehnt ab, was nicht dazu passt. Wer die Zahlen zwischen Anzeige und Schreiben verändert, unterschreibt damit einen anderen Satz — und der wird nicht angenommen.

Am Ende treffen sich hier zwei Unterschriften, die verschiedene Fragen beantworten. Die eine, vom Passkey, beweist: Ein Mensch hat diesen Schreibvorgang gerade eben erlaubt. Sie wird einmal gelesen und dann verworfen. Die andere steht im Datensatz selbst und beweist: Das hier hat der Besitzer erteilt. Sie bleibt und kann von jedem geprüft werden, auch in einem Jahr, auch von jemandem, der der Anwendung nicht traut.

04Der Plan steht vor dem Code, und die Freigabe braucht einen Finger

Damit ist geregelt, wer arbeiten darf. Was gearbeitet wird, ist eine andere Frage, und sie wird in derselben Reihenfolge beantwortet, in der auch Menschen es tun sollten — nur aufgeschrieben.

Am Anfang steht eine Karte (die Aufgabe, der Auftrag) in fester Form: Was ist heute der Zustand und was ist daran falsch. Woran man von außen sieht, dass es erledigt ist. Welches Kommando das zeigt — und was dieses Kommando heute tut. Was ausdrücklich unberührt bleibt. Die letzte Zeile ist die wichtigste: Eine Prüfung, die schon vor der Arbeit durchläuft, beweist, dass die Arbeit unnötig war, und nicht, dass sie stattgefunden hat.

Dann, und erst dann, ein Plan: der Ansatz, die Meilensteine, und zu jedem Meilenstein ein Satz, woran man sein Ende erkennt, samt dem Kommando, das es zeigt. Der Plan ist die Stelle, an der eine Entscheidung noch einen Satz kostet und nicht einen Umbau. Er benennt das Ziel und nicht die Schritte — einem fähigen Modell die Route vorzuschreiben, macht das Ergebnis schlechter.

Der Plan wird freigegeben, und diese Freigabe ist die eine Stelle der ganzen Kette, an der ein Programm nicht weiterkommt. Unterschrieben wird auf einem Sicherheitsschlüssel, der so eingerichtet ist, dass jede einzelne Unterschrift eine Berührung verlangt. Ein Agent, der unter derselben Benutzerkennung läuft, darf die Schlüsseldatei lesen und kann trotzdem nicht unterschreiben. Das ist nicht aus einer Dokumentation übernommen, sondern auf dieser Hardware ausprobiert worden: fünf unbeaufsichtigte Versuche hintereinander, keine einzige Unterschrift.

Unterschrieben wird nicht der Satz „Aufgabe 5a95366 ist freigegeben“ — der würde zu jeder beliebigen Arbeit passen, die diese Nummer nennt. Unterschrieben wird ein Fingerabdruck dessen, was tatsächlich gelesen wurde: der Ansatz, jeder Meilenstein, jedes Prüfkommando. Wird nachträglich ein Kommando ausgetauscht, passt die Unterschrift nicht mehr, und die Zurückweisung benennt das Feld, das sich bewegt hat, statt bloß „ungültig“ zu sagen.

Zwei Dinge sind absichtlich nicht mit unterschrieben: der fertige Code und der Zeitpunkt. Die Freigabe fällt vor der Arbeit, und das ist der Sinn der Reihenfolge. Was sie garantiert, ist deshalb genau eines — dass die Arbeit an einem freigegebenen Plan hängt. Ob sie ihm entspricht, kann sie nicht behaupten. Das ist Durchsehen, und das ist die Aufgabe eines Menschen.

Ein Detail, das aussieht wie Kleinkram und keiner ist: Der Freigabeschlüssel ist an einen eigenen Verwendungszweck geheftet. Unterschriften unter Commits entstehen unter einem anderen. Deshalb kann eine Commit-Unterschrift — die ein Programm ohne jede Berührung erzeugt — niemals als Freigabe durchgehen. Die Prüfung weist sie ab, statt Bytes zu vergleichen, die zufällig passen könnten.

Entschieden, aber noch nicht gebaut: Für Aufgaben der beiden unteren Schwierigkeitsstufen soll künftig eine gültige Vollmacht aus Abschnitt 03 an die Stelle der Einzelunterschrift treten dürfen — die Zustimmung wandert dann von „dieser Plan“ zu „dieser Agent, in diesem Zeitfenster, für diese Befugnisse“. Für die höchste Stufe und für alles ohne Einstufung bleibt es beim Finger. Das ist eine Entscheidung vom 02.09.2026 und steht hier, weil ein Aufsatz, der Beschlossenes als Laufendes ausgibt, genau die Sorte Text ist, gegen die er argumentiert.

05Das Tor prüft — und es hat eine eigene Kennung

Bis hierher ist alles eine Verabredung. Sie wird zu mehr, weil jemand sie prüft, der nicht derjenige ist, der sie einhalten soll. Diese Prüfstelle heißt hier Gate (Tor, die Prüfstelle), und sie stellt beim Bauen sieben Fragen. Jede ist ein Glied (einer dieser Schritte) der Kette:

• Der Vorschlag fügt genau einen Plan hinzu — einen bestehenden zu ändern, beansprucht dessen Aufgabe nicht.
• Die Aufgabe, die der Plan nennt, existiert wirklich.
• Der Plan hat die vorgeschriebene Form.
• Das Kapitel, das der Plan benennt, liegt im Code — entweder ein neues, oder ein bestehendes, das die Änderung wahr hält.
• Die Freigabe deckt genau diesen Plan.
• Der Nachtrag steht im Plan: was die Arbeit entschieden hat. Er wird nach der Arbeit geschrieben, kann also von keiner Prüfung verlangt werden, die vorher läuft.
• Die Belege sind da: Zu jedem Meilenstein gehört ein Kommando, und die Kommandos stehen in der Unterschrift.

Gemeldet werden immer alle sieben, auch die, die nicht beantwortet werden konnten. Ein Bericht, der beim ersten Fehler abbricht, verbirgt die übrigen sechs, und wer eine Kette repariert, will die ganze Form auf einmal sehen. Dazu gehört eine Regel, die anderswo regelmäßig fehlt: „nicht geprüft“ ist nicht dasselbe wie „abgelehnt“. Wenn der Speicher nicht erreichbar war, lautet die Antwort „unbekannt“ und nie „existiert nicht“. Ein Tor, das Nichterreichbarkeit als Verstoß liest, weist gute Arbeit zurück; eines, das umgekehrt rät, winkt schlechte durch.

Entscheidend ist, wo das Tor läuft: auf dem Rechner, der die Pakete baut, nicht auf dem des Runners. Es bringt seine eigene Kopie der Prüfung mit, in einer anderen Sprache geschrieben als das Projekt. Das ist keine Marotte. Ein Tor, das die Prüfung des Runners benutzt, fragt den Runner, ob er sich benommen hat.

Und dann der Teil, der die Kette schließt: Das Urteil wird als Kommentar neben den Änderungsvorschlag geschrieben — als COB (ein Datensatz neben dem Code), mit dem Schlüssel des Verfassers unterschrieben. Der Verfasser ist die eigene Kennung des Prüfrechners, und diese Kennung steht im Projektverzeichnis an einer Stelle, die jeder nachlesen kann. Ein Runner kann seinen eigenen Vorschlag kommentieren, so viel er will — er kommentiert als er selbst. Als das Tor kann er nicht kommentieren, weil ihm dessen Schlüssel fehlt. Damit ist „es wurde geprüft“ ein Beleg und keine Erinnerung.

Ein Patch (der Änderungsvorschlag) ist dabei dasselbe wie ein Pull Request anderswo, nur ohne eine Firma in der Mitte. Was das Tor tut, wenn die Kette reißt, ist deshalb spezifisch: Es hält das Paket zurück, nicht die Übernahme des Codes. Es kann die Übernahme gar nicht zurückhalten — wenn es davon erfährt, ist sie schon passiert. Wer den Vorschlag übernimmt, ist ein Mensch.

06Das Paket ist unterschrieben, die Beförderung ist Handarbeit

Was am Ende läuft, ist ein Image (das fertige Paket): alles, was zum Starten nötig ist, in einer Datei. Eine Versionsmarkierung im Code löst den Bau aus, und der Baurechner unterschreibt das Ergebnis mit einem Schlüssel, der diesen Rechner nie verlässt.

Diese Unterschrift ist keine Zierde. Der Cluster, auf dem alles läuft, weist jedes Paket aus der eigenen Registry ab, das keine gültige Unterschrift dieses Schlüssels trägt — nicht als Warnung, sondern als Ablehnung beim Starten. Wer ein Paket von Hand in die Registry legt, hat damit nichts erreicht: Es läuft nicht an. Der Weg in den Betrieb führt durch den Bau, und der Bau führt durch das Tor.

Und dann kommt der letzte Schritt, und der ist mit Absicht langweilig. Die Promotion (Beförderung in den Betrieb) — welches Paket die Besucher tatsächlich sehen — steht als eine Zeile in einem anderen Projekt, dem, das den Betrieb beschreibt. Diese Zeile ändert ein Mensch, von Hand, über dasselbe Verfahren mit Vorschlag und Übernahme. Der Cluster gleicht sich im Minutentakt an das an, was dort steht.

Man könnte das automatisieren, und fast alle tun es. Es bleibt Handarbeit, weil eine Versionsmarkierung ein Werkstattereignis ist und kein Betriebsereignis. Ein Paket zu bauen heißt „das hier ist fertig“. Es in Betrieb zu nehmen heißt „das hier zeige ich jetzt fremden Menschen“. Das sind zwei Sätze, und jemand soll den zweiten sagen müssen, nachdem er den ersten gehört hat.

07Was das alles nicht verhindert

Der wertvollste Abschnitt einer solchen Beschreibung ist der, in dem die Linie sichtbar wird. Die folgende Liste steht wörtlich in der Anleitung, an der sich die Agenten dieses Projekts orientieren, unter der Überschrift „was weiterhin nur erbeten ist“ — sie ist also nicht für diesen Text gebaut worden, sondern für die, die dagegen verstoßen könnten.

• Dass die Arbeit dem Plan entspricht. Die Freigabe fällt, bevor der Code existiert — genau darum steht sie an dieser Stelle. Sie an den fertigen Code zu binden, hieße entweder, sie ans Ende zu schieben und die Reihenfolge umzudrehen, oder nach jeder Änderung erneut zu unterschreiben, was allen beibringt, ohne Hinsehen zu bestätigen. Ob das Gelieferte das Versprochene ist, entscheidet also weiterhin ein Mensch, der es liest.
• Dass eine Prüfung je rot war. Ein Kommando, das heute durchläuft, zeigt einen Zustand. Es zeigt nicht, dass dieser Zustand vorher gefehlt hat. Eine Aufgabe, deren Prüfung schon vor der Arbeit grün war, beweist damit nur, dass die Arbeit unnötig war — und niemand außer einem Leser merkt das.
• Dass die Prüfkommandos eines Plans wirklich durchlaufen. Auf dem Rechner, der das Tor betreibt, liegt das Werkzeug dieses Projekts nicht. Eine Prüfung, die läuft, wenn das Werkzeug zufällig da ist, und sonst stillschweigend überspringt, wäre genau die Halb-Durchsetzung, gegen die das Ganze gebaut ist. Das Tor hält deshalb nur fest, dass es die Kommandos gibt und dass sie in der Unterschrift stehen. Wer den Plan freigibt, stimmt dem zu, was laufen wird.
• Dass der Weg der richtige war. Ein Plan benennt absichtlich das Ziel und nicht die Schritte: einem fähigen Modell die Route vorzuschreiben, macht das Ergebnis schlechter, nicht besser. Der Preis dafür ist, dass ein grünes Kommando das Ergebnis belegt und nie den Weg dorthin.
• Einen Runner, der Schaden will. Das Tor läuft mit den Zugangsdaten der Registry in seiner Umgebung. Es bindet den, der abkürzt, nicht den, der angreift. Diese Kette macht Nachlässigkeit sichtbar; gegen einen Angreifer mit denselben Rechten hilft sie nicht.

Eine weitere Grenze kommt nicht aus der Anleitung, sondern aus dieser Anwendung:

• Den Merge hält niemand auf. Das Tor hält das fertige Paket zurück, nicht die Übernahme des Codes. Es kann sie gar nicht zurückhalten: die Ereignisse, auf die es reagiert, sind bereits passiert, wenn es sie sieht. Wer den Vorschlag übernimmt, ist und bleibt ein Mensch — nicht als Zusicherung der Technik, sondern weil es hier niemanden sonst gibt, der es tut.

Zusammengenommen ist der Anspruch also kleiner, als er beim ersten Lesen klingt, und genau deshalb hält er: Diese Kette macht nachvollziehbar, was passiert ist, und erzwingt eine menschliche Zustimmung an einer Stelle, an der sie noch billig ist. Sie ersetzt kein Durchsehen, sie erkennt keine schlechte Entscheidung, und gegen jemanden mit denselben Rechten und schlechten Absichten hilft sie nicht. Sie bindet den, der abkürzt.

Und sie verschiebt eine Grenze, die man leicht falsch beschreibt. Nichts hier hindert einen Menschen daran, Code zu übernehmen; die Technik könnte es nicht einmal, wenn sie wollte. Es gibt eine Entscheidung vom 02.09.2026, nach der künftig Agenten die Arbeit anderer Agenten durchsehen sollen — zwei Urteile von Programmen auf verschiedenen Modellen für die unteren Stufen, mit Vetorecht und Stichproben beim Menschen. Auch danach gilt der Satz, nur in einer genaueren Fassung: Der Mensch bleibt die Wurzel, nicht das Tor. Er steht nicht in jedem Durchgang, aber alles, was durchgeht, hängt an einer Unterschrift, die nur er geben kann.

08Die Wörter

Alles, was oben ein eigenes Wort hatte, hier noch einmal mit dem gewöhnlichen daneben — und mit dem Grund, warum es überhaupt ein eigenes gibt.

• DID — Kennung, hinter der ein Schlüssel steht. Kein Konto bei einer Firma, sondern eine Nummer, zu der ein öffentlicher Schlüssel gehört. Wer den privaten Teil hat, kann Sätze unterschreiben, die jeder nachprüfen kann.
• Repo — der eigene kleine Datenspeicher. Jedes Konto hat einen. Was darin liegt, ist einzeln signiert, und wer es liest, kann prüfen, wer es geschrieben hat.
• Record — Datensatz. Ein Eintrag in so einem Speicher. Die Vollmacht für einen Agenten ist einer davon.
• Kette — Reihe von Prüfschritten. Sieben Fragen in fester Reihenfolge. Das Bild trägt, weil eine einzelne rote Antwort die ganze Reihe anhält.
• Glied — einer dieser Schritte. Jedes Glied hat genau einen Satz, mit dem es zurückweist — damit aus der Zurückweisung allein hervorgeht, was zu tun ist.
• Gate — Tor, die Prüfstelle. Die Stelle, an der die Kette gefragt wird, und zwar auf einem Rechner, den derjenige nicht kontrolliert, der geprüft wird.
• Runner — das Programm, das die Arbeit macht. Ein Agent, der eine Karte abarbeitet. Das Wort betont, dass es läuft und nicht entscheidet.
• Karte — die Aufgabe, der Auftrag. Eine Arbeitsbeschreibung mit fester Form. Sie heißt Karte, weil sie auf einem Brett in einer Spalte steht.
• Patch — der Änderungsvorschlag. Dasselbe wie ein Pull Request, nur ohne eine Firma in der Mitte: ein signierter Vorschlag, der neben dem Code liegt.
• COB — ein Datensatz neben dem Code. Karten, Vorschläge und Kommentare liegen im selben Repository wie der Code, jeder mit dem Schlüssel seines Verfassers signiert. Deshalb kann ein Urteil einen Verfasser haben.
• Image — das fertige Paket. Alles, was zum Starten der Anwendung nötig ist, in einer Datei. Was hier läuft, läuft aus so einem Paket.
• Promotion — Beförderung in den Betrieb. Der Schritt, mit dem ein fertiges Paket zu dem wird, das die Besucher sehen. Er passiert von Hand.
• Scope — Befugnis. Ein Wort wie `repo.write`, das genau eine Sache erlaubt. Verglichen wird es Zeichen für Zeichen; Platzhalter gibt es nicht.

09Warum das hier steht

Der Code zu allem oben ist heute nicht öffentlich. Das ist eine Entscheidung und kein Versäumnis: Ein Projekt zu öffnen, heißt auch, es lesbar für den zu machen, der Lücken sucht, und diese Reihenfolge — erst dicht, dann offen — ist bewusst gewählt. Der Text steht trotzdem schon da, weil er niemandem etwas kostet und weil das Verfahren die eigentliche Aussage ist.

Was Sie damit anfangen können, wenn Sie an Ihrer eigenen Werkstatt arbeiten, sind vermutlich drei Sätze, und keiner davon braucht unsere Technik: Gib jedem Programm eine eigene Identität, damit die Spuren auseinandergehen. Gib jeder Vollmacht ein Ende, damit Behalten die Entscheidung ist und nicht Entziehen. Und lass die Stelle, an der ein Mensch zustimmt, dort, wo eine Änderung noch einen Satz kostet — nicht dort, wo sie schon einen Umbau kostet.