Product & Catalog Data: The Foundation of AI Commerce Readiness

AI-assisted shopping may feel fundamentally different from traditional ecommerce.

A shopper can describe a need conversationally, add constraints, compare alternatives and refine a decision without translating everything into a series of short search queries. The experience may be powered by sophisticated AI models, but the quality of the commerce experience still depends on something much more familiar:

Reliable product data.

An AI system cannot confidently reason about a product if basic facts about that product are incomplete, inconsistent, inaccessible or outdated.

It cannot reliably compare two variants if the relationship between them is unclear. It cannot determine whether a product meets a shopper’s budget if pricing is stale. It cannot determine whether an item can be purchased if inventory or availability signals disagree. And it cannot accurately explain differences between products when important attributes are missing from the data available to it.

That is why Product & Catalog Data is the first of the seven dimensions in RPE Origin’s AI Commerce Readiness Assessment.

The objective is not simply to determine whether a company has a product catalog.

Most commerce organizations do.

The more important question is:

Can the organization trust the product information being exposed to the systems that increasingly participate in product discovery?

Product Data Is Becoming Discovery Infrastructure

Product feeds are not new.

Retailers have used them for years to support shopping platforms, marketplaces, paid media, affiliate programs, comparison engines and other digital-commerce channels.

What is changing is the role that structured product information can play in AI-assisted product discovery.

OpenAI’s current Agentic Commerce documentation describes structured product feeds as a means of supplying ChatGPT with catalog data it can use to index products, understand core attributes and present accurate product information in shopping experiences. The supported product-feed specification includes product identity, descriptions, imagery, pricing, availability and optional data for variants and other product attributes.

Google likewise describes Merchant Center product data as foundational information used to match products with relevant queries and as a foundational input for AI-powered formats and experiences. Google also warns that inaccurate identifiers, missing variant information and conflicting data between a feed and a website can create eligibility or display problems.

Those developments reinforce an important shift.

Product data is no longer merely an operational input used to populate a storefront or advertising campaign. It increasingly participates directly in the infrastructure through which external systems understand the catalog.

That makes its quality strategically important.

A retailer may know internally exactly what a product is, which variant is available, how it differs from another model and when the price last changed.

The external system does not inherit that institutional knowledge.

It sees the evidence that has been made available to it.

The Readiness Standard Is Higher Than “We Have a Feed”

Having a product feed does not establish AI Commerce readiness.

Neither does having a PIM, an ERP, structured data on the website or a well-maintained ecommerce platform.

Those systems can all exist while significant inconsistencies remain between them.

A readiness assessment therefore examines product data as an interconnected system rather than treating an individual feed or platform as proof that the problem has been solved.

RPE Origin evaluates whether product identity, variants, attributes, pricing, inventory and feed data are complete, accurate, consistent and current.

Each of those words matters.

Complete means the information needed to understand and distinguish the product is actually present.

Accurate means the information represents the product correctly.

Consistent means different systems and channels are not presenting contradictory versions of the same facts.

Current means time-sensitive information such as pricing, inventory and availability reflects the state of the product closely enough to be useful.

A catalog can perform well on three of those criteria and still create material problems because of the fourth.

Can Each Product Be Identified Reliably?

Product identity is the starting point.

A commerce organization may use SKUs, internal product IDs, GTINs, manufacturer part numbers, parent IDs, item-group identifiers, channel-specific IDs or combinations of those values to identify products.

The specific identifiers vary by business.

What matters is whether the organization can establish a stable relationship between a product and the representations of that product distributed throughout its commerce ecosystem.

This becomes more difficult as environments grow.

A company may introduce a new ecommerce platform while retaining an older ERP. It may add a PIM, marketplace syndication platform, advertising feed manager and regional catalogs. Acquisitions can introduce additional identifiers. Legacy systems may impose different field constraints. Teams may create transformations to satisfy the requirements of individual channels.

Eventually, the same physical product can exist as several slightly different records across multiple systems.

That is not automatically a defect.

The readiness issue is whether those representations can be reconciled reliably.

If an identifier is reused, transformed inconsistently or disconnected from the product record it is supposed to represent, downstream systems may have difficulty determining whether two records describe the same product, different products or variants of a common parent.

Google’s product-data guidance emphasizes stable product identifiers and identifies incorrect GTIN values as a common source of Merchant Center problems.

OpenAI’s current product-feed specification similarly calls for a stable item identifier and requires one row per purchasable item or variant.

The assessment question is therefore not:

Do we have SKUs?

It is:

Can product identity be followed consistently from its source through the systems and channels that represent it?

Are Product Variants Explicit and Consistent?

Many commerce catalogs become significantly more complex once variants are introduced.

A shirt may differ by color and size. A piece of furniture may vary by fabric and finish. An electronic product may have storage or connectivity configurations. Industrial products may differ by dimensions, voltage, materials or technical specification.

Internally, a merchandising team understands those relationships immediately.

