The Best Global Catalogs Do Not Make Products the Same

A shopper asks an agent to find the best waterproof jacket under $150. The request sounds simple. Yet behind that sentence is a small crisis of language.

One merchant calls a product "water resistant." Another uses "weatherproof." A third stores the feature as a numerical rating. Prices may include shipping in one catalog and exclude it in another. Sizes, colors, materials, availability, and return policies all arrive in different shapes. Before an agent can compare anything, it must decide whether these records are even talking about the same kinds of things.

This is the hidden problem beneath global discovery: how can a system create a shared view of the world without destroying the local meanings that make each record useful?

The answer is not simply to connect every system to every other system. That approach creates a web of brittle translations, where each new application increases the number of dependencies. Nor is the answer to force every merchant, application, or domain to adopt one rigid format. That merely relocates the complexity and often erases important distinctions.

The deeper solution is a carefully designed canonical layer: a common language that allows many local systems to communicate while preserving enough context to prevent false equivalence. In the age of agents, this is more than an integration technique. It is the infrastructure of trustworthy comparison.

The real enemy is not different data. It is uncontrolled interpretation

Imagine four retailers selling what appears to be the same black hiking boot. One describes it using a product title, another emphasizes a style code, a third lists a manufacturer identifier, and a fourth bundles the boot with accessories. Their data formats differ, but format is only the visible problem.

The harder issue is meaning. Does "black" refer to the upper material, the entire shoe, or the color family assigned by the merchant? Does a price represent a single item, a pair, or a subscription? Does "in stock" mean physically present, available for immediate shipping, or merely orderable from a supplier?

A system can easily make two records syntactically compatible while leaving them semantically incompatible. It can place every record into fields called price, color, and availability, yet still produce comparisons that are wrong in ways users cannot see.

This distinction matters because integration has two different forms of complexity:

1. Structural complexity, which concerns how data is represented. Fields may be named differently, nested differently, or encoded in different types.
2. Semantic complexity, which concerns what the data actually means. Similar labels may refer to different concepts, while different labels may express the same one.

A canonical data model primarily reduces structural complexity, but its real value appears when it becomes a disciplined place for semantic decisions. It gives a system somewhere to answer questions such as: What counts as a product? What is a variant? Which price is comparable? Which attributes are optional, uncertain, or merchant specific?

Without that shared layer, every application must learn the private dialect of every other application. If five systems need to communicate directly, the integration burden can grow toward twenty translation paths. With a common intermediate language, each system translates into the shared model once, and consumers translate out of it as needed.

The important insight is not that a canonical model makes everything identical. It makes differences legible.

A common model should not eliminate local variation. It should give variation a stable place to appear.

A global catalog is a test of whether the common language is honest

Global product discovery makes this challenge concrete because it asks an agent to compare entities that were never designed to be compared. A merchant catalog is usually optimized for one store's operations, vocabulary, merchandising strategy, and customers. A global catalog must support questions that cross those boundaries.

Consider a request for "a compact espresso machine with a built in grinder, under $400, suitable for a small kitchen." To answer well, an agent needs more than a list of products. It needs a model that can represent:

• Product identity across merchants
• Variants and configurations
• Attributes such as dimensions, power, capacity, and included features
• Price and currency
• Current availability
• Merchant identity and fulfillment context
• Evidence for each claim
• The difference between an explicit fact and an inferred recommendation

The global layer therefore acts as a semantic meeting place. A merchant can preserve its own catalog structure while exposing the concepts an agent needs for discovery. The agent does not need to understand every internal table or naming convention. It needs a reliable representation of the product facts relevant to the user's question.

But this only works if the shared model distinguishes between facts and interpretations. "Stainless steel body" is a merchant supplied attribute. "Good for a small kitchen" is an inference based on dimensions. "Best value" is a judgment that depends on price, quality, shipping, and user priorities. Treating all three as equivalent fields would make the system appear precise while hiding different levels of certainty.

This suggests a useful design principle: canonical models should carry provenance, not just values. For each important property, a discovery system should ideally know:

• Where the value came from
• When it was last updated
• Whether it was explicitly stated or inferred
• How confidently it maps to the shared concept
• Under what conditions the value applies

