SKU.md v1.0.0 is here: from product descriptions to AI-readable knowledge

SKU.md v1.0.0 is now available. For independent merchants, developers, and builders of shopping agents, it defines an open way to publish product knowledge: readable, maintainable Markdown that explains what a store sells, which facts have been reviewed, and where those facts come from.

The release goes beyond a file format. Merchants can inspect missing or conflicting information, review evidence, compare products against explicit requirements, and export reviewed content. It establishes a checkable foundation for agents to understand products. SKU.md remains an open proposal; a stable version number does not make it an adopted industry standard.

The starting point: what product pages leave unresolved

Stores already have descriptions, specifications, FAQs, and commerce systems. But a shopper asking for a product suited to a particular use needs context that may be scattered across them. Which variant does a measurement describe? What limits compatibility? Under what conditions was a performance claim measured?

SKU.md began with the idea that merchants should be able to maintain that context themselves instead of leaving machines to infer it. The repository records initial website and specification work in July 2026. That dates the development history, not the public release of a particular version.

What the early versions taught us

The v0.8 draft explored catalogs, product documents, and the organization of information sources. v0.9 sharpened interoperability, scoped validation, and safe consumption: a parseable document, an accessible resource, and a correct catalog relationship require separate checks.

The v0.10 work explored the boundary between product knowledge and commerce, including knowledge discovery, handoffs to live systems, and the limits of page tools. These experiments raised a practical question: how much should an open product knowledge specification be responsible for?

Version 1 narrows that responsibility. Earlier YAML manifests, partitions, and commerce profiles give way to a root catalog and optional product knowledge documents, both in pure Markdown. Historical specifications remain archived. Current tools accept only 1.0.0 and do not automatically convert older documents. Progress includes removing responsibilities as well as adding capabilities.

Readable knowledge, with sources attached

Merchants should be able to read what they publish and host it as an ordinary web resource. Markdown keeps text, links, and changes visible. Structured records describe identity, variants, attributes, and evidence without introducing another publication format.

Source links let readers return to the original material. Evidence excerpts, review states, and check dates help document a merchant’s judgment. An accessible URL does not establish that its contents support a claim, and a review declaration is not an automatically issued certification.

Unknown values remain unknown. Product-level attributes do not silently become variant-level facts. Clear scope allows a consumer to recognize missing information instead of producing a confident but unsupported answer.

What v1.0.0 delivers

Layer	What it enables
Open specification	Catalogs and sourced product knowledge, including identity, variants, attributes, conditions, and live-system links
Product optimizer	Checks for gaps and conflicts, evidence review, saved working drafts, and reviewed exports
Comparison playground	Explicit requirements evaluated as matched, excluded, or insufficient, with before-and-after comparison
CLI, Agent Skill, and read-only MCP	Shared rules across environments; consult each tool’s documentation for its capabilities and release status

Specification and package versions are independent. Specification 1.0.0 does not imply that every tool package is version 1.0.0 or that a candidate Skill package has separately shipped. Website tools, downloads, and service endpoints must each be checked.

Knowledge explains; live systems transact

Price, availability, delivery, taxes, payments, and order status change. Static knowledge cannot replace the systems responsible for them. SKU.md can point to those systems, but a link does not authorize a transaction.

The comparison playground checks submitted facts against conditions. It does not rank products with a model or forecast sales. Local acceptance records cover the specification, tools, and seven-language workflows; external agent adoption and merchant channel outcomes require separate evidence.

Start with one verifiable product

Merchants can begin with a product that has complete public documentation. Developers can implement consumers and report reproducible failures. Missing facts and concrete platform constraints are more useful contributions than unsupported endorsements.

Read the 1.0.0 specification, review a product in the optimizer, and examine how information changes affect decisions in the comparison playground. For agent workflows, check the capabilities and status of the Skill and MCP service separately.

History and release evidence

• Repository history: development evidence, not public release dates.
• v0.8, v0.9, and v0.10: archived design decisions.
• 1.0.0 changelog and local acceptance record: preparation and testing evidence, not a substitute for live release verification.