'%20clip-path='url(%23canvas-clip)'/%3e%3cg%20clip-path='url(%23canvas-clip)'%3e%3cg%20transform='rotate(0,%20256,%20256)'%3e%3cg%20transform='translate(87%2087)%20scale(14.083333333333334%2014.083333333333334)%20translate(0%200)'%3e%3cpath%20fill='none'%20stroke='%23FFFFFF'%20stroke-linecap='round'%20stroke-linejoin='round'%20stroke-width='2'%20d='m18.064%2010.877l-4.89-7.26c-.42-.625-1.287-.803-1.936-.397a1.4%201.4%200%200%200-.41.397l-4.893%207.26C4.24%2013.715%204.9%2017.318%207.502%2019.423a7.13%207.13%200%200%200%204.168%201.572M15%2018a3%203%200%201%200%206%200a3%203%200%201%200-6%200m5.2%202.2L22%2022'/%3e%3c/g%3e%3c/g%3e%3c/g%3e%3c/svg%3e)
The Agent-Readable Catalogue: The Data Foundation Agentic Commerce Requires
A machine buyer cannot shop a store it cannot read. Before any wallet or payment rail matters, the catalogue has to be answerable: stable identity, variant precision, governed attributes, normalised values, and honest freshness. This guide works through the seven quality dimensions, the five value states a record can be in, real normalisation examples, and the ownership trail that keeps the data honest.
This is the data half of agent readiness. The contract guide explains what the answer must contain; this one explains what the source data must be before that answer can be trusted. Both rest on the existing catalogue-quality and variant-search guides, which go deeper on each mechanism.
An agent reads fields, not pages. If identity, variant, or attribute facts live only in prose, the machine cannot act on them. Catalogue quality is the first layer of agent readiness, not a separate project.
Chapter 0 · What an agent-readable catalogue is
The same catalogue, written so software can act on it
An agent-readable catalogue is not a second catalogue. It is your existing product data, structured so a machine can answer a shopper's request without a human in the loop. The difference is not the products. It is whether each fact an agent needs lives in a field it can read, or only in prose it cannot.
Take one product: a navy trail shoe, UK 8, wide. A person sees a card and understands it. An agent needs the same facts as typed data: a stable product id, a variant id for that exact size and width, the colour as one canonical value, the price as a number with a currency, and an availability state. If those live in fields, the agent can act. If they live in the description sentence, it cannot.
What it looks like to a machine
Not a page. A record. Each product is a set of named fields with typed values: identity, variant, attributes, price, stock, compatibility. The machine reads the record, not the rendered layout. Missing or prose-only facts are simply invisible to it.
Why it matters
When an agent cannot read the catalogue, it returns the wrong variant, a false no-match, or a guessed value it then acts on. The merchant loses the sale and the agent loses the trust. Agent readiness starts at the data, not at the wallet.
How a machine works through the catalogue, step by step
- 1. Receive the request. The agent sends a normalised query: an identifier, typed attributes, or a compatibility constraint, not free text to scan.
- 2. Match against fields. The search layer compares the constraints to catalogue fields, not to page text, and resolves to a specific variant.
- 3. Report state honestly. The response carries a match_state (exact, partial, corrected, relaxed, or no_match) so the agent can branch.
- 4. Return typed records. Each result carries variant id, price, availability, and the evidence that caused the match, not just a title.
- 5. Hand off. The agent follows a stable link or cursor to the exact variant and completes the job, or recovers using the named missing dimension.
Chapter 1 · Seven quality dimensions
The dimensions a catalogue must satisfy before it is agent-readable
Each dimension is a question a machine cannot answer if the data is missing. The failure column is what an agent experiences when that dimension is weak: not a worse page, but a wrong or unactionable result.
01 · Identity
Question: Can the product and sellable variant be named without ambiguity?
Evidence: Stable product ID, variant ID, SKU, barcode, manufacturer part number, canonical title
If weak, an agent sees: Known-item queries collide, return the parent only, or link to the wrong variant.
02 · Classification
Question: Does the item occupy the right place in a maintained taxonomy?
Evidence: Category ID, product type, collection rules, compatibility family
If weak, an agent sees: Category queries leak across unrelated products and filters become incoherent.
03 · Attribute coverage
Question: Are the properties shoppers and agents use actually present?
Evidence: Material, colour, size, dimensions, capacity, use case, fitment, certification
If weak, an agent sees: A product exists but cannot prove it satisfies a descriptive query.
04 · Normalization
Question: Do equivalent values share one canonical representation?
Evidence: Controlled values, units, casing, punctuation, aliases, locale rules
If weak, an agent sees: One concept fragments into several filters, tokens, or analytics labels.
05 · Granularity
Question: Does each fact live at the product, variant, offer, or market level where it is true?
Evidence: Variant options, variant identifiers, market price, stock, customer-specific terms
If weak, an agent sees: The correct product is returned with the wrong size, price, availability, or fitment.
06 · Operational accuracy
Question: Does the indexed state still match the source of truth?
Evidence: Updated timestamps, sync events, retry state, deletion state, observed result
If weak, an agent sees: New items are absent or stale price, stock, and discontinued products remain visible.
07 · Search exposure
Question: Do search and filter surfaces receive the evidence the catalog stores?
Evidence: Index mapping, queried fields, analyzer, filter mapping, result-card projection
If weak, an agent sees: Rich product data is stored and displayed but never participates in retrieval.
Full mechanism, examples, and visuals for each dimension are in the ecommerce catalog quality guide.
Chapter 2 · Five value states
A missing fact is not the same as a wrong fact
Agent readiness depends on handling each state correctly. A dangerous mistake is treating Unknown as Known, or Conflicting as resolved. The action column is what a disciplined pipeline does for each.
| State | Example | Meaning | Action |
|---|---|---|---|
| Known | Material = merino wool | The fact is present and valid. | Index the typed value and its approved display label. |
| Unknown | Material has not been supplied or verified | The system lacks the fact. | Route to enrichment or supplier review. Do not infer a confident value. |
| Not applicable | Battery capacity for a non-powered item | The field does not apply to this category. | Exclude it from completeness calculations for that category. |
| Invalid | Voltage = "high" where a numeric unit is required | A value exists but violates the field contract. | Quarantine or correct it before relying on the field. |
| Conflicting | ERP says 120 V while supplier feed says 240 V | Two sources disagree. | Apply source precedence and flag the conflict for review. |
Never infer a confident value from a missing one. If material is Unknown, route it to enrichment. An agent that receives a guessed value acts on a lie.
Chapter 3 · Normalisation in practice
One concept, one canonical value, many aliases
Inconsistent values are why an agent believes two compatible items disagree, or why a filter splits one colour into four. Normalisation separates the canonical stored value from the display label and the query aliases. The examples below are drawn from the catalog quality material. This is not abstract: when the same attribute is stored as "USB C", "usb-c", and "Type-C" with no shared canonical value, the search index builds three filter facets for one concept, so a refinement query misses the items filed under the other spellings. A machine buyer then sees an incomplete result set and cannot tell whether the product is absent or merely mislabelled.
| Raw values seen | Canonical | Display | Aliases / note |
|---|---|---|---|
| navy, Navy Blue, dark blue, BLU | navy | Navy | dark blue, navy blue: Do not collapse a distinct shade when that distinction affects the buyer. |
| USB C, usb-c, Type-C | usb-c | USB-C | type c: Keep the canonical value separate from query aliases. |
| 12 volt, 12V, 12 vdc | 12 V DC | 12 V DC | 12v, 12 volt dc: Preserve the unit and current type when they are compatibility constraints. |
| Large, L, lg | L | Large | large, lg: Scope the size system to the product family and market. |
Note the unit preservation in "12 V DC": when voltage is a compatibility constraint, collapsing to "12 V" loses information an agent needs to match fitment.
Chapter 3b · In plain language: the 12 V fan that nearly shipped wrong
One un-normalised value, two different shoppers
Normalisation is a quality dimension that often silently breaks an agent. Here is the same product seen two ways. A workshop sells a cooling fan listed as "12 volt" in one place and "12V" in another, with the compatibility note "works with 12v systems" buried in prose.
What a person does
Reads the listing, sees "12 volt", reads "works with 12v systems", and decides it fits the 12 V DC control panel. The human glosses over the casing and the missing unit.
What an agent faces
Sees three different strings: "12 volt", "12V", "12v". Without a canonical value it cannot tell they are one fact, so a filter for "12 V DC" returns nothing and it reports no match, or it matches the wrong product family entirely.
| State | Catalog value | Agent outcome |
|---|---|---|
| Before | "12 volt" / "12V" / "12v" as free text | No reliable filter; wrong or missing match. |
| After | canonical 12 V DC, display "12 V DC",
aliases "12v, 12 volt dc" | Filter resolves; compatibility constraint is enforceable. |
A person absorbs the inconsistency; an agent is stopped by it. That is the whole reason agent readiness starts in the catalogue, not at the API.
Chapter 4 · Who owns each field
A record is answerable only when someone owns each fact
The buyer questions map to owners and validation rules. Agent readiness fails when a field everyone assumes someone owns actually belongs to no one. The table is the accountability layer the contract depends on.
| Buyer question | Fields | Owner | Validation |
|---|---|---|---|
| What is it? | Canonical title, product family, brand, category, product type | Catalog merchandising | Required, specific, unique enough within its family |
| Which exact item? | SKU, barcode, MPN, model, variant ID, option values | Catalog operations or ERP/PIM | Stable, unique in scope, formatting policy applied |
| Does it meet the need? | Material, dimensions, performance, use case, certification, care | Category specialist or supplier-data team | Required by category, typed value, unit included |
| Will it fit or work? | Compatibility, fitment, size system, interface, voltage, market restrictions | Technical catalog owner | Modeled as a constraint, not buried in prose |
| Can I buy it now? | Publication, market, customer access, stock, price, sellable state | Commerce platform and inventory | Current for the active context, traceable to source |
| What should the card show? | Matching variant, image, price, stock, badge, URL, selected options | Search and storefront teams | Projection preserves the evidence that caused the match |
Chapter 5 · The ownership trail
From source event to rendered card, each stage has a contract
An answerable catalogue is a pipeline, not a snapshot. Each stage hands a contract to the next, and each has a monitor that catches drift. If a stage's monitor is silent, the agent eventually acts on stale or partial data without anyone knowing.
New product created
Source: PIM, ERP, supplier feed, or commerce admin
Contract: Identity, category, required attributes, publication intent
Monitor: Rejected record count and missing required fields
Variant or offer changes
Source: Commerce, ERP, inventory, pricing service
Contract: Variant ID, options, SKU, price, stock, market, timestamp
Monitor: Source-to-index delay and conflicting updates
Catalog record transformed
Source: Integration or enrichment pipeline
Contract: Field mapping, normalization version, source lineage, validation result
Monitor: Dropped fields, defaulted values, schema failures
Search document indexed
Source: Search indexing pipeline
Contract: Document version, searchable fields, filters, variant projection
Monitor: Failed writes, stale documents, missing deletions
Result rendered
Source: Storefront theme or search UI
Contract: Matching ID, displayed variant, price, stock, URL, selected options
Monitor: Engine-to-card mismatches and broken handoffs
Chapter 6 · The boundary
Catalogue quality is necessary, not sufficient
A readable catalogue does not make a store agent-ready by itself. The store still needs a response contract (the contract guide) and a way to attribute and bound the agent. But without the catalogue, the contract lies. Fix the data first; layer the interface on top.
A structured answer over weak data is a faster wrong answer. The contract guide and this guide are two halves of one readiness story; neither stands alone.
Research basis
Grounded in existing catalogue and variant material
The dimensions, value states, normalisation examples, and ownership trail summarise the catalogue-quality and variant-search guides already published. Agentic commerce does not change the requirements; it raises the cost of ignoring them. The figures here are drawn from those guides and are illustrative of the pattern, not measurements of a specific store.
Sources checked August 4, 2026
- Ecommerce Catalog Quality guide: The seven quality dimensions, value states, and normalisation detail this summary draws from.
- Ecommerce Variant Search guide: Why variant identity and the identifier-to-handoff trace matter to a machine buyer.
- Agent Search Contract guide: The response structure this catalogue work feeds.
Where ParticleSearch fits
We help the store answer, after the data is ready
ParticleSearch works on the search and discovery layer. It depends on the catalogue being structured, and it makes that structure answerable to both people and agents. It does not replace catalogue hygiene, and it does not issue wallets or settle payments.
Framework reflects catalogue-quality and variant-search material current on August 4, 2026. Wallet and x402 capabilities remain subject to their vendors' release.
Review the ParticleSearch storefront experience