For example, a normalized product record might represent a jacket's water resistance like this in conceptual terms:

attribute: water_resistance
value: resistant
source: merchant description
confidence: medium
qualification: not tested for prolonged immersion
updated: recent catalog refresh

This is more useful than a deceptively clean Boolean field such as waterproof: true. The normalized record is not merely a container. It is an argument about what a source means, with enough evidence for another system to evaluate that argument.

The paradox of canonicalization: the cleaner the model, the greater the risk

A canonical model reduces friction, but it can also create a new kind of danger: false simplicity. Once many sources are translated into a shared schema, the differences between them may disappear from view. This is especially dangerous for agents, because agents are optimized to produce fluent answers from structured inputs. If the structure conceals uncertainty, fluency becomes a form of misrepresentation.

Suppose a global catalog reduces all delivery information to one field called available. A product can then be sorted and recommended efficiently. Yet the field may conceal several realities:

• Available for immediate dispatch
• Available from a supplier in two weeks
• Available for pickup only
• Available to some geographic regions
• Technically orderable but subject to uncertain fulfillment

The field is operationally convenient but semantically weak. It answers a narrower question than the user may think it answers.

The same problem appears with product identity. A canonical model may merge several merchant listings into one conceptual product because the brand and model number match. That can be useful for comparison. But the listings may differ in warranty, included accessories, regional specifications, or seller condition. Identity is not one thing. There is manufacturer identity, merchant listing identity, variant identity, and offer identity.

A robust global catalog therefore needs layered identity:

1. The conceptual product, such as a particular model of camera.
2. The variant, such as lens configuration, storage capacity, or color.
3. The merchant offer, including price, inventory, shipping, and seller terms.
4. The retrieval moment, because the offer may change minutes later.

Collapsing these layers produces a tidy record and a poor recommendation. Keeping them distinct allows the agent to compare products while still explaining why two apparently identical offers are not interchangeable.

Canonicalization should be treated as a compression process. Compression is valuable because it removes repetition. It is dangerous because it can discard information. The design question is not, "How do we fit every source into one schema?" It is, "Which distinctions can safely be compressed, and which distinctions must survive?"

From shared schema to shared judgment

The most important shift is to stop thinking of a canonical model as a fixed dictionary. It is better understood as a decision surface between local systems and global questions.

A dictionary says that one field maps to another. A decision surface asks whether the mapping is valid for the task at hand.

For example, a merchant may have a field called material with the value "leather." A general discovery system may map this to a material concept. That seems straightforward until the user's request is "vegan leather." A casual normalization step might group both records under a broad category such as leather goods, but a trustworthy system must preserve the distinction between animal leather, synthetic alternatives, and ambiguous marketing language.

The shared model should therefore have at least three layers:

1. The stable core

This contains concepts that most consumers need and that can be defined relatively consistently: product identifier, title, merchant, currency, price, availability, category, and variant.

2. The qualification layer

This records conditions and boundaries: region, time, quantity, seller, shipping method, warranty, measurement unit, and confidence. Qualifications prevent a value from being mistaken for a universal fact.

3. The extension layer

This preserves domain specific or merchant specific attributes that do not fit the common core. Extensions are not failures of modeling. They are a pressure release valve that prevents the core from becoming bloated or coercive.

This three layer structure solves a recurring tension. If the model is too loose, agents cannot compare products reliably. If it is too strict, merchants either cannot participate or must distort their data to fit. The stable core enables interoperability, the qualification layer preserves truth, and the extension layer protects local richness.

An agent using a global catalog should also reason in two stages:

First, normalize for retrieval. Identify comparable products using shared concepts, synonyms, categories, and constraints.

Second, reintroduce difference for explanation. Before presenting a recommendation, restore the qualifications, evidence, merchant context, and unresolved ambiguity that matter to the decision.

This is a subtle but powerful pattern. The system needs sameness to search and difference to advise.

Discovery requires abstraction. Trust requires the return of what abstraction removed.

Why agents make this architecture newly urgent

Traditional integrations often have a narrow purpose. An order service may need a customer identifier and a shipping address. A reporting pipeline may need sales totals. A global agent has a much wider mandate: it must interpret open ended requests, combine evidence, compare alternatives, and explain its conclusions.

