SKU.md v0.9: interoperability, scoped conformance, and safe consumption

SKU.md v0.9 is an interoperability and consistency release. It does not add a Shopify-specific field, a ranking score, or a second checkout system. Instead, it defines how a publisher states what was checked, how a consumer interprets that evidence, and where both parties must return to live commerce systems.

The wire format is unchanged

The v0.9 Schema preserves the v0.8 document types, Profiles, fields, required properties, enums, extension rules, and safety boundaries. The migration is therefore deliberately small at the data layer:

1. Change schema_version to sku.md/0.9-draft.
2. Change the Schema URL to https://sku.md/schema/sku-md/0.9/schema.json.
3. Run every required check for the conformance scope you intend to claim.

A consumer can continue to read v0.8 documents for compatibility, but it must not label them v0.9-conformant. Version identity and conformance evidence are different claims.

The complete English v0.9 specification is the only normative text. The public v0.9 JSON Schema checks structure; it is not a complete conformance decision by itself.

Three conformance scopes

v0.9 names the surface that a validator actually inspected.

Scope	What it can establish	What it cannot establish
offline_document	Safe frontmatter and YAML, Schema, single-document semantics, and Markdown parity	HTTP delivery, resource reachability, or parent graph integrity
published_resource	One live URL, including HTTP status, redirects, MIME, canonical, soft fallback, and reachability	Consistency across the whole document family
document_graph	Parent chains, representations, external Profiles, referenced resources, and cross-document consistency	Permission to buy, pay, or mutate commerce state

Within a report, syntax, Schema, semantics, and online checks are recorded as separate layers. If a required check fails, the overall result is failed. If a required check was not performed and no check failed, the result is incomplete, never passed.

A portable validation report

The report is evidence about a document; it is not part of SKU-MD frontmatter. For a successful generated root document it can look like this:

{
  "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": []
}

Stable issue codes make the result usable across tools. Examples include YAML_DUPLICATE_KEY, SCHEMA_VALIDATION_FAILED, CANONICAL_MISMATCH, GTIN_CHECK_DIGIT_INVALID, KNOWLEDGE_DYNAMIC_STATE_FORBIDDEN, and BODY_PARITY_INVALID. A network timeout must not be converted into a success.

The website generators create offline_document reports only. After upload, the publisher still needs online checks for HTTP status, text/markdown, soft fallbacks, canonical URLs, parent links, representations, and external Profile references.

Reference Consumer behavior

A Reference Consumer is a behavioral contract for readers, not a new wire format. It provides a safe sequence:

1. Discover the merchant-hosted root and verify its origin and representation.
2. Follow declared catalog entrypoints and partitions without guessing hidden products.
3. Select the exact Variant using stable identifiers, options, market, language, and canonical Variant URL.
4. Keep Facts, Claims, Disclosures, Guidance, Limitations, Compatibility, source URLs, and verification dates distinct.
5. Treat offer_snapshot as an observation and use live_lookup or live_verification for current price, availability, shipping, tax, and totals.
6. Return carts, checkout, payment, and orders to the declared live authority with explicit user confirmation.

When identity, evidence, freshness, or authority is insufficient, a consumer must fail closed instead of filling the gap with a model inference.

Source governance stays in the tool layer

Publishers need more state than consumers should receive. A private Source Map can record the origin of every value and whether it was Detected, Derived, or Verified. An Audit–Plan–Apply workflow can then compare HTML, Product JSON-LD, Merchant Feed, platform Catalog, and existing SKU-MD; prepare a reviewable diff; and publish only after human confirmation.

Source Maps, review records, draft status, release diffs, issue logs, and channel metrics do not enter the public Schema. If an incremental rebuild or online validation fails, the delivery system should keep the last valid version instead of replacing it with partial output.

Platform collaboration, not duplication

SKU-MD should describe stable knowledge and explicit source boundaries. A platform catalog remains authoritative for current distribution, price, and availability; live APIs or UCP/MCP handle current queries; Checkout owns buyer authentication, totals, payment, and order creation.

As of 2026-08-01, Shopify documents Shopify Catalog and UCP-compliant Catalog, Cart, Checkout, and Order interfaces. Shopify does not document those systems, ChatGPT, or another Shopify channel reading or trusting SKU-MD. The integration guidance therefore uses pointers and authority boundaries, not copied payment or order state.

Measure SEO, GEO, and AEO without promising outcomes

The useful question is not whether a static file “boosts AI ranking.” A controlled experiment can instead measure:

• exact Variant resolution accuracy;
• citation of sourced Facts rather than marketing prose;
• recall of disclosures and limitations;
• use of live verification before a time-sensitive answer;
• consistency across HTML, Product JSON-LD, Merchant Feed, platform Catalog, and SKU-MD.

These measures can reveal whether the publishing contract reduces ambiguity and stale answers. They do not prove that a crawler will fetch the document or that a platform will rank, cite, recommend, or convert a product.

A practical migration sequence

Start by updating version identifiers and generating an offline report. Publish only after human review. Then verify the live resource and document graph. Keep dynamic commerce outside Knowledge, preserve the last valid revision when automation fails, and compare outcomes through controlled tests rather than unqualified adoption claims.

Further reading

Apply the current delivery contract in Publish your first SKU.md.