Zusammenfassung

  • Der individuelle Informational Internet-Draft AER-1 Revision 04 verlangt Blätter aus der jeweiligen receipt_id; die beobachtete öffentliche Workflow-Seite verwendet seq:receipt_hash.
  • Alle fünf Schrittendpunkte antworteten mit HTTP 200, alle Belege wurden bestätigt und alle Output-Hashes stimmten mit dem Manifest überein. Die Seitendefinition reproduziert ihre veröffentlichte Wurzel, die Entwurfsdefinition eine andere.
  • Python-, Rust- und TypeScript-Helfer im fixierten Commit folgen Revision 04. Der 43/43-Vektorsatz trägt noch die Kennzeichnung -03 und enthält keinen Workflow-Test.

Eine Normänderung ohne abgeschlossene Umstellung

Am 29. September 2026 erschien Revision 04 von AER-1: A Portable Execution Receipt for AI Agent Tool Calls. Das Dokument ist ein individueller Internet-Draft mit angestrebtem Status Informational, kein RFC und keine Annahme durch eine IETF-Arbeitsgruppe.

Seine Regel für Workflow-Wurzeln ist trotzdem eindeutig. Jedes Blatt soll der SHA-256-Hash der UTF-8-Bytes einer Schritt-receipt_id sein. Benachbarte 32-Byte-Digests werden roh verkettet und erneut gehasht. Bei einer ungeraden Anzahl wird der letzte Digest dupliziert. Der Abschnitt nennt die Konstruktion zunächst empfohlen, verpflichtet Implementierungen anschließend aber mit MUST. Die frühere Erlaubnis für Alternativen sei entfernt worden, weil verschiedene Wurzeln für denselben Workflow die implementierungsübergreifende Verifikation brechen.

Die derzeitige öffentliche Beispielseite verwendet eine andere Blattdefinition. Sie ruft jeden Schritt ab, verlangt einen positiven Integritätsstatus und bildet dann die UTF-8-Zeichenfolge aus Sequenznummer, Doppelpunkt und kleingeschriebenem Output-Hash: seq:receipt_hash.

Die Folge ist messbar. Die Seite veröffentlicht a4b2fcb4684cec481e4ece889ed15c7d9e47e58d9ba4fb02ea354c0cb2ca44c4. Ihre eigene Regel erzeugt exakt diesen Wert. Die Regel aus Revision 04 erzeugt mit denselben fünf Schritten 7c4817ca249edfeae259b98abf63ed38a31d9dbeebf5ee23139410a7a7f63b37.

Damit ist nicht bewiesen, dass ein Hash falsch berechnet wurde. Bewiesen ist, dass die Umstellung des Vertrags nicht abgeschlossen ist.

Die fünf Schritte bleiben gültig

Eine saubere Einordnung beginnt mit dem, was nicht fehlschlug. Alle fünf öffentlichen Verifikationsendpunkte antworteten erfolgreich. Jeder Beleg meldete verified: true. Jeder zurückgegebene Output-Hash entsprach dem Wert im Workflow-Manifest.

Die Seite prüft also reale Einzelbelege und bindet die erwarteten Hashes. Ihre Binärbaumregel funktioniert. Revision 04 verwendet dieselbe Elternregel und dieselbe Duplizierung ungerader Endknoten. Nur die Blätter repräsentieren andere Dinge.

Das ist der Grund, warum die Oberfläche nicht pauschal als „kaputt“ bezeichnet werden sollte. Sie ist intern konsistent. Der Schaden entsteht erst an der Portabilitätsgrenze: Ein unabhängiger Verifikator, der den aktuellen Text befolgt, muss ihre Wurzel ablehnen oder zumindest als nicht konform zu seiner Konstruktion kennzeichnen.

Eine nackte Wurzel löst dieses Problem nicht. Aus 64 Hexadezimalzeichen lässt sich die Blattsemantik nicht zurückgewinnen. Wer sie in eine Freigabe, eine Zahlung oder einen Prüfbericht übernimmt, braucht deshalb den Konstruktionsvertrag dazu.

Das Repository zeigt den Zielzustand

Der öffentliche Quellstand wurde bei Commit f3aacbb5cf7d00977fd107afc34fc24b08c4f569 fixiert. Dort bildet Python Blätter aus Beleg-IDs. Rust hasht die ID-Bytes. TypeScript hasht die UTF-8-Darstellung der IDs. Diese drei geprüften Helfer entsprechen Revision 04 einschließlich der Behandlung ungerader Ebenen.

Der Browsercode der öffentlichen Seite verbleibt bei seq:hash. Damit liegen Entwurf und geprüfte Bibliothekshelfer auf der einen, die laufende Seite auf der anderen Seite der Migration.

