Help AI understand your products: preparing for agent shopping with SKU.md v1.0.0

A shopper asking AI for help may begin with a need rather than a brand: “Find a blue travel mug that holds at least 300 ml and is insulated.” A merchant’s opportunity depends partly on whether a system can determine that the product suits that person.

SKU.md v1.0.0 helps merchants organize the necessary knowledge so it can be discovered, traced to sources, and compared. That can address misunderstandings and missing information. It cannot guarantee that an external agent will read, cite, or recommend a product.

Why the answer might be “insufficient information”

This is a fictional example, not a real store, user study, or visibility experiment. A travel-mug page states “350 ml capacity” and offers a blue variant, but does not say whether that variant is insulated.

Capacity recorded only at product scope does not automatically establish the blue variant’s capacity. Missing insulation information is not equivalent to “not insulated.” Both uncertainties matter when evaluating the blue variant.

Requirement	Initial information	Next step
Blue variant holds at least 300 ml	Only a product-level 350 ml statement	Verify applicability to blue and record variant-scoped evidence
Blue variant is insulated	Unknown	Find explicit support, or leave it unknown
Available now and delivered by Friday	Static knowledge cannot establish this	Check the live store system

Insufficient information calls for more evidence. An explicit failure means the product does not meet that condition. Treating the two as interchangeable misleads both merchant and shopper.

Discoverable: offer a clear entry point

A root /sku.md file connects the catalog to optional product knowledge documents. Consumers that support the format get a declared starting point rather than guessing which links contain product facts. The specification also defines a homepage-declared alternative that may be considered only after an exact root 404.

Publishing the entry point is within the merchant’s control. Implementing and visiting it is the consumer’s choice. Product pages, established search work, and channel feeds still need maintenance. Successful file validation does not establish search indexing or AI-platform adoption.

Understandable: attach identity, scope, and evidence

Capacity, color, and insulation must refer to the relevant product or variant. Measurement conditions, limitations, and sources belong with the claim. A performance result obtained under specific conditions should not become an unconditional promise.

Evidence excerpts and review states make the reasoning inspectable. A reviewer must check that the source actually supports the attribute, not merely that the URL opens. Unsupported claims should remain pending or unknown instead of being invented to fill a table.

This gives consumers a clearer account of where a product fits and gives merchants a way to trace a statement back to its origin.

Comparable: inspect changes in facts, not an AI score

Suppose the merchant verifies that the blue variant holds 350 ml and adds reviewed evidence at that scope. The capacity condition changes from insufficient to matched. If insulation remains unknown, the product still cannot be considered a match for both conditions.

If reviewed evidence later supports insulation, both static conditions may pass. If it establishes that the mug is not insulated, the product should be excluded. Compatible capacity units can be converted between liters and milliliters.

These are reproducible checks under the same requirements, not a model’s preference or a platform placement. Adding an accurate limitation that excludes a product can be a sign of better knowledge.

Walk through the tools

1. Open the product optimizer. Learn the workflow with its built-in example, then load your own information using the inputs supported by the interface.
2. Inspect gaps, conflicts, and evidence issues to choose which attributes need attention.
3. Check source excerpts, product scope, and measurement conditions against public material before explicitly accepting a change.
4. Use the comparison playground to compare before and after under identical conditions, separating matched, excluded, and insufficient outcomes.
5. Export reviewed Markdown or a channel structured-data proposal that still requires human review, and inspect the output.

Channel proposals do not publish to your store or advertising system and do not guarantee search eligibility. Existing systems remain responsible for commercial fields such as price and stock. Download working drafts for safekeeping; an edit in a browser session is not a live publication.

Establish a baseline with one product

Record which questions the product data can answer, which lack evidence, and whether the file is publicly accessible. After improving the facts, repeat the same checks and keep both results.

For a later real-agent experiment, record the product and version used, the prompt, whether the file was fetched, and which sources were cited. Track access, citations, visits, and purchases separately. Local condition checks are not visibility-growth data.

Start with a product whose specifications often prompt questions. Follow the quick start and current specification, and turn one ambiguous selling point into a scoped, verifiable fact.