1. Treat AI as a review item generator
1.1 What AI can do
Place AI in the role of organizing, comparing, and flagging missing evidence. A merchant can provide already-approved product, cost, market, and promotion boundaries and ask AI to list a suggested price, the relevant market, missing fields, and approval questions. The output should remain a review record. It should not silently become a store fact.
AI can also help break a promotion rule into conditions, exceptions, scope, and recovery actions. That decomposition is useful because it exposes missing evidence: cost has not been confirmed, the target market is unclear, the currency context is not checked, the approver is not identified, or the old price was never recorded.
1.2 What AI cannot replace
AI cannot confirm the current cost, decide whether a price complies with the merchant’s policy, or treat an earlier suggestion as current market truth. It cannot supply a tax, returns, payments, privacy, or legal conclusion, and it cannot safely fill a missing amount or rate. Price, inventory, order, payment, market, and customer data must come from the real store and its stated policy.
Whenever a review item could lead to a price change, promotion publication, payment capture, refund, cancellation, purchasing action, or legal judgment, it must stop before human authorization. In this post, “automation” describes repeatable checks only; it does not mean that an externally consequential action is automatically executed.
2. Break pricing risk into four layers
2.1 Product layer: which item is changing
Identify the product and variant before discussing a price. Products and Product details are the official places in the source set to check the product record. The governance record should carry the approved product identifier, current price, any store-recorded cost field, variant relationship, and applicable policy. It should not infer those facts from AI prose.
If the review item does not point to one unambiguous product or variant, it does not enter approval. Similar names, a same-named item in another market, an old variant, or a draft record can send a correct-looking number to the wrong object. When identity is unclear, the fallback is to request product evidence, not to guess.
2.2 Margin layer: set the non-negotiable floor first
The margin floor comes from the merchant’s cost definition and approved policy. Internally, the team may calculate gross margin amount as review item selling price minus approved cost, then apply the store’s accepted margin-rate convention. This post does not prefill any amount, rate, or threshold. If cost, calculation convention, or the approved threshold is missing, the review item is unconfirmed review; AI must not fill the blank.
The floor check should answer three questions: does the suggested price meet the floor, does the result based on the real cost meet the minimum margin requirement, and does the price after the promotion still meet the floor? If a promotion has multiple conditions, review the least favorable rule combination that is still allowed by the review item. Keep the calculation inputs for human review.
2.3 Market layer: one rule does not mean one context
Use Markets to check the store’s current market context and Currencies for Markets to check the market-related currency setting. Markets, languages, currencies, taxes, returns, and payment processing are separate acceptance surfaces. A price that looks reasonable in one market does not prove that every other surface has passed.
If the market field is missing, currency display is inconsistent, the eligible region is unclear, or the local policy has not been referenced, the review item remains a draft. The reviewer must be able to answer “which market, which currency context, who is eligible, and who approved it,” rather than seeing only one number.
2.4 Authorization layer: who can release and recover
Approval is a control boundary, not a copywriting step. Each review item needs one or more human reviewers authorized under the store policy. The person who checks the margin convention may not be the person who validates market context. If authorization is missing, unavailable, or unsupported by evidence, the review item stays unpublished.
3. The price guardrail table: floor, margin, market, approval
3.1 Floor guardrail
The floor is a store-approved condition that a review item must not cross. It is not a number that AI should generate from a competitor, a trend, or a feeling. Record the floor’s source, the products it covers, the markets where it applies, and the approver. Without those fields, the floor cannot be audited.
3.2 Margin guardrail
The margin check uses the store-approved cost and calculation convention. If the current cost has not been confirmed, the review item cannot be marked as margin-approved. A promotion check must review the original price, the post-promotion price, and the conditions; checking only the visible label can miss the actual rule.
3.3 Market guardrail
The market guardrail lists market, language, currency, tax, returns, and payment processing as separate checks. Attach the Markets and Currencies for Markets review results to the review item record. “Passed” means that the current configuration and policy were reviewed by a human; it is not a promise about future configuration changes.
3.4 Approval guardrail
The approval guardrail identifies the evidence reviewed, the version approved, the reviewer’s decision, the time of approval, and the person who can trigger recovery if the review item fails. Role names and thresholds must come from the store’s policy; they must not be invented in an article or prompt.
| Guardrail | Evidence to record | Pass condition | Human approval | Failure fallback |
|---|---|---|---|---|
| Floor | Product/variant ID, approved floor, source, and version | Review item price is not below the approved floor | Store-authorized price reviewer | Stop the review item; restore the recorded old price or request evidence |
| Margin | Current cost convention, original price, post-promotion price, calculation inputs | Original and promotion results meet the approved margin floor | Authorized reviewer for the cost/margin convention | Withdraw the review item; preserve the calculation record; do not invent a number |
| Market | Target market, eligible audience, language and policy context | Market and exceptions are explicitly confirmed | Market operations or the policy-designated reviewer | Do not publish that market version; return to market checks |
| Currency | Markets context and Currencies for Markets review result | Relevant display and settlement currency conditions are accepted | Authorized market/payment reviewer | Pause the market promotion; recheck currency and payment conditions |
| Approval | Review item version, comments, approver, timestamp | Required roles approve the same version | Store-authorized approver | Keep unpublished; recover to the old version when required |
The table deliberately contains no amount or discount. “Not below” and “meets” must be instantiated with the merchant’s own policy and current data. That makes the guardrail executable without presenting an example as a universal threshold.
4. Build an evidence chain from Products to market context
4.1 Check the product record first
Keep product ID, variant, current price, and cost field in a “store fact” column, separate from an “AI suggestion” column. Store facts enter only from the current back office record or merchant-supplied evidence. AI suggestions carry a review status and a unconfirmed-review label. Product details are used for item-by-item verification; generated text is not product master data.
4.2 Record the promotion target and old price
Record the old price before reviewing a promotion. The record should let a reviewer identify the product, variant, target market, original-price version, review item rule, and approval state. The old price is the recovery anchor. It must not be reconstructed from memory after an error.
4.3 Check market and currency last
Save the Markets review separately from the Currencies for Markets review. For every target market, state whether the review item applies, which currency context is being used, and whether the store policy requires a human step. Taxes, returns, and payment processing do not pass automatically because the price table passed; they require their own acceptance checks.
| Evidence item | Input source | Reviewer question | State when not passed |
|---|---|---|---|
| Product and variant | Current Products / Product details record | Is the target unique and current? | BLOCKED: add product evidence |
| Current and old price | Current store record and recovery record | Can the pre-promotion state be reconstructed? | BLOCKED: do not publish |
| Cost and margin convention | Merchant-approved current data and policy | Are inputs complete and consistent? | REVIEW: do not fill by guesswork |
| Target market | Markets and merchant policy | Are scope and exceptions explicit? | BLOCKED: recheck market |
| Currency condition | Currencies for Markets and current configuration | Has the currency context been accepted? | BLOCKED: pause the market |
| Approval version | Human review record | Do comments refer to the same review version? | HOLD: wait for authorization |
5. Design an AI workflow that can be reviewed
5.1 Put confirmed fields in the input
The prompt or task form should separate “required facts,” “facts to confirm,” and “do not infer.” Required facts include product identity, current price, approved floor, cost convention, target market, currency context, and promotion conditions. The review-owner for every unconfirmed field should be named. Prohibited inferences include missing amounts, rates, legal conclusions, return or payment decisions, revenue claims, and automatic release.
A reusable task template is:
> You are a pricing and promotion review item organizer. Use only the store facts and policies I provide. Output: product/variant, old price, suggested price or rule, floor check, margin check, target market, currency context, missing evidence, risk notes, approval roles, and the steps to restore the old price if the review item fails. For any number not provided, write “to be confirmed.” Do not fill values and do not execute a change.
The template keeps AI in a structured organization role. The merchant still has to check whether the output faithfully represents the source record, especially where a model may confuse a product, market, or promotion condition.
5.2 Review the output one field at a time
Review identity first, then floor and margin, then market and currency, and finally approval and recovery. Do not skip evidence because the review item looks attractive. If AI rewrites, merges, or blurs a field, return to the original store record.
5.3 Save versions and reasons
Keep a version number, input snapshot, AI output, human edits, rejection reason, approver, and recovery anchor for each review item. Keep only the minimum information needed for governance. When customer data is involved, record purpose, consent/opt-out, retention, and deletion boundaries and follow the store policy. This post does not turn privacy settings into legal advice.
6. Review promotion rules at release handoff
6.1 Check the rule, not just the display copy
The review target is the rule itself: eligible products, eligible variants, target market, currency context, start and end conditions when the store policy requires them, discount conditions, exceptions, original price, and recovery version. This post does not prescribe an amount, discount, or time; the current store configuration and approved record supply those values.
6.2 Recheck original price, post-promotion price, and margin
The post-promotion price must return to the floor and margin checks. Do not validate only the promotion label or marketing copy. If stacking, exceptions, or scope cannot be reconstructed clearly by the reviewer, do not publish; split the rule into fields that can be checked.
6.3 Treat AI explanations as draft rationale
An AI-generated explanation of “why this price” is draft rationale only. Do not present a model estimate as market fact, an earnings promise, or a policy conclusion. The official AI best-practices guidance in the source set calls for review of AI-generated content; this post applies the same discipline to every field in a pricing or promotion review item.
7. Accept markets and currencies separately
7.1 Use Markets to validate scope
For every target market, confirm whether the review item should appear, whether there are market exceptions, and whether the merchant policy permits the rule. A pass in one market does not pass another. Bind the market context to the review version.
7.2 Use Currencies for Markets to validate currency conditions
Check the current market-to-currency context and the store’s acceptance result. Do not substitute a conversion table or an AI estimate for the live store configuration. Do not write an exchange rate, fee, or settlement conclusion without store evidence.
7.3 Review tax, returns, and payment separately
Tax, returns, and payment processing require separate review against current store configuration and policy. They are not boxes that the price guardrail can automatically check. If a rule could affect a refund, payment capture, or cancellation, route it to an authorized human; AI can only identify the follow-up.
8. Use an approval matrix and precise states
8.1 Use states instead of a vague “done”
Use states such as review item, evidence needed, human review, approved, rejected, and rolled back. These states describe the governance flow; they do not claim that Shopify has already executed a change. Only an authorized reviewer approving the same version can move the review item into the store’s prescribed release step.
8.2 Make approval traceable
The approval record should answer: which product and variant were checked; which cost and floor policy version was used; which market and currency conditions were reviewed; whether post-promotion margin was recalculated; which review version was approved; and where the old price can be recovered. If a key answer is missing, return to review.
8.3 Treat rejection as a normal fallback
Rejection is not an exception to hide. Unconfirmed cost, unclear market, unchecked currency, an unreconstructable rule, or a mismatch between AI output and store facts are valid rejection reasons. Preserve the reason so the next prompt or form can improve, but do not rewrite the rejection as a customer story.
9. Failed-promotion rollback rehearsal: an explicit test fixture
9.1 Fixture description
The following is a runbook/test fixture, not a customer case and not a production activity log. It uses missing fields and does not provide a real amount or discount:
- Product/variant: the test product and variant
- Recorded old price: the recorded old-price baseline
- Approved floor: the approved floor
- Approved minimum margin: the approved minimum margin
- Target market: the test market
- Currency context: the test currency context
- Review item promotion: the promotion rule in the fixture
- Authorized reviewer: AUTHORIZED_REVIEWER
- Failure trigger: the post-promotion result is below the floor, or the market/currency context differs from the approved record
The fixture tests whether an error is detected, publication is stopped, the old price can be located, and a human-authorized recovery can be carried out. It does not prove that a promotion works.
9.2 Rehearsal steps
- Register the product/variant, the recorded old-price baseline, the approved floor, the approved minimum margin, the test market, and the test currency context in the test record.
- Generate the promotion rule in the fixture using only fixture fields. Mark it for review and do not make a production change.
- Have the reviewer recalculate the post-promotion price and margin and check the target market and currency context.
- Inject one explicit failure: make the result fail the approved floor, or make the market/currency record differ from the approved context. Use symbols only; do not create an amount.
- Mark the review item rejected or recovery-required, freeze further release, and record the failure, version, and reviewer.
- Under the store’s authorization process, restore the recorded old-price baseline. A human confirms the action; AI does not initiate it.
- Recheck product, price, market, and currency records. Confirm that the recovered version matches the original baseline and record the result.
9.3 Pass criteria and rollback boundary
The minimum pass criteria are: the error is detected; the review item does not proceed; the old-price baseline is locatable; recovery is authorized; the recovered state is rechecked; and the record does not call the fixture a customer case. If any step fails, keep the review item unpublished and escalate to the store owner.
10. Release handoff checklist
10.1 Fact checklist
Confirm that the product and variant are unique; current and old prices are recorded; the cost convention and margin floor come from an approved store record; target market and currency context are checked; tax, returns, and payment processing are separately reviewed if affected; and every missing field is explicitly marked to be confirmed.
10.2 AI checklist
Confirm that AI generated a review item but did not execute an unauthorized price or promotion change; every number came from current store evidence or policy; estimates were not written as facts; no legal-compliance, earnings, or security guarantee was introduced; and the merchant reviewed and corrected the output.
10.3 Approval and recovery checklist
Confirm that the same review version has approval from the required authorized role; comments are traceable; the recorded old-price baseline or an equivalent old-version anchor is saved; failure triggers, stop actions, and the recovery owner are explicit; and the current store state will be rechecked at release handoff.
Multicurrency payment in Markets needs its own check: the currently supported path requires Shopify Payments or Adyen; other payment providers default to the store currency. Do not treat a multicurrency display as proof that settlement passed; record the provider, market eligibility, and currency conditions separately.
Frequently asked questions
FAQ 1: Can AI directly change a Shopify price?
This post does not treat AI as a direct price-change authority. Shopify Magic or Sidekick output may be wrong, so a merchant must review the review item against real product, cost, market, and policy evidence and follow the store’s authorization process. Whether to execute a price change is a store-control decision, not an automatic release from this article.
FAQ 2: What number should I use for the margin floor?
This post supplies no universal amount, rate, or percentage. The floor and minimum margin must come from the merchant’s approved cost convention and policy. If the cost, convention, or approval threshold is missing, keep the review item unconfirmed and do not ask AI to guess.
FAQ 3: If a promotion passes in one market, can I reuse it in other markets?
Do not assume that. Markets, languages, currencies, taxes, returns, and payment processing need separate acceptance, and Currencies for Markets must be checked against the current configuration. Each market needs an explicit scope, currency context, and approval record.
FAQ 4: What should happen first when a published promotion has the wrong price?
Stop further release or spread, lock the review version and failure reason, locate the previously recorded old price, and restore it through the store’s authorized process. Recheck product, margin, market, and currency after recovery. Do not reconstruct the old price from memory or ask AI to execute a refund, payment capture, or cancellation.
FAQ 5: Can an AI pricing suggestion be used as a compliance conclusion?
No. AI output is a review item or a risk prompt, not a legal conclusion or policy authorization. Tax, returns, payments, privacy, and legal issues must be reviewed separately against the current store configuration, stated policy, and authorized human judgment. This post offers no compliance guarantee.
Official sources and verification date
This post uses only the five official sources specified in the controller’s research brief. The source-pack verification date for each is 2026-08-30. Reopen and recheck the current pages and store configuration at release handoff:
Series links: marketing-content governance is Shopify AI Marketing Content: Ads, Email, and Brand Facts; demand and historical-data context is Shopify AI Demand Forecasting: Inventory, Markets, and Replenishment; the series extension is Shopify AI Privacy for Cross-Border Ecommerce: Data, Vendors, and Access. These links resolve to current-language article routes.