Same product name, wrong variant: a controlled AI product-identity test

Product-identity testing should separate a product family from its variants before a team treats an AI answer as usable evidence. This Para Labs protocol gives catalog and product marketing teams a controlled way to test whether an answer names the correct variant, blends specifications, leaves identity unresolved, or cites a source that does not support the claim.

This is an unexecuted lab protocol. It is not a claim that a current AI platform confuses variants, that a vendor feed requires a specific field, or that product-shopping demand has been validated. The originating organic signal for this angle is thin: three Search Console rows, seven impressions, and zero clicks in the observed lane window. The value here is the test design, not proof of market demand.

Product variant identity needs a smaller test than product discovery

A product-discovery article asks whether a brand or product can enter an answer surface. A product-variant test asks a narrower question: when the product family is already held constant, can the answer keep the exact variant, market, and comparison frame straight?

That boundary matters because the existing Para Labs product-discovery page already owns the broader feed and shopping-visibility explanation: OpenAI's product-feed path turns ChatGPT shopping visibility into a source architecture problem. This protocol should not repeat that page. It should sit one layer downstream, where the brand team needs to know whether the answer is using the right SKU, edition, bundle, market, generation, or package size.

Use the protocol when two or more variants can plausibly be confused because they share a family name. Examples can be hypothetical: "Model X Standard" versus "Model X Pro," a U.S. edition versus a U.K. edition, a 2025 bundle versus a 2026 bundle, or a software plan whose limits changed by market. The fixture should be built from the team's own current catalog and approved source set, not from assumptions about any one AI system.

Product variant test design: hold the family constant and vary one identity factor

The controlled variable is product identity, not brand preference. Keep the family name stable across prompts, then change one identity factor at a time: variant identifier, market, comparison phrasing, or source context.

A clean fixture needs four inputs:

1. Canonical product-family name. The shared family label that appears across variants.
2. Variant identifiers. Model number, plan name, edition, generation, bundle, size, or SKU-level phrase.
3. Market boundary. Country, region, channel, language, audience, or availability boundary if the product differs by market.
4. Approved source set. Product page, help article, spec sheet, release note, price sheet, third-party review, or other page the team is willing to treat as evidence.

Do not start by asking whether the answer is flattering. Start by asking whether the answer resolved the object. An answer can sound helpful and still be unusable if it compares the right product family but the wrong variant.

Public catalog standards already show why this distinction is concrete. Schema.org defines ProductGroup as a way to represent a group of product variants and ProductModel as a model-level product description. GS1 describes the Global Trade Item Number as an identifier for trade items in the global supply chain. Google Search Central's product variant structured data documentation explains product groups and variants for Search markup. OpenAI's Agentic Commerce product-feed specification is another example of product data being represented as structured input. Those sources are cited only to ground the catalog-identity problem; this protocol does not claim that any current AI-shopping system behaves a certain way in response to them.

Same product name test matrix

The matrix below is a starter design. Replace the hypothetical product labels with real catalog fixtures before running the test.

Test cell	Held constant	Variable changed	Example prompt pattern	Identity risk being tested
A. Variant-specific comparison	Product family	Variant identifier	"Compare Product X Pro with Product X Standard for a small team."	The answer describes the family but blends Pro and Standard specifications.
B. Market-specific variant	Product family and variant	Market	"Is Product X Pro in the U.K. the same as Product X Pro in the U.S.?"	The answer imports U.S. features, price, or availability into the U.K. variant.
C. Generation-specific variant	Product family	Generation or year	"What changed between Product X 2025 and Product X 2026?"	The answer treats a retired or older variant as current.
D. Bundle or plan boundary	Product family	Bundle, package, or plan	"Does Product X Team include the same limits as Product X Enterprise?"	The answer merges limits from two commercial packages.
E. Source-constrained answer	Product family and variant	Cited source	"Using only the cited source, what does Product X Pro include?"	The source supports the family but not the specific variant claim.
F. Ambiguity check	Product family only	No variant supplied	"What is Product X best for?"	The answer should ask for a variant or state that the variant is unresolved.

The goal is not to create a gotcha prompt. The goal is repeatability. Each row should be run against the same approved source fixture, recorded with the exact answer text, cited URLs, date, market, and model or engine configuration where the team is allowed to record it.

Annotation rubric for variant identity errors