Machines need them represented explicitly.

If six SKUs are variants of the same underlying product, the data model should make that relationship clear. The attributes that distinguish one variant from another should also be represented consistently.

Problems begin when the relationships diverge.

The PIM may contain a parent-child structure while the ecommerce platform treats each SKU as an independent product. One outbound feed may group variants correctly while another does not. Titles may distinguish color but omit size. Structured data may describe only the currently selected variant while another feed represents the entire family differently.

Google specifically calls out missing or incorrect variant attributes such as item group ID, color and size as common product-data issues.

OpenAI’s current feed specification similarly treats purchasable items or variants as distinct rows and provides structured fields for product identity and optional variant-related information.

Variant modeling is therefore more than catalog housekeeping.

It is part of the information architecture that allows another system to understand which products belong together and what makes each choice different.

Are the Attributes That Matter Actually Present?

Once identity and variants are established, the next question is whether the available attributes provide enough information to describe the product meaningfully.

Some attributes are nearly universal: title, description, brand, price and availability.

Others depend heavily on the category.

For apparel, size, color, material and fit may matter.

For electronics, storage, dimensions, screen size, processor, compatibility or connectivity may become critical.

For tools, power source, voltage, capacity, materials or compatible accessories may determine whether a product is appropriate.

For furniture, dimensions and materials may be essential to the purchase decision.

The problem is that product information often develops unevenly.

One product family may contain highly structured attributes while another relies heavily on prose. A manufacturer feed may populate technical specifications completely while private-label products use a different model. Important differentiators may exist only in PDF documentation or marketing copy.

The product page may technically contain the information, but that does not necessarily mean the information exists in a form that can be used consistently by downstream systems.

Google’s product_detail attribute is a useful example of the direction platforms are taking. Google allows merchants to provide structured technical specifications and additional product details and states that the data can help customers discover product information across AI-driven surfaces such as AI Mode as well as traditional search experiences.

The readiness assessment therefore asks not only:

Which fields are populated?

It also asks:

Are the attributes necessary to understand, differentiate and compare these products represented in a reliable and reusable way?

Do Price, Availability and Inventory Represent Reality?

Some product facts change slowly.

Others can change minute by minute.

Price and availability belong to the second category.

That makes them particularly important in AI-assisted discovery.

A recommendation can be logically appropriate and still create a poor customer experience if the product is no longer available or costs substantially more than the information used to recommend it suggested.

These inconsistencies can originate in many places.

A promotional price may have ended on the website but remain in a downstream feed. Inventory can update in the ERP faster than the ecommerce platform. Regional availability may differ. A discontinued SKU can remain in a marketplace feed. A particular variant may be out of stock while the parent product still appears available.

The technical issue is freshness.

The operational issue is authority.

Which system has the final word about the current price, inventory and availability of a product?

And just as importantly:

How quickly does that truth propagate to the systems that depend on it?

OpenAI’s current product-feed guidance instructs merchants to keep current prices and availability updated in the feed. Its product-feed documentation also provides supported delivery methods designed to keep catalog information current.

Google provides similar mechanisms. Its Merchant Center documentation explains that structured product data can support automatic item updates and help reduce mismatches involving product data and landing-page information.

AI Commerce readiness therefore includes both data accuracy and the operational mechanism that keeps that accuracy intact.

Do the Systems Agree?

Most established commerce organizations do not have one product system.

They have an ecosystem.

A typical environment might contain an ERP, PIM, ecommerce platform, CMS, inventory service, pricing engine, marketplace connector, advertising feed, structured website data and one or more custom integrations.

That architecture is not inherently problematic.

Different systems should specialize.

The risk appears when those systems disagree and no governed process determines which source is authoritative.

Consider a single product where the ERP says the item is active, the PIM contains an older description, the ecommerce platform contains a promotional price, the merchant feed still carries the standard price, structured data omits one variant and a marketplace has not yet removed discontinued inventory.

Every individual system may be functioning exactly as designed.

The commerce ecosystem is still presenting multiple versions of product truth.

This is one reason a readiness assessment should not examine feeds in isolation.

The assessment needs to understand where product truth originates, how it changes as it moves through the architecture, and where discrepancies can be introduced.

Google’s Merchant Center guidance requires submitted product data to align with what users see on the landing page and provides specific matching requirements involving product identifiers.

That principle extends beyond any one platform.

If the same product is represented differently depending on which machine-readable source is consulted, the organization has a governance and synchronization problem as much as a data problem.

Is the Catalog Maintained as Requirements Change?

AI Commerce readiness is not a one-time data-cleanup exercise.

Products change.

Catalogs change.

Channels change.

And external platform requirements change.

Google’s 2026 Merchant Center specification update illustrates that point. Google added new product-level shipping capabilities and announced updated image-size requirements that begin enforcement in 2027.

OpenAI’s Agentic Commerce specifications likewise distinguish between supported stable schemas and draft capabilities intended for planning and feedback.

