Machine-Readable Product Data

AI does not need another product description explaining that Midnight means black, Pro means the expensive version, and usually ships quickly means somewhere between tomorrow and the end of the universe.

It needs product data where identity, attributes, relationships, variants, price, availability, language, and context are explicit.

That is what machine-readable product data means: product information structured so crawlers/agents/and who knows who else can reliably identify, query, compare, filter, transform, and act on it without first interpreting marketing copy.

And today, this matters beyond traditional SEO. Search engines consume structured data. Shopping platforms consume feeds. Applications consume APIs. Retrieval systems consume structured metadata and embeddings. AI agents increasingly consume tools and resources through protocols such as MCP.

The mistake is in trying to create a separate “AI catalog” for each of them.

A better architecture starts with one canonical product model and projects it into the formats different machines need:

For developers, that is mainly a data architecture problem. For business leaders, it determines whether products can actually be discovered, understood, compared, recommended, and eventually purchased in AI-mediated buying journeys.

And yes, it also determines whether your next AI initiative becomes a useful commerce capability or an extremely expensive chatbot guessing what misc_attribute_07 means.

Machine-readable product data is product information represented with explicit structure, types, identifiers, and relationships rather than relying primarily on prose or presentation.

We look at a product page and infer quite a lot:

Alto Chair
Black oak
48 cm wide
Available in Oslo
€349

Software/crawler/AI should not have to infer any of that. A better underlying representation separates those concepts:

{
  "productId": "alto-chair",
  "name": "Alto Chair",
  "category": "Dining Chair",
  "material": "Oak",
  "widthMm": 480,
  "variants": [
    {
      "sku": "ALTO-BLK",
      "color": "Black",
      "price": {
        "currency": "EUR",
        "amount": 349
      },
      "availability": "in_stock"
    }
  ]
}

The difference looks trivial until you try to make machines do something useful with it.

Prompt 'show me black oak dining chairs under 50 cm wide and €500' is easy when those properties are typed fields. It becomes natural-language archaeology when width, color, material, and price have been baked into paragraphs, filenames, category labels, and whatever somebody typed into a CMS in 2018.

This is why AI-ready product data is not fundamentally an AI problem. It is a product modeling problem that AI has made impossible to ignore.

Start by eliminating machine guesswork. An AI-ready product model should make five things particularly clear: identity, meaning, relationships, commercial state, and provenance.

A product is not its URL. A SKU is not always the product. A variant is not necessarily a new product family. Yet plenty of commerce architectures quietly treat all three as interchangeable until localization, marketplaces, subscriptions, bundles, or AI discovery arrive and make the distinction expensive.

A useful identity model is:

Each has a different job.

The product ID identifies the conceptual product. The variant ID identifies a specific configuration. The SKU supports merchant operations. The Global Trade Item Number (GTIN) provides an interoperable trade identity where applicable. The URL tells software where the product can be found.

AI models are good at language. That does not mean every product fact should become language.

If width matters commercially, store a number and a unit. If waterproofing matters, use a boolean or controlled value. If material matters for filtering and recommendations, use a structured field or relation. If compatibility determines whether a customer can use the product at all, please do not hide it on line four of the long description.

This is especially important because commerce queries combine fuzzy intent with exact constraints.

“Something minimalist for a small dining room” is semantic.

“Under 75 cm wide, in stock, below €600” is not.

Good product architecture supports both; a modern platform allows it. Smart enough for semantics, strict enough for specs.

Crystallize uses Shapes as product and content blueprints, with components for text, numeric values, media, relations, selections, dates, structured groups, and other field types. Product Shapes can also model variants, prices, stock, and attributes.

That matters because structured product modeling should happen at the source, not in later steps.

Product data is rarely flat. A shoe belongs to a brand, a collection, a category, a material taxonomy, perhaps a sustainability certification, and a family of variants. An industrial component may relate to compatible machines, replacement parts, installation documentation, and regulatory classifications.

