Как читать многоуровневую архитектуру SKU.md v0.8: самостоятельно размещаемая информация и транзакции под контролем платформы

Схема SKU.md v0.8 — не лестница от простых технологий к сложным. Это карта смены контроля. ИИ-агент начинает с домена продавца, проходит через опубликованные пути обнаружения и предоставленный продавцом товарный контекст, а затем переходит к возможностям, зависящим от внешних протоколов, платформ, проверки личности, допуска или серверной системы обработки транзакций.

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

Цвет обозначает границу полномочий

Белые блоки обозначают файлы, структуры данных или механизмы. Цвет вокруг них показывает, кто может создать и поддерживать каждый из них.

На бирюзовых уровнях право публикации принадлежит продавцу. На своём домене он может настроить robots.txt, предоставить карту сайта, опубликовать llms.txt и корневой sku.md, добавить индексы разделов и товарные документы, а также реализовать инструменты страницы. По-прежнему нужны корректный хостинг, безопасный разбор данных и точные сведения, но для самого размещения файлов предварительное одобрение коммерческой платформы не требуется.

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

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

Управление и обнаружение остаются под контролем продавца

Первый уровень включает robots.txt, llms.txt и sitemap.xml. Все три помогают потребителю находить и понимать ресурсы сайта, но выполняют разные задачи.

robots.txt задаёт правила обхода и может указать расположение карты сайта, однако не является общим протоколом проверки личности или авторизации доступа. Карта сайта помогает массово обнаруживать URL, но не доказывает, что утверждения на каждом URL актуальны, точны и надёжны. Файл llms.txt может дать ИИ-потребителю краткую навигацию, однако публикация не гарантирует, что модель или агент прочитает, примет или процитирует его либо повысит рейтинг сайта.

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

Семейство документов SKU-MD сохраняет размер корневого манифеста ограниченным

Второй бирюзовый уровень — семейство документов SKU-MD.

• Корневой манифест каталога /sku.md.
• Необязательные индексы разделов для крупных или сегментированных каталогов.
• Документы *.sku.md для отдельных товаров.

O(1) на схеме означает, что размер корневого манифеста должен оставаться ограниченным по мере роста каталога. Это не обещание, что запрос ко всему каталогу можно выполнить за постоянное время. Вместо встраивания всех товаров корень ссылается на точки входа каталога, разделы и документы товаров, поэтому может оставаться коротким и стабильным.

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

Файлы размещает продавец, но одно только имя файла не создаёт полномочий. Полномочия этих файлов определяются контролем домена, каноническими URL, согласованными редакциями, доказательствами и корректной HTTP-доставкой.

Слой достоверной товарной информации отделяет стабильные знания от изменчивого состояния

Третий бирюзовый уровень ставит рядом Product JSON-LD и SKU.md Knowledge, а отдельно показывает offer_snapshot и live_verification. Так стабильные факты не смешиваются с изменчивым коммерческим состоянием в одной плоской записи.

Product JSON-LD предоставляет зрелую семантику товара на уровне страницы. SKU.md Knowledge может организовать факты, утверждения, раскрытия, рекомендации, ограничения и связанные доказательства. Knowledge хранит утверждения, достойные публикации и аудита, а не фиксирует краткосрочные цену, наличие, доставку или промоакции в долговечном тексте.

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

live_verification — консервативный резервный способ проверки текущего состояния. Он снова открывает публичную товарную страницу и проверяет отображение того же варианта. Это не структурированный API поиска по каталогу и не средство совершения покупки. Если потребитель может определить доступный структурированный live_lookup, следует предпочесть его; иначе состояние повторно проверяется на публичной странице под контролем продавца.

capabilities[] и protocol_profiles[] ведут по разным путям

После уровня товарных данных архитектура разделяется. Это не деление на новые и старые технологии, а различие между тем, кто управляет возможностью, и условиями, которые потребитель должен выполнить перед использованием.

capabilities[]: возможности времени выполнения, публикуемые продавцом

Если у внешнего протокола нет авторитетного профиля или возможность существует во время работы страницы, capabilities[] может описывать общую функцию, например инструмент страницы WebMCP. Продавец реализует инструмент на странице магазина и объявляет область действия, статус, способ обнаружения и режим доступа.

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

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

protocol_profiles[]: ссылка на внешнюю систему доверия

Если внешний протокол определяет авторитетный профиль обнаружения, protocol_profiles[] ссылается на него. Он не копирует в манифест каталога версии протокола, сервисы, транспорты, конечные точки и схемы.

На схеме UCP и ACP приведены как примеры этого пути. Профиль можно опубликовать на домене продавца, но реальное участие может требовать поддержки протокола, регистрации продавца, проверки платформой, учётных данных или коммерческого договора. Синтаксически правильный профиль не обеспечивает принятия со стороны других участников.

Это важное свойство архитектуры: открытый документ обнаружения может честно описывать среду выполнения, где нужен допуск, не делая вид, будто входных требований нет.

Два пути сходятся на границе транзакции

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

SKU.md может указать расположение этих систем и полномочный источник для каждого поля, но не заменяет серверную систему оформления заказа. Итоговая сумма, статус платежа и статус заказа должны поступать из системы, которая способна выполнить и записать изменение. Если такой источник недоступен, безопасный результат — «неизвестно», а не вывод о транзакции из статического документа.

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

Пять категориальных ошибок, которых избегает архитектура

1. Обнаружение — не принятие. Доступность файла не означает, что агент будет его использовать, считать надёжным или рекомендовать.
2. Декларация — не одобрение. Запись о возможности или профиль протокола не доказывает, что внешняя система активировала возможность.
3. Снимок — не текущее состояние. Цену и наличие оценивают вместе со временем наблюдения и повторно проверяют в момент решения.
4. Инструмент страницы — не платёжные полномочия. Возможность времени выполнения ограничена присутствием пользователя, политикой приложения и Checkout.
5. Открытая спецификация — не открытая транзакция. По-прежнему могут требоваться идентификация, учётные данные, согласие, управление рисками и коммерческий договор.

Небольшой документ тоже может честно показать границу

Архитектура сохраняет простую точку входа, но не сводит все последующие зависимости к расплывчатому выражению «ИИ-коммерция». Продавец контролирует на своём домене обнаружение, документы, доказательства и слой времени выполнения страницы, а внешние протоколы и транзакционные системы сохраняют реальные требования допуска и авторизации.

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

Дополнительные материалы

Сопоставьте назначение каждого слоя с матрицей llms.txt, agents.md и SKU.md.