The important readiness question is not whether the catalog satisfies every possible field that exists today.

It is whether the organization has the operational discipline to identify material changes, determine whether they apply, update its product model and maintain the resulting integrations.

A catalog that is accurate once but difficult to maintain is not particularly resilient.

What Product-Data Problems Look Like in Practice

A useful assessment should produce findings more specific than “product data needs improvement.”

That diagnosis does not tell a commerce team what happened, where it happened or what should be corrected.

A stronger finding might identify that a group of product variants is not consistently linked to a common parent across systems. Another might show that a feed is publishing promotional prices after the associated campaign has expired. A third might find that important compatibility information exists in PDF documentation but is not represented in structured product attributes.

Other findings might involve unstable identifiers, incomplete GTIN coverage, category attributes that are populated inconsistently, discontinued products that continue flowing downstream, inconsistent taxonomy, undocumented feed transformations or unclear ownership of particular product fields.

The distinction matters because the remediation differs.

An identifier problem may require governance.

A stale price may require integration changes.

An attribute-coverage problem may require product-content remediation.

An inconsistent variant structure may require data-model changes.

A feed discrepancy may originate not in the source product record but in transformation logic between systems.

Specific evidence produces specific work.

That is why one of RPE Origin’s core assessment principles is:

Score the evidence, not the ambition.

What Evidence Does the Assessment Examine?

An AI Commerce Readiness Assessment should not begin by asking whether stakeholders believe their catalog is well managed.

It should examine the catalog itself.

Depending on the commerce architecture, that can include product exports, PIM records, ecommerce catalog data, Merchant Center feeds, marketplace feeds, APIs, inventory and pricing data, structured data, taxonomy documentation, representative product pages and the processes governing how product changes are approved and distributed.

The important methodological step is to connect those artifacts.

Rather than examining a product feed as an isolated file, representative products can be traced from their authoritative source through downstream systems and ultimately into the information exposed externally.

That makes it possible to see where information changes.

An attribute may exist correctly in the PIM but disappear in the ecommerce transformation. A price may be accurate in the commerce platform but update too slowly in a downstream feed. A variant relationship may be defined correctly in one channel but lost in another. Structured data may represent different facts from the visible product page.

The assessment can also deliberately select products that stress different parts of the catalog model: products with several variants, complex technical specifications, changing promotional prices, compatibility requirements, inventory constraints or replacement relationships.

The purpose is not necessarily to inspect every SKU manually.

It is to determine whether the underlying data model, integration architecture and operating process consistently produce trustworthy product information.

That establishes a defensible baseline.

Reliable Product Truth Benefits More Than AI

AI Commerce adds urgency to these questions, but the value of better product data is not limited to AI.

More consistent product information can support ecommerce search, marketplace syndication, advertising, merchandising, personalization, customer service, analytics and other systems already dependent on the catalog.

That matters strategically.

Organizations should be cautious about treating AI Commerce readiness as a collection of isolated optimizations for a particular AI platform. Platforms and integration patterns will continue to evolve.

The more durable objective is to improve the quality, structure, accessibility and governance of the commerce information those systems consume.

OpenAI’s current Agentic Commerce documentation illustrates why. Product feeds provide structured catalog data that helps ChatGPT surface products with accurate pricing, availability and seller context.

Google continues to expand the structured product information it can consume through Merchant Center and product markup.

The implementation details differ.

The underlying requirement is remarkably consistent:

Machines need reliable product evidence.

Product Data Is the Foundation, Not the Finish Line

A catalog can satisfy every basic data-quality requirement and still fall short of what is needed for sophisticated AI-assisted recommendations.

Imagine a product record for a cordless drill.

The catalog may accurately describe it as an 18V drill with a half-inch chuck and a 2.0Ah battery.

Those facts establish what the product is.

They do not necessarily establish whether it is appropriate for a first-time homeowner, whether it can handle masonry, which battery ecosystem it uses, what accessories are compatible, why a customer might choose it over another model or when a more powerful product would be appropriate.

Those are different questions.

They move beyond product data and toward product knowledge.

That distinction is central to the readiness framework.

Product data establishes identity and factual product truth.

Semantic product knowledge adds context around use, suitability, compatibility, audience, differentiation and relationships.

A product first needs to be represented reliably.

Then it needs to become understandable in context.

Only then can another system have stronger evidence for determining whether it belongs in a particular recommendation.

That is the progression:

Available → Understandable → Recommendable

Reliable product and catalog data establishes the foundation.

The next dimension—Semantic Product Knowledge—examines what happens when we move beyond describing what a product is and begin establishing when, why and for whom that product may be appropriate.

Product data is the foundation of AI Commerce readiness. If product identity, variants, attributes, pricing, inventory or feeds are inconsistent, downstream AI systems may be working from incomplete or conflicting information. An AI Commerce Readiness Assessment can help establish where those gaps exist and which issues should be prioritized first.