Кратко

  • draft-mih-agent-settlement-records-00 предлагает отдельные подписанные наблюдения плательщика и получателя, а состояние совпадения выводит проверяющая сторона. Ни одна из записей не вправе сама объявить совокупный результат.
  • Согласие о платеже и доставка независимы. Проект прямо допускает состояние agreed для платежа и none для доставки: ни подписи, ни совпадение сторон не доказывают получение товара, контента или услуги.

Самая опасная отметка в торговле автономных агентов может оказаться не красным предупреждением, а слишком ёмким зелёным значком. Платёжные системы видят списание и зачисление, бухгалтерия закрывает сверку, а следующие процессы читают «рассчитано» как «сделка исполнена». Нулевая редакция Two-Party Settlement Records for Agent Payments, опубликованная в IETF Datatracker 2 октября 2026 года, пытается не дать такому смысловому расширению стать частью инфраструктуры.

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

Проект раскладывает settlement максимум на четыре типа leg: условия, наблюдение плательщика, наблюдение получателя и доставку. Каждая сторона запечатывает только то, что увидела её собственная система. Полученное от контрагента свидетельство можно процитировать, но нельзя превратить в своё наблюдение. Ссылка фиксирует хранение и связь записи, а не переносит происхождение утверждения.

Совокупное состояние поэтому выводит verifier. Ни один settlement member не содержит собственного вердикта agreed или mismatch. Проверяющая сторона сначала валидирует Agent Action Capsule, producer envelope, структуру, wrapped object, роль и локальную политику ключей. Затем она группирует приемлемые legs по ссылке на условия и типизированной платёжной ссылке и получает результат из их байтов. Поставщик свидетельства не становится по совместительству судьёй двустороннего согласия.

Одинокая сторона остаётся заявленным утверждением. payer_stated означает лишь, что система плательщика сообщила об исходящем платеже; payee_stated — что система получателя сообщила о входящем. Отсутствующая половина не доказывает разногласие: она могла ещё не возникнуть, быть удержана или никогда не появиться. Связанный проект evidence request отдельно описывает ответ, подписанный отказ и зафиксированное отсутствие, не превращая три разных исхода в общий сбой.

Для agreed набор условий уже. Наблюдения должны соединяться, использовать разные принятые ключи, содержать одну нормализованную платёжную ссылку, пройти правило суммы и сообщать один статус. Сравнение суммы точное: в одном активе и на общей десятичной шкале сумма плательщика равна полученному получателем плюс его receive fee. Допуска нет. Если напрямую сравнить исходную сумму с чистым поступлением, честно раскрытая комиссия даст ложное расхождение.

Даже тогда согласие касается только рассказа двух платёжных систем о движении средств. Соответствие наблюдаемой суммы исходным terms проект сообщает отдельно. Обе стороны могут идеально совпасть между собой и вместе отличаться от сделки. Коммерческая допустимость комиссии относится к условиям и средствам защиты, а не появляется автоматически из криптографического совпадения.

У доставки собственный автомат состояний. Если delivered leg отсутствует, результат — none. Единственная непротиворечивая сторона даёт stated; совпадающие content digest отправителя и получателя — matched; разные — mismatch. Разделение действует в обе стороны: платёж бывает agreed, пока доставка none, а доставка — matched, пока платёж остаётся лишь payee_stated.

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

Слова статуса тоже являются локальными наблюдениями. settled означает окончательность на стороне запечатавшего запись: списано у плательщика либо зачислено или получено у получателя. Модель допускает и reversed, а более поздние наблюдения должны замещать ранние. Поэтому settled нельзя превращать в независимое от платёжного рельса обещание вечной необратимости.

Подпись не назначает подписанта. Проект прямо оставляет trust policy за своими рамками. Verifier должен отдельно определить, какому ключу позволено говорить от имени заявленного плательщика или получателя. Разные ключи мешают одному ключу изготовить обе половины agreed, но само наличие двух ключей ещё не доказывает двух уполномоченных контрагентов.

Граница сохраняется и для wrapped payment objects. Уже подписанные квитанции переносятся по digest и не должны подписываться заново. Wrapper доказывает включение определённых байтов, но не делает упаковавшего их первоначальным издателем. Аналогично, SCITT receipt может подтвердить регистрацию leg в названном журнале прозрачности. Он не доказывает истинность содержания и не превращает одностороннюю запись в двустороннюю.

Это семантика предложения, а не сведения о внедрении. Datatracker показывает индивидуальный Internet-Draft без stream и standards level. Соответствия x402, AP2, Payment HTTP, Open Payments, Lightning и ISO 20022 предложены автором проекта; они не свидетельствуют о принятии формата этими сообществами. В ходе исследования страница ISO вернула запрет доступа, поэтому статья не приписывает ISO поддержку, которой нет в сохранённом тексте проекта.

Minimum Initial Specification Лу Хэна задаёт полезную институциональную позицию: публиковать минимальную форму, в которой могут встретиться независимые наблюдения, но оставлять решения с последствиями локальными. Running-Code Primacy требует назвать фактически работавшие rail object, политику ключей, правило нормализации и supersession head. Reality Layers не позволяет слить подписанное наблюдение, согласие о платеже, свидетельство доставки и договорное исполнение в один значок «готово».

Руководству нужен не более широкий значок, а воспроизводимая квитанция решения. В ней должны остаться принятые и отклонённые legs, политика связи ключа со стороной, выведенное состояние платежа, сравнение с terms, состояние доставки, проверка wrapped object, статус рельса, замещение записей и локальное коммерческое действие. Тогда при споре организация сможет точно показать, где закончилось согласие фактов и началось её суждение.

Источники