Those relationships should exist as relationships.

This is where modern PIM architecture has an advantage over the classic “product table plus 200 custom columns” model. In Crystallize, components and relations can connect products with other catalog entities, while the wider Product Universe can hold products alongside structured marketing content and other supporting information.

AI systems benefit because they can navigate a product graph rather than infer one from duplicated strings.

The business benefit is more mundane and more useful: change the brand information once instead of discovering that 417 products each contain their own slightly different version of it.

This becomes critical when AI search and RAG enter the picture. Descriptions, features, use cases, categories, materials, style, and compatibility are good candidates for semantic indexing or embeddings.

Exact prices, inventory counts, personalized pricing, and availability are not.

If the stock changes from 12 to 11, you should not need to regenerate the embedding. If the price changes at 14:06, an AI assistant should not cheerfully quote the vector database copy from Tuesday.

Use semantic retrieval to determine which product is relevant, then retrieve or hydrate volatile commerce data from the authoritative source before presenting the answer.

That architecture looks roughly like:

Vector search is useful. Turning the whole catalog into vectors and hoping cosine similarity understands inventory is less useful.

Once product information passes through APIs, feeds, search indexes, embeddings, caches, and AI applications, “where did this value come from?” becomes a serious operational question.

At minimum, downstream records should retain:

• source product ID
• source update timestamp
• indexing timestamp
• language or market
• transformation or schema version
• content hash where useful

The goal is not provenance theatre. You need enough metadata to detect when the source says one thing and the search or AI layer says another.

For AI commerce, freshness is part of product correctness. A recommendation for a product that existed yesterday is annoying. A recommendation with yesterday's price is potentially expensive.

schema.org is important, but it is not the whole architecture. This distinction has become more important because discussions about AI discoverability often mix schema.org, GraphQL, feeds, embeddings, and MCP as though they were competing answers to the same question.

They are not. They operate at different layers.

The useful question is not schema.org vs GraphQL vs MCP.

It is where each belongs in the architecture.

schema.org gives machines a standardized vocabulary for describing entities on web pages. For commerce, that includes types such as Product, ProductGroup, and Offer.

Google's product variant documentation uses ProductGroup to represent the common product and individual Product entities for variants, including relationships such as hasVariant, isVariantOf, and variesBy.

A simplified product family Schema vocabulary you might use looks like:

{
  "@context": "https://schema.org",
  "@type": "ProductGroup",
  "name": "Alto Chair",
  "productGroupID": "alto-chair",
  "variesBy": [
    "https://schema.org/color"
  ],
  "hasVariant": [
    {
      "@type": "Product",
      "sku": "ALTO-BLK",
      "color": "Black",
      "offers": {
        "@type": "Offer",
        "price": "349.00",
        "priceCurrency": "EUR",
        "availability": "https://schema.org/InStock"
      }
    }
  ]
}

This is useful because it gives crawlers an explicit interpretation of what the visible page represents.

But schema.org should ideally be generated from your underlying product model.

Do not create carefully maintained structured data that disagrees with the PIM, storefront, merchant feed, and warehouse. Machines are remarkably efficient at consuming inconsistent data at scale.

GraphQL solves a different problem. A GraphQL API exposes a typed schema describing what data exists and how clients can query it. GraphQL also supports introspection, meaning tools can inspect available types, fields, relationships, and arguments.

That turns out to be useful for AI agents as well. The GraphQL project now explicitly positions its self-describing schema, introspection, validation, and selective field retrieval as useful properties for agents.

An application or agent could ask for exactly what it needs:

query {
  product(id: "alto-chair") {
    name
    variants {
      sku
      color
      stock
      price
    }
  }
}

That is excellent deterministic machine access. What GraphQL does not do is make the endpoint magically discoverable to every crawler on the open web.

Google is not wandering around looking for random /graphql endpoints and introspecting them until it finds a chair. That would be less search engine optimization and more automated penetration testing.

So GraphQL complements schema.org rather than replacing it.

