BLOG / sku-md-adoption-flywheel.mdx
The SKU.md adoption flywheel: evidence before ecosystem claims
A realistic publisher–validator–consumer path using generators, platform defaults, conformance, reference consumers, cases, and governance.
SKU.md has the pieces of an adoption flywheel, but not the independent use needed to claim one. Progress should be measured through reproducible use, not file counts or optimistic ecosystem language.
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.
Who must participate
| Side | Needs | Evidence of progress |
|---|---|---|
| Publishers | Low-friction generation, review, and exact delivery | Valid public documents maintained over time |
| Validators | Stable Schema, semantic checks, and public-resource tests | Independent implementations agree on results |
| Consumers | Clear discovery, safe parsing, and bounded use cases | Useful answers with citations and correct failures |
The loop stalls when any one group is absent. Generated files have little value without consumers. Consumers without conformance create incompatible dialects, while validators need practical publishing paths to test.
Six reinforcing investments
- Generators create small, reviewable drafts without inventing facts.
- Platform defaults make exact, merchant-controlled publication routine where platforms choose to support it.
- Conformance suites test offline documents, public resources, and document graphs.
- Reference consumers demonstrate safe source selection and fail-closed behavior.
- Cases report reproducible tasks, costs, failures, and maintenance instead of relying on testimonials.
- Community governance versions changes, records decisions, and prevents one vendor from redefining compatibility.
These are roadmap components. Existing local generators, fixtures, and a Reference Consumer are evidence of project work, not achieved platform defaults or an adopted ecosystem.
Metrics that resist vanity
| Weak metric | Stronger replacement |
|---|---|
| Files generated | Public resources still valid after 90 days |
| Validator runs | Independent validators returning the same result |
| Logo list | Named integration with an official source and tested route |
| Demo answer | Repeatable task with citations and negative cases |
| Traffic spike | Sustained cohort trend with confounders recorded |
The project should publish negative results: routes that redirect, platforms that cannot own /sku.md, identifier mismatches, stale evidence, and consumers that decline unsafe actions. Those results show where the contract works and where it stops.
Governance requirements
Changes need a public specification, fixed Schema URLs, migration guidance, test fixtures, and an explicit lifecycle. Extension namespaces should identify their authority. A proposal that mentions MCP, UCP, or WebMCP must remain independent unless those projects explicitly adopt it.
The v0.10 specification, conformance fixtures, and reference evaluation provide a starting point. The next credibility gain comes from external review and independent implementation, not from renaming the draft a standard.
A responsible next loop
Start with a small publisher problem. Publish the minimal document and run public checks, then let an independent consumer answer one bounded question. Record failures and feed the result into the specification. Repeat with another implementation before broadening a claim.
That loop can eventually justify platform tooling or defaults. Until then, describe it as adoption work in progress.
Further reading
Start with What is SKU.md? and use Publish your first SKU.md to produce testable publisher evidence.