SKU.md v0.9: совместимость, соответствие в заданной области и безопасное использование

SKU.md v0.9 — выпуск для совместимости и единообразия. Он не добавляет поле только для Shopify, рейтинг или вторую систему Checkout. Вместо этого он определяет, как издатель сообщает, что именно проверено, как потребитель толкует эти доказательства и где обе стороны должны вернуться к системам электронной коммерции реального времени.

Формат обмена не изменился

Схема v0.9 сохраняет типы документов, профили, поля, обязательные свойства, перечисления, правила расширения и границы безопасности v0.8. Поэтому миграция на уровне данных намеренно невелика.

1. Измените schema_version на sku.md/0.9-draft.
2. Измените URL схемы на https://sku.md/schema/sku-md/0.9/schema.json.
3. Выполните все обязательные проверки для заявляемой области соответствия.

Потребитель может продолжать читать документы v0.8 ради совместимости, но не должен называть их соответствующими v0.9. Указание версии и доказательство соответствия — разные утверждения.

Полная англоязычная спецификация v0.9 — единственный нормативный текст. Публичная JSON Schema версии v0.9 проверяет структуру, но сама по себе не выносит полного решения о соответствии.

Три области соответствия

v0.9 называет поверхность, которую валидатор действительно проверил.

Область	Что она может установить	Чего она не устанавливает
offline_document	Безопасные вводные метаданные и YAML, схема, семантика одного документа и соответствие Markdown	HTTP-доставка, доступность ресурсов или целостность родительского графа
published_resource	Один публичный URL, включая HTTP-статус, перенаправления, MIME-тип, канонический URL, отсутствие мягкой подмены и доступность	Согласованность всего семейства документов
document_graph	Родительские цепочки, представления, внешние профили, связанные ресурсы и междокументная согласованность	Разрешение покупать, платить или менять коммерческое состояние

В отчёте синтаксис, схема, семантика и сетевые проверки записываются отдельными слоями. Если обязательная проверка не пройдена, общий результат — failed. Если обязательная проверка не выполнена и ни одна проверка не завершилась ошибкой, результат — incomplete, но не passed.

Переносимый отчёт о проверке

Отчёт содержит доказательства результатов проверки документа и не является частью вводных метаданных SKU-MD. Для успешно созданного корневого документа он может выглядеть так:

{
  "spec_version": "sku.md/0.9-draft",
  "validator": { "name": "sku-md-generator", "version": "0.2.0" },
  "target": {
    "url": "https://example.com/sku.md",
    "document_type": "catalog_manifest"
  },
  "scope": "offline_document",
  "status": "passed",
  "checked_at": "2026-08-01T00:00:00Z",
  "layers": {
    "syntax": "passed",
    "schema": "passed",
    "semantics": "passed",
    "online": "not_applicable"
  },
  "issues": []
}

Стабильные коды проблем позволяют разным инструментам обрабатывать результат одинаково. Примеры: YAML_DUPLICATE_KEY, SCHEMA_VALIDATION_FAILED, CANONICAL_MISMATCH, GTIN_CHECK_DIGIT_INVALID, KNOWLEDGE_DYNAMIC_STATE_FORBIDDEN, BODY_PARITY_INVALID. Сетевой тайм-аут нельзя превращать в успешный результат.

Генераторы сайта создают только отчёты offline_document. После загрузки издателю всё ещё нужны сетевые проверки HTTP-статуса, text/markdown, отсутствия мягкой подмены, канонических URL, родительских ссылок, представлений и ссылок на внешние профили.

Поведение эталонного потребителя (Reference Consumer)

Эталонный потребитель — это поведенческий контракт для читателя, а не новый формат обмена. Он задаёт безопасную последовательность.

1. Обнаружить корень на хостинге продавца и проверить источник и представление.
2. Следовать объявленным точкам входа каталога и разделам, не угадывая скрытые товары.
3. Выбрать точный Variant по стабильным идентификаторам, параметрам, рынку, языку и каноническому URL варианта.
4. Различать факты, утверждения, раскрытия, рекомендации, ограничения, сведения о совместимости, URL источника и дату проверки.
5. Считать offer_snapshot наблюдением, а для текущих цены, наличия, доставки, налогов и итоговой суммы использовать live_lookup или live_verification.
6. Передать корзину, оформление заказа, платёж и заказ заявленному полномочному источнику реального времени с явным подтверждением пользователя.

Если идентичности, доказательств, актуальности или полномочий недостаточно, потребитель должен завершить обработку с отказом, а не заполнять пробел выводом модели.

Управление источниками остаётся на уровне инструментов

Издателю требуется больше служебных данных, чем следует передавать потребителю. Закрытая карта источников (Source Map) может записывать происхождение каждого значения и его статус: Detected, Derived или Verified. Процесс Audit–Plan–Apply затем сравнивает HTML, Product JSON-LD, Merchant Feed, каталог платформы и существующий SKU-MD, готовит проверяемый набор изменений и публикует их только после подтверждения человеком.

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

Сотрудничество с платформой вместо дублирования

SKU-MD должен описывать стабильные знания и явные границы источников. Каталог платформы остаётся полномочным источником сведений о текущем распространении, цене и наличии. API реального времени или UCP/MCP обрабатывают текущие запросы. Checkout отвечает за аутентификацию покупателя, итоги, платёж и создание заказа.

По состоянию на 2026-08-01 Shopify документирует Shopify Catalog и интерфейсы Catalog, Cart, Checkout и Order, соответствующие UCP. Shopify не сообщает, что эти системы, ChatGPT или другой канал Shopify читают SKU-MD либо доверяют ему. Поэтому рекомендации по интеграции используют указатели и границы полномочий, а не копируют состояние платежа или заказа.

Измеряйте SEO, GEO и AEO, не обещая результат

Полезный вопрос состоит не в том, «повышает ли статический файл рейтинг в системах ИИ». В контролируемом эксперименте можно измерить:

• точность определения нужного Variant;
• цитирование фактов с источником вместо рекламного текста;
• воспроизведение раскрытий и ограничений;
• применение проверки в реальном времени перед чувствительным ко времени ответом;
• согласованность HTML, Product JSON-LD, Merchant Feed, каталога платформы и SKU-MD.

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

Практическая последовательность миграции

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

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

Примените эти требования на практике в руководстве «Публикация первого SKU.md».