Nothing goes live until a real cart agrees.

One publish call starts a durable workflow on the store. It runs these steps in order:

1. Create the Shopify discount codes for options that use one.
2. Rewrite the option maps the discount function reads at checkout.
3. Write the cart transform's map, where an option needs it and the store has registered the transform.
4. Build a real Storefront cart for every visible option, plus the no-pointer, forged-pointer, landing-page and free-shipping checks, and, for subscription options, read the renewals discount that prices every later billing cycle.
5. Go live, but only if every visible option matched.

Offer Suite creates no order tags and no gift products: a gift is a product the store already sells, priced to $0 at checkout. Over MCP, publish_offer needs confirm: true and refuses without it. Over the API, the POST /offers/{id}/publish call is the approval. Each run can be read back with get_publish_run.

The verifier builds each option's cart on the store's own Storefront API, reads what Shopify charged and abandons the cart. It compares each line with the offer document and prices the expectation with the same line-pricing module the buy box's prices come from.

A version goes live, or becomes a verified experiment arm, only if every visible option is matched. Otherwise it stays a draft and the live version keeps selling.

Shopify can take about 10 seconds to apply a new map, so a mismatch is checked again after 10, 20 and 40 seconds before it counts.

The theme block, through the SDK build it bundles, refuses to sell an option whose latest real-cart check did not match. Other selections are priced by the same line-pricing module the check uses.

The offer's pointer rides on the cart as an attribute, and any storefront script can write one. So the discount function and the cart transform trust it only as far as the cart backs it up:

• An option's price, gifts and free shipping apply only when the cart holds its required lines, in enough units, bought the same way (subscription or one-time), and never to more units than the option sells.
• A gift is zeroed only up to the units the option includes.
• Free shipping applies to shipping rates only, never to pickup or local delivery, and the store's shipping settings are never changed.
• On a subscription, the first charge is priced by the "Offer Suite" app discount, which applies once. Recurring discounts and every-shipment free shipping sit on "Offer Suite renewals", which Shopify saves on the subscription contract for every billing cycle.
• When the order arrives, a line role the shopper wrote counts only when the published offer gives that product that role, so a paid line cannot be costed as a gift.

Limits, stated plainly. Category-builder options have no required lines, so any cart that carries a builder's pointer gets the builder's own capped price. The check proves which lines the cart holds, not which option or experiment arm the shopper was shown: a shopper can apply another option's or arm's pointer when the cart already holds that option's lines.

The option map is compacted and sharded over five metafields, each kept under Shopify's 10,000-byte input limit. That is room for a few hundred simple options per store, fewer for large builders or entries that name many variants.

A publish is refused up front if it would push a shard past the limit, or if the measured instruction budget says it would leave room for fewer than 10 priced cart lines within Shopify's limit. The refusal names the cause, so a brand retires offers instead of finding out at checkout that a cart was charged list price.

The dev store's own map holds every test offer published there, large category builders among them, so it runs fuller than a single offer's would. It is measured in the evidence below.

• Re-verify on demand with POST /offers/{id}/verify, the MCP tool verify_offer or the dashboard's Re-verify button. Only the live version can be verified; any other answers 409 not_live.
• Every day, each store's app discounts and option maps are checked and rebuilt in place if they are missing or out of date, with no republish and no change to any offer. A discount someone deactivated, or a map too large to write, is reported, not fixed.
• On the same run, the two live offers per store verified least recently are checked again on real carts, so every live offer comes round again in turn (a store with ten live offers, every five days). A red experiment arm pauses its experiment.
• When a store's pricing status changes, every team member gets one email when it breaks and one when it is fixed. The alert names the offer, the option and the cart checks that failed.
• Rebuild by hand with POST /stores/{id}/pricing (rebuild_store_pricing): the same check and rebuild, run now.
• The dashboard and Shopify App Home show each store's pricing status and when it was last checked.

Read from the dev API: the last publish of OF_DEV_KITS on the dev store, then the latest real-cart check of each of its options. They are two events, dated apart.

• Free shipping can be verified only in US markets, where the verifier has a delivery address. Elsewhere the check is skipped, so a version with free shipping is not published.
• Renewals are checked against the selling plan and the renewals discount's configuration, not against an observed renewal charge.
• The verifier proves each option's default cart, not every selection a shopper can make.
• Rebuilding a store's pricing is API and MCP only. The dashboard has Re-verify; App Home shows the pricing status.