That makes the cost of poor canonicalization higher. A conventional application may fail with an error message when a mapping is wrong. An agent may produce a persuasive recommendation that looks correct. The failure is not merely technical. It is epistemic: the system presents an uncertain or invalid comparison as knowledge.

Agentic discovery also changes the direction of integration. In a conventional workflow, a known application asks a known service for a known object. In global discovery, the agent begins with a user intention and searches across unknown sources. The system must discover what is available before it can decide what is relevant.

That calls for a catalog architecture with several explicit contracts:

• Discovery contract: What entities and capabilities can be found?
• Normalization contract: Which fields and concepts are comparable?
• Evidence contract: How are claims traced to source data?
• Freshness contract: How current must price and availability be?
• Uncertainty contract: How are ambiguous, missing, or inferred values represented?
• Action contract: When can the agent merely recommend, and when can it initiate a purchase or other transaction?

These contracts turn an integration surface into a trust surface. They also make the system easier to evolve. A new merchant does not need to imitate every existing merchant. It needs to satisfy the shared contracts and clearly declare where its data extends or differs from the common model.

A useful operational measure follows from this: do not evaluate a catalog only by coverage, latency, or number of indexed products. Measure its semantic error rate. How often does a normalized attribute lead to a materially wrong comparison? How often does a recommendation depend on a stale offer? How often does the system merge listings that should remain distinct?

The best global catalog is not the one that makes the most products look comparable. It is the one that knows when comparison is justified.

A practical framework for building trustworthy global discovery

Teams designing a shared catalog or agent interface can apply the following sequence.

Start with user decisions, not source fields

List the decisions the agent must support: choosing the cheapest qualifying offer, finding a product that fits within a physical space, identifying a compatible replacement, or comparing return policies. Then define the concepts needed for those decisions. This prevents the canonical model from becoming a warehouse of whatever fields happen to exist.

Separate identity, attributes, and offers

Do not store a product name, a technical specification, and a merchant price as if they were the same kind of fact. Model the conceptual product, its variants, and each merchant offer separately. This protects comparisons from accidental merging.

Make ambiguity explicit

Use values such as unknown, not provided, not applicable, and inferred distinctly. A missing value is not the same as a negative value. "No waterproof rating supplied" should never silently become "not waterproof."

Preserve source context

Every normalized claim that could affect a purchase decision should retain source, timestamp, scope, and confidence. This supports auditing, refresh strategies, and explanations to users.

Normalize only as far as the decision requires

If two attributes are equivalent for a particular query, map them together for that query. Do not assume they are universally interchangeable. A broad category may be sufficient for discovery but insufficient for final ranking.

Let the agent ask for clarification

When the shared model cannot resolve a meaningful ambiguity, the best response may be a question. Does the user need delivery by Friday, or is the product merely required to be orderable? Is "under $150" inclusive of shipping and tax? Clarification is not a failure of automation. It is a way to prevent hidden assumptions from becoming bad outcomes.

Key Takeaways

• Use a canonical layer to reduce dependencies, not to erase differences. The goal is a stable translation point between local systems and global questions.
• Treat semantic compatibility as more important than structural compatibility. Matching field names does not mean matching meaning.
• Separate retrieval from explanation. Normalize aggressively enough to find candidates, then restore provenance, qualifications, and uncertainty before recommending.
• Model identity in layers. Keep conceptual products, variants, merchant offers, and time sensitive conditions distinct.
• Measure semantic error, not only technical performance. A fast catalog that creates false equivalence is worse than a slower catalog that knows its limits.

The future of product discovery will not be determined by how many catalogs an agent can access. It will be determined by whether the agent can move between different commercial worlds without confusing translation with truth.

A canonical model is often described as a solution to a dependency problem. In practice, it is a solution to a judgment problem. It creates the shared language through which fragmented systems can become searchable, but it also defines which differences remain visible when a decision is made.

That is why the central question is not whether every merchant can speak the same language. They should not have to. The better question is whether an agent can listen to many local languages, translate them into a common frame, and still tell us where the translation is imperfect.

The most trustworthy global catalog will not make the world look uniform. It will make the world's nonuniformity usable.