Crystallize's Discovery API illustrates this nicely. It is a read-optimized GraphQL API whose structure follows the Shapes and components defined in the tenant. It supports browsing, search, filtering, faceting, sorting, ranking, and personalization from the same product model.

In other words, if your model contains meaningful product semantics, those semantics can flow directly into a typed machine interface.

Model Context Protocol (MCP) sits another layer up. It does not define what a product, SKU, variant, or price means. It standardizes how AI clients interact with servers that expose resources and tools.

MCP makes APIs and capabilities understandable and accessible to agents within guardrails. If you have documentation of your APIs, it's possible for an AI to reach your capabilities also, but without context.

For commerce, MCP might expose capabilities such as:

searchProducts()
getProduct()
getProductModel()
checkStock()
calculatePrice()
createCart()

The agent does not need to understand every backend API upfront. It discovers what the MCP server allows it to do and invokes those capabilities.

But the underlying product data still needs to be well modeled.

MCP can give an agent a beautifully standardized tool called findCompatibleReplacementPart. If the catalog has no structured compatibility data, congratulations: you have built a standardized interface to ambiguity.

Crystallize provides a concrete example. Crystallize MCP server can query data, fetch the content model, introspect schemas, suggest and set up the model. Read operations are enabled by default, while mutation capabilities can be explicitly added.

There is another layer that deserves more attention: feeds.

Feeds are not glamorous. They are flat files, mappings, validation errors, and the occasional afternoon spent discovering that somebody interpreted “available” differently in three markets.

They also work.

Google Merchant Center established the pattern long ago: merchants send normalized product information into a system specifically designed to ingest commerce data.

AI commerce is heading in the same direction.

OpenAI's current Agentic Commerce documentation includes structured product feeds intended to enable ChatGPT to index and display products with current prices and availability. The specification requires core data including product identifiers, titles, descriptions, URLs, images, availability, price, and brand, and also supports variant and geographic information. It can also accept a supported Google-compatible product feed format.

That development is strategically important.

It suggests that AI product discovery will not depend on a single mythical “AI SEO format.” Different systems will ingest product truth through different routes:

• crawlable pages
• schema.org
• merchant feeds
• platform-specific feeds
• APIs
• agent tools
• perhaps future commerce protocols we have not standardized yet

The smart move is not guessing which one wins.

It is maintaining product data clean enough to generate all of them.

Crystallize's architecture lends itself naturally to this model because the product structure is defined before the channel representation.

At the PIM layer, Shapes define what a product contains. Components can represent strings, numbers, media, selections, relations, dates, structured groups, and reusable pieces. Product variants then have native commerce fields such as SKU, stock per location, prices, attributes, and media.

Imagine a furniture product. Instead of this:

Oak dining chair in black. Width: 48 cm.
Works well in Scandinavian interiors.
Also available in natural oak.

You can model:

Product: Alto Chair
Category → Dining Chair
Brand → Northwind
Material → Oak
Style → Scandinavian
Width → 480 mm
Suitable for → Indoor

and then variants:

ALTO-BLK
Color → Black
Stock → 21
Price → EUR 349

ALTO-OAK
Color → Natural Oak
Stock → 8
Price → EUR 349

The copy still matters. Humans shop emotionally as well as rationally, and AI search benefits from descriptive language.

But now the copy does not carry the entire burden of explaining what the product actually is.

The same structured model can be surfaced through Crystallize's Discovery API. Because Discovery's GraphQL structure follows tenant Shapes, product semantics become API semantics. Fields can be indexed for filtering, faceting, sorting and ranking, and Discovery also supports vector-based vocabularies and similarity capabilities alongside more conventional search mechanisms.

This is a useful design pattern for AI commerce: structured retrieval, where exactness matters; semantic retrieval, where meaning matters.

Crystallize can then sit behind other representations. A storefront can generate schema.org markup from the same source data. Feed-generation jobs can map the canonical model to Google or AI-platform requirements. An AI application can query GraphQL directly. An agent can access capabilities through Crystallize's MCP server.

