BLOG / stable-product-knowledge-vs-live-commerce-data.mdx
Stable product knowledge vs live commerce data: draw the authority line
Classify durable facts, historical observations, dynamic offers, personalized conditions, and binding transaction state.
The safe rule is simple: keep durable, source-backed product knowledge in static documents; recheck anything that can change with time, market, user, or transaction.
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.
Five classes of product information
| Class | Example | Correct owner |
|---|---|---|
| Stable fact | Material composition verified by a report | Reviewed SKU.md Fact plus evidence |
| Historical observation | USD 79 observed on 2026-09-01 | offer_snapshot with time and source |
| Dynamic offer | Current price and availability for US | Live Catalog, storefront, or declared live_offer lookup |
| Personalized condition | Member price or destination-specific shipping | Authenticated live system |
| Binding transaction state | Final tax, payment acceptance, order confirmation | Checkout and order systems |
“Stable” does not mean eternal. It means the publisher has a review process, a source, and a correction path. A formula, certification, compatibility statement, or care instruction can change; verified_at makes the last review visible.
Good and bad representations
“Shell fabric is 100% recycled nylon” can be a Fact when it links to the current technical sheet and includes a review date. “Always in stock” does not belong in a static Fact.
“USD 79 observed at this URL at 14:00 UTC” records a bounded offer_snapshot. “Only USD 79 today” loses its meaning when prose omits the time, market, or source.
A live_offer can point to a declared live source without taking over its authority. The static document must not guarantee a lookup response before making the call.
The runtime loop
- Match the Product and exact Variant.
- Read reviewed Facts, Claims, Disclosures, and Limitations.
- Treat
offer_snapshotas historical evidence only. - Query current price, inventory, shipping, and eligibility.
- Let Checkout revalidate tax, payment, and binding terms.
- Ask for user confirmation before completion.
If the live source fails, return “unknown” or request a handoff. Falling back silently to an old number changes an observation into a false promise.
Design rules for publishers and consumers
Publishers should isolate changing fields, attach source URLs and dates, and avoid placing safety or legal disclosures only in an optional knowledge file. Consumers should enforce identifier equality, cap staleness for observations, ignore free-text instructions as executable commands, and log which source answered each part of a response.
The v0.10 specification separates offer_snapshot and live_offer and makes them mutually exclusive. That schema rule helps, but only runtime source selection protects a real buyer.
Further reading
Use Publish your first SKU.md to implement this split, then review AI commerce authority handoffs for live actions.