Кратко

  • Индивидуальный Informational Internet-Draft AER-1 редакции 04 требует строить листья из receipt_id; наблюдаемая публичная страница использует seq:receipt_hash.
  • Все пять конечных точек вернули HTTP 200, все квитанции сообщили об успешной проверке, а их выходные хеши совпали с манифестом. Алгоритм страницы точно воспроизводит опубликованный корень, алгоритм черновика — другой.
  • Помощники Python, Rust и TypeScript в зафиксированном коммите следуют редакции 04. Набор из 43 векторов всё ещё помечен как -03 и не проверяет workflow-корень.

Что останется в аудиторском деле

Представим, что корень workflow уже попал в решение о доступе или оплате. Через несколько месяцев аудитор видит a4b2fcb4684cec481e4ece889ed15c7d9e47e58d9ba4fb02ea354c0cb2ca44c4. Значение совпадает с публичной страницей. Пять шагов доступны. Каждый отвечает успешно и заявляет verified: true. Все выходные хеши совпадают с манифестом.

Страница вычисляет лист как SHA-256 от UTF-8-строки, состоящей из номера шага, двоеточия и выходного хеша: seq:receipt_hash. Затем она соединяет соседние сырые 32-байтовые дайджесты, при нечётном количестве дублирует последний и повторяет процедуру. Независимый пересчёт приводит ровно к опубликованной величине.

Но текущая редакция 04 документа AER-1: A Portable Execution Receipt for AI Agent Tool Calls требует другого. В ней лист — SHA-256 от UTF-8-байтов receipt_id. Для тех же пяти шагов получается 7c4817ca249edfeae259b98abf63ed38a31d9dbeebf5ee23139410a7a7f63b37.

Документ опубликован 29 сентября 2026 года как индивидуальный Internet-Draft с предполагаемым статусом Informational. Это не RFC и не принятый документ рабочей группы IETF. Однако статус черновика не отменяет наблюдение: два публичных контракта дают разные идентичности одному набору шагов.

По первому корню аудитор не восстановит утраченное правило. Хеш хорошо связывает известные байты, но не объясняет, почему выбраны именно эти байты.

Различие возникает до дерева

В обоих расчётах используется SHA-256. В обоих соседние 32-байтовые значения соединяются в исходном виде. В обоих последний элемент нечётного уровня дублируется. Отличается лист.

Редакция 04 сначала называет описанную конструкцию рекомендуемой, а затем прямо предписывает её словом MUST. Более раннее разрешение альтернатив удалено. Причина сформулирована в самом тексте: разные корни одного workflow ломают межреализационную проверку.

У страницы есть понятная логика — напрямую связать позицию и обязательство по результату. У черновика другая логика — дерево строится из устойчивых идентификаторов, а каждая квитанция разрешается и проверяется отдельно. Обе модели можно обсуждать. Нельзя считать их одной моделью.

Поэтому определение листа относится к протоколу, а не к скрытой реализации. Если оно не путешествует вместе с корнем, получатель вынужден доверять памяти или объяснению исходного оператора. Формально децентрализованный хеш тогда сохраняет централизованную власть толкования.

Зафиксированный код уже следует новой редакции

В публичном репозитории на коммите f3aacbb5cf7d00977fd107afc34fc24b08c4f569 функция Python принимает идентификаторы квитанций. Rust хеширует байты ID. TypeScript хеширует UTF-8-представление ID. Все три проверенных помощника соответствуют редакции 04.

Код браузера на рабочей странице извлекает выходные хеши и строит seq:hash. Внутри страницы противоречия нет — поэтому её расчёт успешно проходит. Противоречие находится между совместимостями.

Принцип приоритета работающего кода у Lu Heng не означает, что первая развёрнутая версия автоматически получает нормативную власть. Он требует смотреть, что реально исполняется и принимается. Новый текст также не переписывает исторические квитанции одним фактом публикации. Спецификация, тесты, библиотеки и сервис должны сойтись через внедрение.

Минимальный общий слой должен быть узким, но детерминированным. Выбор листа — минимальное условие локальной проверки. Исключить его из переносимого профиля значит исключить саму переносимость.

43 из 43 — правильный ответ на прежний набор вопросов

Репозиторий сообщает 43/43 для Rust, Go, TypeScript, Python, Java, C# и Swift. README перечисляет область: поля квитанции, UUID, дата и время, строгие Base64 и UTF-8, выходное обязательство, классы происхождения, профиль производителя, необязательные якоря и обратное чтение эмиттеров.

Workflow в перечне отсутствует. Индекс векторов указывает редакцию -03. Среди 43 записей нет проверки workflow, Merkle, последовательности шагов, хеша шага или дублирования нечётного узла.

Все семь реализаций могут получить идеальный результат, ни разу не построив дерево новой функции. Число достоверно в пределах набора. Оно не подтверждает то, чего набор не спрашивал.

Новый вектор должен фиксировать пять ID, вход каждого листа, листовые дайджесты, промежуточные уровни, дублирование пятого элемента и ожидаемый корень. Его должны прогонять рабочая страница, API и все поддерживаемые языки.

Шесть разных проверок

Совпадают ли сохранённые байты шага с обязательством? Совпадает ли ответ endpoint с манифестом? Выбран ли лист по именованной конструкции? Получает ли другая реализация той же конструкции тот же корень? Записал ли внешний свидетель выбранное обязательство? Произошёл ли нужный внешний эффект?

Публичный пример уверенно отвечает на первые два вопроса и доказывает внутреннюю согласованность своей конструкции. Он показывает частичный Nostr-якорь. Но якорь свидетельствует о переданном корне, а не выбирает семантику листа.

Агрегация не повышает происхождение данных. Сообщение внешнего агента остаётся сообщением. Наблюдение шлюза не становится фактом вне шлюза. Получение цены не доказывает сделку.

Интерфейс должен показывать объект проверки: байты, шаг, манифест, конструкцию, якорь или внешний результат. Иначе зелёная отметка превращает недосказанность в решение пользователя.

Корень должен хранить свой паспорт

Для переносимости нужны версии схем, идентификатор конструкции, точная кодировка, хеш-функция, правило родителей, обработка нечётного узла, формат результата, упорядоченные ID и обязательства шагов, происхождение, определение финальных байтов, область якоря и версия тестового набора.

Принимающая система сохраняет версию политики и лицо, принявшее решение. Тогда спустя месяцы можно ответить, какой именно объект был одобрен.

При переходе с seq:receipt_hash на receipt_id нельзя молча пересчитать прошлое. Старый корень сохраняется, новый публикуется как версионированное последующее обязательство, а в переходный период отображаются оба. Внедрение должно быть наблюдаемым, а не ретроактивным.

Источники и ограничения

Наблюдение зафиксировано 30 сентября 2026 года по времени Шанхая. Оно подтверждает воспроизводимое различие между редакцией 04, фиксированным публичным коммитом и действовавшей страницей. Оно не подтверждает злой умысел, слабость SHA-256, компрометацию, сбой внешнего эффекта, массовое внедрение или поддержку IETF. Проверка кода ограничена помощниками workflow на Python, Rust и TypeScript. Черновик и сервис могут измениться.