Annotators should score identity before persuasion. A recommendation is not valid if it cannot keep the object of the recommendation stable.

Label	Definition	Minimum evidence to assign it	Action for the product or catalog team
Correct variant	The answer names the intended variant and uses attributes that match approved sources for that variant.	The cited or approved source supports the variant name, market, and material specifications used in the answer.	Preserve the source path; consider making the variant distinction more extractable.
Blended specifications	The answer names one variant but imports attributes, limits, pricing, or availability from another variant.	At least one material attribute belongs to a sibling variant, older generation, different bundle, or different market.	Rewrite product and comparison sources so variant differences are tabular and explicit.
Unresolved identity	The answer discusses the product family but does not resolve which variant is being described.	The answer uses family-level language where the prompt or source fixture requires variant-level specificity.	Add disambiguation language, variant IDs, and "not the same as" comparison blocks.
Source mismatch	The answer cites or relies on a source that does not support the specific variant claim.	The cited page discusses the family, a different variant, or a dated version but not the asserted variant fact.	Repair citations, update source pages, or mark the claim as unsupported until corroborated.

A fifth operational label can be useful: not enough information. Use it when the fixture itself does not provide enough evidence to decide. That label protects the team from blaming the answer system for a catalog problem the company has not made machine-readable.

Product catalog sources should expose differences, not just names

Variant identity improves when sources state differences in a way machines and humans can reuse. The most useful source block is not a marketing paragraph. It is a compact comparison that includes the family name, each variant identifier, market scope, currentness date, material differences, and sources for claims.

For a product marketing team, that means the same canonical facts should appear across the product page, support page, spec sheet, comparison page, and external coverage where applicable. Contradictions do not become harmless because they are small. If one page says "Standard" and another says "Starter," or if a regional page omits the market boundary, an answer can preserve the family name while losing the variant.

This is where Machine Relations gives the protocol a broader frame. Machine Relations is the discipline of making brands legible, retrievable, credible, and cited across AI-mediated discovery systems. For catalog teams, variant identity is a legibility problem before it becomes a recommendation problem.

The September 12 Machine Relations Research release on source-layer baselines is useful here only as a methodological analogy. It argues for separating answer presence, mention rate, cited-source share, retrieval state, and source quality instead of collapsing them into one score. A product-variant protocol should do the same kind of denominator discipline: separate family recognition from variant correctness, source support, and market fit.

That research does not prove product-variant behavior. It simply shows why disciplined measurement avoids false confidence when different evidence layers are blended.

How to run the product identity protocol without overclaiming

Before any public or executive report, lock the limits of the test:

1. State the fixture. Identify the product family, variants, markets, and approved source URLs used.
2. State the non-finding. If the test has not run, call it a protocol. If it ran on one engine or one date, do not generalize beyond that engine, date, and configuration.
3. Separate result labels. Report correct variant, blended specifications, unresolved identity, and source mismatch as separate rates or counts.
4. Preserve answer evidence. Store the exact prompt, answer, cited sources, timestamp, and annotator note.
5. Assign the repair owner. A blended answer may point to a source gap, a catalog naming gap, a documentation conflict, or an answer-generation error. Do not collapse those causes.

For teams using AuthorityTech or related AI visibility audits, the same rule applies: a visibility score is not a substitute for object-level evidence. A brand can appear in an answer while the wrong variant is described. That is why a product identity test belongs beside discovery measurement, not underneath it.

FAQ

What is a product variant identity test?

A product variant identity test is a controlled prompt-and-source protocol that checks whether an AI answer keeps the correct SKU, plan, edition, generation, bundle, or market variant separate from the broader product family. It measures identity resolution before judging whether the answer is useful or persuasive.

Is this evidence that AI shopping systems confuse product variants?

No. This article is an unexecuted protocol, not an empirical finding about current AI shopping systems. It describes how a team should test variant identity if it has a product family where similarly named variants could be blended.

How is this different from product feed optimization?

Product feed optimization focuses on making product data eligible and parseable. This protocol focuses on whether an answer preserves the exact variant identity when family name, market, comparison phrasing, and source context change. It complements feed work without claiming any specific platform requirement.

What should a product marketing team fix first if variants are blended?

Fix the source layer before blaming the answer. Add explicit variant identifiers, market boundaries, comparison tables, currentness dates, and source-backed claims so both humans and AI systems can tell which product variant each statement describes.