Reading the SKU.md v0.8 layered architecture: self-hosted information, platform-gated transactions

The SKU.md v0.8 architecture is not simply a stack of technologies arranged from simple to advanced. It is a map of where control changes hands. An AI agent begins on a merchant domain, moves through public discovery and merchant-published product context, and only later reaches capabilities that may depend on an external protocol, platform, identity, or transaction backend.

The colors make that boundary visible. Teal marks surfaces a merchant can publish or implement on its own domain. Coral marks operations that require admission, credentials, authorization, or execution by another party. The distinction is essential: information can be open to discovery without making the systems that act on that information open to every caller.

The colors are an authority legend

The white boxes name files, data structures, or mechanisms. Their colored containers answer a different question: who can make the mechanism real?

In the teal layers, the merchant controls publication. It can configure robots.txt, expose a Sitemap, maintain llms.txt, publish a root sku.md, add partition indexes, write product documents, and provide page-runtime tools. These surfaces still need correct hosting, safe parsing, and accurate data, but they do not require a commerce platform to approve the existence of the files.

Coral does not mean that a protocol specification must be closed. It means that operational use depends on a counterparty. A protocol profile may need merchant enrollment, a verified identity, credentials, supported services, or platform review. Checkout, payment, and order completion necessarily involve authorization and systems that can commit commercial state.

The diagram therefore separates two ideas that are often collapsed: publishing a declaration and possessing the authority to execute it.

Governance and discovery remain merchant-controlled

The first layer covers robots.txt, llms.txt, and sitemap.xml. All three help a consumer find or interpret site resources, but they do not have the same job.

robots.txt expresses crawler rules and can point to Sitemaps. It is not a general authentication or authorization protocol. A Sitemap supports bulk URL discovery; it does not certify that every discovered claim is current or trustworthy. llms.txt can provide a compact navigation surface for AI-oriented readers, but publication does not guarantee that any model or agent will read, accept, cite, or rank it.

This is why the layer is labelled governance and discovery rather than trust. The merchant controls what is published and where it points. The consumer still decides whether it may fetch a resource, whether the response is authentic, and how much evidentiary weight it deserves.

The SKU-MD document family keeps the root bounded

The next teal layer is the SKU-MD document family:

• the root /sku.md catalog manifest;
• optional partition indexes for large or segmented catalogs;
• product-level *.sku.md documents.

The root manifest is described as O(1) because its size should remain bounded as the catalog grows. It is not a promise that an entire catalog can be queried in constant time. The manifest stays small by linking to catalog entry points, partitions, and product-document discovery surfaces instead of embedding every product.

That design gives an agent a predictable starting point without forcing a small merchant to build a large indexing system. A modest catalog can link directly to its useful resources. A large catalog can introduce nested partition indexes. Product documents remain focused on one product group and its variants, so details can be updated without rewriting the root.

All of these files remain under merchant control. Their authority comes from domain ownership, canonical URLs, consistent revisions, evidence, and correct HTTP delivery, not from the filename alone.

The product-truth layer separates knowledge from changing state

The third teal layer combines Product JSON-LD with SKU.md Knowledge and places offer_snapshot beside live_verification. That arrangement prevents stable facts and volatile commerce state from being treated as one undifferentiated record.

Product JSON-LD supplies established page-level product semantics. SKU.md Knowledge can organize facts, claims, disclosures, guidance, limitations, and their evidence. The knowledge layer is for statements worth publishing and auditing; it must not be used to freeze temporary prices, inventory, shipping quotes, or promotions into durable prose.

An offer_snapshot records what was observed for a market and variant at a specific time. Fields such as observed_at, refresh_after, and a genuine offer_valid_until let a consumer judge freshness. A snapshot is evidence of a past observation, not a reservation and not proof that the same price or availability still applies.

live_verification provides a conservative fallback: reopen the public storefront page and inspect the currently displayed state for the same variant. It is explicitly not a structured catalog API and cannot directly trigger a purchase. When a recognized live lookup is available, it can be preferred; otherwise the public page remains a verifiable, merchant-controlled surface.

Capabilities and protocol profiles form two different paths

After product truth, the architecture branches. The split is not “modern” versus “legacy.” It distinguishes who operates the capability and what must happen before a consumer can use it.

capabilities[]: merchant-published runtime ability

capabilities[] can describe a generic function when no authoritative external profile exists, including WebMCP page tools. A merchant can implement those tools in its storefront runtime and declare their scope, status, discovery mode, and access mode.

Page-runtime tools remain constrained by the page context. They can require user presence, expose only product or cart operations, and have no remote invocation URL. Self-hosted therefore does not mean unrestricted. The browser, site policy, current user session, tool schema, and application code still bound what can happen.

A capability entry describes an available surface. It does not show that an agent has user consent, payment authority, or permission to perform an irreversible action.

protocol_profiles[]: a pointer into an external trust system

protocol_profiles[] is used when an external protocol already defines an authoritative discovery profile. SKU.md links to that profile rather than copying its versions, services, transports, endpoints, and schemas into the catalog manifest.

The diagram uses UCP and ACP as examples of this path. The profile can be published on the merchant domain, but operational participation may still depend on protocol support, registration, platform review, credentials, or commercial agreements. A syntactically valid profile cannot manufacture acceptance by another party.

This is an important property of the architecture: an open discovery document can accurately describe a gated execution environment without pretending the gate does not exist.

Both paths converge at the transaction boundary

The final coral layer contains Checkout, Payment, and Order. Whether an agent arrives through a page capability or a protocol profile, committing a transaction requires systems that control money, inventory, tax, fulfillment, fraud checks, and user authorization.

SKU.md can identify where those systems are and which source is authoritative for a field. It cannot replace the checkout backend. Final totals, payment status, and order state must come from an execution system able to make and record those changes. When no usable source exists, the safe value is unknown, not an inferred transaction.

The convergence also prevents a dangerous shortcut: a self-hosted page tool must not be treated as a way around platform or protocol controls. It may help prepare a cart or guide a user, but the point where commercial state becomes binding still belongs to an authorized backend.

Five category errors the architecture avoids

1. Discovery is not adoption. Publishing a file makes it addressable; it does not make agents consume or trust it.
2. A declaration is not admission. Listing a capability or protocol profile does not prove another system has enabled it.
3. A snapshot is not live state. Price and availability must be evaluated with their observation time and verified again when the decision requires it.
4. A page tool is not payment authority. Runtime access remains bounded by user presence, application policy, and the checkout system.
5. An open specification is not an open transaction. Identity, credentials, consent, risk controls, and commercial agreements can still be required.

A small document can still express an honest boundary

The architecture keeps the entry point simple while refusing to flatten every downstream dependency into a single “AI commerce” claim. Merchants can own the discovery, documentation, evidence, and page-runtime layers on their domain. External protocols and transaction systems retain their real admission and authorization requirements.

That division is the central design choice. SKU.md does not try to eliminate the boundary between published product context and executable commerce. It makes the boundary explicit enough for publishers to state what they control, for platforms to preserve the gates they must operate, and for consumers to know when they have moved from reading evidence to requesting an action.

Further reading

Compare each layer’s present responsibility in llms.txt vs agents.md vs SKU.md.