Running-Code Primacy verlangt, beide Zustände zu benennen. Der veröffentlichte Entwurf darf laufende historische Belege nicht rückwirkend umdeuten. Die laufende Seite darf wiederum nicht allein festlegen, was ein portables AER-1-Profil für andere Implementierungen bedeutet. Adoption ist erst erreicht, wenn Text, Tests, Bibliotheken und Betrieb denselben Kompatibilitätssatz bilden.

Lu Hengs Prinzip einer minimalen Anfangsspezifikation ist dabei keine Aufforderung zur Unbestimmtheit. Der gemeinsame Kern soll schmal sein, aber lokale, deterministische Prüfung ermöglichen. Welche Bytes ein Blatt bilden, gehört zwingend in diesen Kern.

Warum 43/43 die Migration nicht absichert

Das Repository nennt für sieben Sprachen 43 bestandene von 43 Tests. Die dokumentierte Prüffläche umfasst Pflichtfelder, UUIDs, Zeitangaben, striktes Base64 und UTF-8, Output-Commitments, Provenienzklassen, Producer-Profil, optionale Anker und Roundtrips.

Workflows werden nicht aufgeführt. Der Vektorindex bezeichnet sich als Revision -03. Kein Vektor testet Workflow, Merkle-Wurzel, Schrittfolge, Schritt-Hash oder die Duplizierung eines ungeraden Blatts.

Ein perfektes Ergebnis ist damit vollständig vereinbar mit einer ungetesteten neuen Funktion. Die Zahl ist innerhalb des Korpus belastbar. Außerhalb davon ist sie kein Nachweis.

Ein Revisions-04-Vektor muss die fünf IDs, Blatt-Inputs, Blatt-Digests, Zwischenebenen und die erwartete Wurzel festschreiben. Öffentliche Seite, API und alle Sprachimplementierungen müssen denselben Vektor verwenden. Erst dann wird aus der Migrationsabsicht eine interoperable Beobachtung.

„Verifiziert“ ist kein atomarer Zustand

Mindestens sechs Aussagen sind zu trennen: Die gespeicherten Schrittbytes passen zum Commitment. Der abgerufene Hash passt zum Manifest. Das Blatt folgt einer benannten Konstruktion. Ein zweiter Verifikator erhält mit derselben Konstruktion dieselbe Wurzel. Ein externer Zeuge hat das Commitment registriert. Die Toolaktion hat außerhalb des Belegsystems die erwartete Wirkung erzielt.

Der öffentliche Workflow belegt die ersten beiden Punkte und die Konsistenz seiner eigenen Konstruktion. Ein als teilweise ausgewiesener Nostr-Anker bezeugt außerdem einen veröffentlichten Wert. Er entscheidet nicht, ob die Blattdefinition des Entwurfs verwendet wurde.

Auch Provenienz bleibt unverändert. Eine von einem externen Agenten gemeldete Aktion wird durch Aggregation nicht zur eigenen Ausführung. Eine Gateway-Beobachtung beweist nichts außerhalb ihrer Sicht. Ein Preisabruf ist kein Settlement.

Eine belastbare Oberfläche ergänzt daher das Objekt: Schrittbytes verifiziert, Manifest gebunden, Wurzel kompatibel mit Konstruktion X, Anker beobachtet oder Außenwirkung bestätigt.

Migrationskontrolle statt stiller Neuberechnung

Eine portable Wurzel benötigt Schema-Versionen, Konstruktionskennung, Bytekodierung, Hash- und Elternregel, Odd-Node-Regel, Ausgabeformat, geordnete Schritt-IDs und Commitments, Provenienz, Definition der finalen Output-Bytes, Ankerumfang und Testvektor-Version.

Die annehmende Stelle hält zusätzlich Richtlinienversion und Entscheider fest. Dadurch bleibt später nachvollziehbar, welcher Baum genehmigt wurde.

Bei einer Umstellung von seq:receipt_hash auf receipt_id dürfen alte öffentliche Wurzeln nicht still neu berechnet werden. Die alte Verpflichtung bleibt bestehen; eine versionierte Nachfolgerverpflichtung dokumentiert die neue. Während der Übergangsphase sollten beide Werte nebeneinander erscheinen. So wird Migration sichtbar, ohne Geschichte umzuschreiben.

Quellen und Grenzen

Die Beobachtung wurde am 30. September 2026 in der Zeitzone Asia/Shanghai eingefroren. Sie belegt eine reproduzierbare Abweichung zwischen Revision 04, einem fixierten öffentlichen Commit und der damals aktiven Seite. Sie belegt weder Täuschung noch eine SHA-256-Schwäche, Kompromittierung, Ausfall einer Außenwirkung, breite Adoption oder IETF-Billigung. Geprüft wurden nur die Workflow-Helfer in Python, Rust und TypeScript. Entwurf und Dienst können sich ändern.