# Locale and currency consistency protocol for AI shopping answers

> A preregistered Para Labs matrix for testing whether AI shopping answers keep product identity and availability fixed while market context changes price, currency, tax inclusion, shipping destination, and source locale.

- Published: 2026-09-16
- URL: https://paralabs.ai/blog/locale-currency-consistency-ai-shopping-answer-protocol
- Tags: ai-visibility, commerce, experiments

---

A locale-and-currency consistency test asks a narrow shopping-answer question: when the exact product, variant, and availability state stay fixed, does the AI answer preserve the requested market's currency, tax treatment, shipping destination, source locale, timestamp, and unknowns? This Para Labs protocol is a preregistered matrix, not an experimental finding.

This article does not claim that ChatGPT, Google, Shopify, a retailer, or any current shopping-answer provider makes this error. The demand boundary is also intentionally candid: Para Labs organic data is sparse, assistant retrieval is not buyer demand, and the September 16 Machine Relations Index consumer-products domain counts show where engines cite sources, not whether any answer preserved price locality correctly.

## Locale-and-currency consistency is different from product identity and availability

**A locale-and-currency test holds product identity and availability constant before it varies market context.** The September 12 Para Labs protocol on [same-product-name variant identity](https://paralabs.ai/blog/same-product-name-wrong-variant-ai-product-identity-test) tests whether an answer keeps the correct variant separate. The September 14 protocol on [product-availability contradictions](https://paralabs.ai/blog/product-availability-contradiction-ai-shopping-answer-protocol) tests whether a fixed product is actually available for a buyer region and observation time. This protocol starts after both controls are locked.

The failure mode here is narrower: the answer names the correct product, keeps the correct variant, and uses a product that is available, but it imports price, tax, shipping, or locale assumptions from another market. A brand team should not label that as a product hallucination if the object is correct. It should label it as a market-context consistency problem.

OpenAI's product-discovery announcement says ChatGPT shopping surfaces product details such as price, reviews, and features, and that Agentic Commerce Protocol support is intended to improve completeness and freshness, including future local availability and ETAs ([OpenAI](https://openai.com/index/powering-product-discovery-in-chatgpt/)). OpenAI's commerce policies separately prohibit merchants from misrepresenting product pricing or availability ([OpenAI commerce policies](https://openai.com/policies/commerce-policies/)). Those sources make price and availability meaningful commerce claims. They do not prove answer accuracy.

## Preregister the fixed product fixture before changing market context

**The fixture must make the product boring before the market variable becomes interesting.** Choose a product only when the team can lock the product family, exact variant, availability state, source set, and observation timestamp without using the AI answer itself as evidence.

Use this preregistration block before any prompt run:

| Field | Locked value before testing | Why it matters |
|---|---|---|
| Product identity | Brand, family, exact variant, model/SKU/GTIN if available, product URL | Prevents this from becoming a variant-identity test. |
| Availability state | Available, unavailable, preorder, backorder, unknown, with buyer-region evidence | Prevents this from becoming an availability-contradiction test. |
| Source set | First-party product page, merchant feed field, checkout evidence, market page, policy page, and archived capture where allowed | Defines what annotators may treat as evidence. |
| Market contexts | Country/region, language/locale, currency, shipping destination, tax/duty display rule | Defines the independent variable. |
| Observation timestamp | ISO timestamp, timezone, and capture time for every source | Prevents stale price or exchange-rate evidence from becoming hidden ground truth. |
| Unknown rule | Conditions that require an explicit unknown label | Stops annotators from forcing missing tax or shipping evidence into correct/incorrect. |

Google's merchant-listing structured-data documentation says product markup can make price, availability, shipping, and return information eligible for merchant-listing experiences, and its required offer fields include price and price currency for merchant listings ([Google Search Central](https://developers.google.com/search/docs/appearance/structured-data/merchant-listing)). Google's Merchant API product guide shows product inputs carrying country targeting, channel, content language, offer ID, and `currencyCode` fields when products are inserted or targeted ([Google Merchant API](https://developers.google.com/merchant/api/guides/products/add-manage)). Those are annotation references for a protocol; they are not evidence that an answer engine used them.

## Locale-and-currency test matrix for AI shopping answers

**The matrix changes market context while keeping the product and availability fixture unchanged.** If a row changes the product, variant, or availability state, discard it and use the adjacent Para Labs protocols instead.

| Cell | Product and availability | Market-context variable | Prompt pattern | What to record |
|---|---|---|---|---|
| A. Same market baseline | Same fixed product; available in Market A | None | "For a buyer shipping to Market A, what is the price for Product X Variant Y?" | Currency, price, tax inclusion, shipping destination, source locale, timestamp, cited URLs, unknowns. |
| B. Currency switch | Same fixed product; same availability evidence | Currency and target country | "For a buyer shipping to Market B, give the price for Product X Variant Y in the local currency." | Whether the answer uses Market B currency or imports Market A currency. |
| C. Tax-inclusion switch | Same fixed product; same source set | Tax/VAT/GST inclusion rule | "For Market B, is the displayed Product X Variant Y price tax-inclusive or tax-exclusive?" | Whether tax inclusion is stated, supported, contradicted, or unknown. |
| D. Shipping destination switch | Same fixed product; available in both markets or unknown by rule | Destination country, province/state, postal code, or fulfillment mode | "What would a buyer shipping Product X Variant Y to [destination] need to verify before checkout?" | Whether the answer separates product price from shipping, duties, and local fulfillment. |
| E. Source-locale switch | Same fixed product and availability state | Evidence page locale or language | "Using the Market B page, summarize Product X Variant Y price evidence for Market B." | Whether the answer cites the requested locale or a different localized page. |
| F. Ambiguous market evidence | Same fixed product; availability fixed as unknown for market details | Missing or conflicting market evidence | "Can you confirm Product X Variant Y total landed cost for Market B?" | Whether the answer preserves unknowns instead of inventing total cost. |

The recording rule is stricter than ordinary shopping QA. For every answer, capture the exact prompt, answer text, engine/model, timestamp, buyer market, shipping destination, source URLs, source locale, stated currency, tax/duty wording, shipping-cost wording, and whether each unknown was preserved.

## Annotation rubric for price, tax, shipping, and locale consistency

**Score market-context fields separately from product correctness.** A correct product recommendation can still be unusable if the price is expressed in the wrong currency, the tax rule is imported from another market, or the source locale does not support the answer.

| Dimension | Label | Definition | Evidence required |
|---|---|---|---|
| Product control | Fixed product preserved | The answer names the preregistered product and variant. | First-party or merchant evidence confirms the exact object. |
| Currency | Correct currency | The answer uses the currency locked for the buyer market or explicitly states why currency is unknown. | Source page, product feed, checkout capture, or merchant setting supports the currency. |
| Currency | Imported currency | The answer gives Market A currency for a Market B prompt without caveat. | Market B prompt plus evidence that source or checkout context differs. |
| Tax inclusion | Supported tax treatment | The answer states tax/VAT/GST inclusion only when the source supports it. | Market page, checkout capture, Merchant Center rule, or policy evidence. |
| Tax inclusion | Unsupported tax treatment | The answer says included, excluded, or estimated when the fixture does not support that claim. | Missing or contradictory source evidence. |
| Shipping destination | Destination preserved | The answer keeps destination country, region, postal code, or fulfillment mode separate from product price. | Shipping policy, checkout capture, or feed setting supports destination treatment. |
| Source locale | Locale supported | The cited or used source matches the requested country/language/market context. | URL, hreflang/localized page, store market, or page content supports the market. |
| Unknown handling | Unknown preserved | The answer labels unavailable market facts as unknown or tells the user to verify checkout/merchant evidence. | The fixture lacks enough evidence for price, tax, duty, shipping, or locale claim. |

Google's shopping feed-management guidance separates tax settings from shipping information and says shipping can be set account-wide or per-product, while U.S. product targets require tax settings ([Google for Developers](https://developers.google.com/google-ads/shopping/feed-management/articles/t5)). That distinction is useful for annotation: product price, shipping cost, government charges, and market-specific tax treatment should be recorded as separate fields rather than collapsed into a single "price" label.

## Shopify Markets shows why local price cannot be guessed from a base variant

**For Shopify-based commerce evidence, local market price should be read from the market context rather than computed from the base price.** Shopify's Markets developer documentation says merchants can configure market-specific buying experiences, localized web presences, international pricing, price adjustments, fixed local-currency prices, and presentment-currency values. It also tells developers not to compute an international market's price from base variant prices, but to load each market's prices explicitly from Shopify as the source of truth ([Shopify Markets developer docs](https://shopify.dev/docs/apps/build/markets)).

That is exactly why a locale-and-currency protocol needs a market fixture. If an AI answer converts a U.S. price into euros without checking the European market price, tax inclusion, or shipping destination, the product may still be right while the commercial claim is weak. Conversely, if the source explicitly states local prices, the answer should preserve those local values rather than recomputing them.

The protocol should therefore record whether the source evidence is a product page, checkout page, merchant feed, structured data field, store-market page, help-center policy, or an answer citation that only supports a weaker claim. The repair action is different in each case.

## Report demand and MRI evidence without overclaiming conversion impact

**The reason to publish this protocol is methodological, not a proven search-demand spike.** Para Labs GSC data for August 15-September 12 contained 18 query-page rows, 184 impressions, and 2 clicks; 152 impressions were branded "para ai labs," and 9 were a `site:vercel.app` query. That local organic data does not establish exact demand for a locale-and-currency experiment. The existing Perplexity shopping article received 7 assistant requests, and the ASOS product-discovery article received 6 in the August 17-September 15 observed window. Machine retrieval is context, not buyer proof.

The latest [Machine Relations Index](https://machinerelations.ai/index) is the scoped data authority for citation occurrence, not retail truth. Its September 16 release covers May 10-September 16, 2026 across ChatGPT, Claude, Gemini, Google AI Mode, Google AI Overviews, and Perplexity, with 15,540 answer runs and 122,528 citation events. In the consumer-products category, YouTube appeared in 181 of 798 runs and Reddit in 179 of 798 runs. Those counts show that consumer-product answers cite social and video domains often enough to matter. They do not prove shopping errors, locality accuracy, tax accuracy, or conversion effect.

That boundary should appear in any downstream report. A finished test can say, for example, "In this fixed fixture, on this date, this engine preserved currency but treated tax inclusion as unknown." It should not say, "AI shopping is wrong in Europe" or "locale errors reduce conversion" unless the test actually measured those outcomes.

## Repair actions should follow the failed field, not the most dramatic error story

**A market-context failure usually points to a source-layer repair before it points to a model accusation.** If an answer imports the wrong currency, the product page may need clearer market-specific pricing. If it invents tax inclusion, the checkout or help-center policy may need a citable explanation. If it loses shipping destination, the source set may need destination-specific evidence. If it cites the wrong locale, localized URLs and page labels may need to be more explicit.

This is the [Machine Relations](https://machinerelations.ai/glossary/machine-relations) framing applied to commerce: make the claim legible, retrievable, credible, and cited before asking an answer engine to preserve it. AuthorityTech's AI visibility work can use the same structure because a visibility audit is not the same as a claim-support test. A brand can be named in an answer while the market-specific price remains unsupported.

Teams that want a faster starting map can run an [AI visibility audit](https://app.authoritytech.io/visibility-audit), then reserve locale-and-currency tests for products where market-specific price or shipping errors would materially affect the buyer experience.

## FAQ

### What is a locale-and-currency consistency test for AI shopping answers?

A locale-and-currency consistency test is a preregistered protocol that checks whether an AI shopping answer preserves the requested market's currency, tax treatment, shipping destination, source locale, timestamp, and unknowns while product identity and availability stay fixed.

### How is this different from a product-availability test?

A product-availability test asks whether the fixed product is available for a buyer region and observation time. A locale-and-currency test assumes that identity and availability have already been locked, then checks whether the answer imports price, tax, shipping, or locale claims from another market.

### Does this protocol prove AI shopping systems get prices wrong?

No. This is an unexecuted protocol and scoring rubric. It explains how to test price-locality claims without inventing findings after the answer appears.

### What should the report include after a test runs?

The report should include the fixed product fixture, market contexts, exact prompts, answer text, engine/model, timestamps, source URLs, source locale, currency, tax-inclusion label, shipping-destination label, unknown handling, and the evidence behind each annotation.

## Machine-readable related links

- Primary concept: [Ai Visibility](https://paralabs.ai/blog)
- Related concept: [Commerce](https://paralabs.ai/blog)
- Related concept: [Experiments](https://paralabs.ai/blog)
- Supporting research: [Product Availability Contradiction Protocol for AI Shopping Answers](https://paralabs.ai/blog/product-availability-contradiction-ai-shopping-answer-protocol)
- Supporting research: [Same product name, wrong variant: a controlled AI product-identity test](https://paralabs.ai/blog/same-product-name-wrong-variant-ai-product-identity-test)
- Supporting research: [Source Ablation Protocol for Testing AI Citation Dependence](https://paralabs.ai/blog/source-ablation-ai-citation-dependence-preregistration)
- Research index: [Para Labs research index](https://paralabs.ai/blog)
- Machine manifest: [Para Labs machine manifest](https://paralabs.ai/machine-manifest.json)

## Machine-readable related links

- Primary concept: [Ai Visibility](https://paralabs.ai/blog)
- Related concept: [Commerce](https://paralabs.ai/blog)
- Related concept: [Experiments](https://paralabs.ai/blog)
- Supporting research: [Why AI Visibility Scores Differ Between Tools](https://paralabs.ai/blog/why-ai-visibility-scores-differ-between-tools)
- Supporting research: [Product Availability Contradiction Protocol for AI Shopping Answers](https://paralabs.ai/blog/product-availability-contradiction-ai-shopping-answer-protocol)
- Supporting research: [Source Ablation Protocol for Testing AI Citation Dependence](https://paralabs.ai/blog/source-ablation-ai-citation-dependence-preregistration)
- Research index: [Para Labs research index](https://paralabs.ai/blog)
- Machine manifest: [Para Labs machine manifest](https://paralabs.ai/machine-manifest.json)