BLOG / what-is-sku-md.mdx
What is SKU.md? Merchant-hosted product knowledge for agents
Define SKU.md, its document family, the Readable–Queryable–Executable Web, and the authority boundaries it does not cross.
SKU.md is a merchant-hosted way to make product discovery and stable, sourced product knowledge easier for automated consumers. It connects durable explanations to live commerce sources; it does not replace those sources.
In precise terms, SKU.md is merchant-hosted product discovery and stable product knowledge: agents can find products, understand sourced facts, and know where to recheck live commerce. It is not a new checkout protocol.
Why product knowledge gets fragmented
A storefront may split one product across HTML, Product JSON-LD, feeds, manuals, policy pages, size charts, a live catalog, and checkout. A title and current price do not explain whether a material claim was tested, which variant it covers, or when the evidence was reviewed. A long marketing page does not say which source owns today’s availability.
SKU.md gives the merchant a small document graph that states identity, knowledge, evidence, limitations, and live verification entry points without merging them into one false source of truth.
Readable, Queryable, and Executable are separate layers
| Layer | Best at | Authority boundary |
|---|---|---|
| Readable Web | Stable explanations, evidence, disclosures, discovery | SKU.md can participate here |
| Queryable Web | Current catalog, price, inventory, shipping estimates | Live Catalog, API, or MCP owns the response |
| Executable Web | Cart, payment, order, and page actions | Checkout, order systems, UCP, or reviewed WebMCP actions own execution |
The layers form a loop: discover a product, read its sourced knowledge, query current conditions, then ask for user confirmation before a consequential action. Static knowledge should make the loop safer, not remove its live checks.
The v0.10 document family
The v0.10 specification defines a root Catalog Manifest, optional Partition Indexes, and Product Documents. A manifest-basic entry point can expose identity and catalog links without claiming live capabilities. A Product Document binds knowledge to stable Product and Variant identities and can remain valid without any offer.
Optional offer_snapshot records a historical observation. Optional live_offer points to separately declared live lookup. Neither field turns Markdown into a binding quote. Canonical and parent links make the graph inspectable; published-resource checks prove delivery rather than meaning.
Who should publish, implement, and consume it
Publishers are merchants or authorized operators who can review product sources. Implementers build generators, validators, platform routes, and safe consumers. Consumers may be agents, search or catalog tools, accessibility tools, or internal systems that need sourced product context.
| Role | Responsible choice | Unsafe shortcut |
|---|---|---|
| Publisher | Confirm identity, sources, dates, and limitations | Promote unreviewed copy to Fact |
| Implementer | Fail closed on ambiguity and validate public delivery | Treat local Schema success as publication |
| Consumer | Cite sources and recheck volatile state | Use an old snapshot as today’s price |
What SKU.md cannot confer
It cannot grant permission, authenticate a request, authorize payment, guarantee fulfillment, or make a claim true merely because it parses. It also cannot prove that a model will crawl, cite, recommend, rank, or convert a product. Those outcomes depend on independent systems and evidence.
That narrower role is practical. A merchant can expose a stable, reviewable product explanation and show a consumer where unresolved questions must be checked.
Further reading
Compare adjacent formats in llms.txt vs agents.md vs SKU.md and learn the delivery workflow in Publish your first SKU.md.