One catalog. Multiple interfaces.

That is considerably easier to govern than giving every channel its own interpretation of “product.”

Most companies do not start with completely unstructured product data. They start with partially structured data whose semantics have drifted over time. Plenty of examples:

• One supplier uses navy. Another uses dark blue. Marketing uses midnight. The ERP says BLU-03.
• Width is stored in millimeters for one category and centimeters for another.
• Product families exist conceptually, but variants have become standalone records because one marketplace needed them that way six years ago.
• Brand information exists as a relation in the PIM, as a string in the ERP, as another string in the CMS, and, apparently, as a spreadsheet owned by Martin from the warehouse in Skien, not Oslo.

AI does not create these problems; it exposes them.

This is the non-obvious upside of the current AI wave: it is forcing companies to finally answer architecture questions they could previously hide behind a nice storefront. Simple questions such as:

• What is the product?
• What is the variant?
• Which system owns which value?
• Which attributes have controlled vocabularies?
• Which relationships matter?
• What is public?
• What is customer-specific?
• How fresh must each field be?

Without those answers, the problem is not AI readiness. The problem is product information governance wearing an AI hat.

Do not start by buying a vector database or building an MCP server. Start where the ambiguity starts: the product model. You can try our AI tool, Flare, to see what it can look like.

From talks with our clients during demos and first build time, we’ve come to the conclusion that a sensible order is:

1. Establish canonical product and variant identities. URLs and names are addresses and labels, not durable identity.
2. Structure the attributes that influence buying decisions. Dimensions, material, compatibility, size, brand, categories, pricing, and availability should not depend on the extraction of prose.
3. Model product relationships and taxonomies explicitly. Give machines context rather than hoping they infer your catalog hierarchy.
4. Separate descriptive semantics from volatile commerce facts. Search semantically; retrieve price and availability authoritatively.
5. Generate schema.org from the canonical model (your internal, central product base). Do not treat Schema.org like a separate, secondary catalog. The public-facing Schema.org markup updates automatically without human intervention.
6. Generate merchant and AI feeds from the same source. Feeds are becoming important ingestion surfaces for AI commerce and search.
7. Expose deterministic product access through APIs such as GraphQL.
8. Add hybrid semantic retrieval where natural-language discovery creates value.
9. Add MCP when agents need to discover data capabilities or perform actions.
10. Measure freshness and correctness, not merely whether the chatbot produced an answer.

The order matters. Putting MCP in front of poor data does not make the data agentic.

It just lets the agent reach the poor data faster.

For years, structured product data was discussed mainly as a PIM concern or an SEO implementation detail.

That framing today is too narrow.

Your products increasingly need to be understood by search engines, marketplaces, recommendation systems, conversational interfaces, LLMs, shopping assistants, and autonomous agents. Some will crawl your pages. Some will ingest feeds. Some will query APIs. Some will call tools.

There will not be one universal “AI product format” that makes all of this disappear.

The durable strategy is a product model that can support many machine interfaces without changing what the product means every time a new channel appears.

That is where platforms such as Crystallize become relevant. Shapes and typed components establish the model. Variants capture sellable configurations and commerce data. The Discovery API exposes that model through semantic GraphQL. Webhooks keep integrations synchronized. MCP adds an agent-facing access layer. Structured web data and product feeds can then be generated as downstream projections rather than competing sources of truth.

The strategic test is surprisingly simple:

Can a machine determine exactly what this product is, how it differs from its variants, what its important properties mean, whether it can be purchased now, and where those facts came from — without guessing?

If yes, your product data is ready for AI, search, agents, and whatever interface comes next.

If not, adding an LLM does not solve the ambiguity.

It merely gives the ambiguity excellent conversational skills.

We can help here. SCHEDULE A 1-on-1 DEMO to see how Crystallize can help you transform your product data for agentic commerce. Or, why not START building for FREE.