Commerce OS guide

Recommendations

Guide status: Operating-system guidance. Last reviewed 14 August 2026. Recommendation actions and decision-state labels must be checked against the version currently installed.

Purpose

Recommendations turns qualified evidence into reviewable proposals. A recommendation should explain the issue or possibility, show its evidence and limitations, define affected scope, describe the proposed change and make authority requirements explicit.

It is a decision object, not a promise of outcome. Approval means the merchant accepts a specified course of work within a specified boundary; it does not prove that execution completed or that the commercial result will be positive.

Before you begin

  • Resolve material source or storefront-health issues.
  • Confirm that the recommendation still applies to the current products, market, audience and placement.
  • Identify margin, inventory, brand, privacy and customer-experience constraints.
  • Know who owns the decision and who can publish or approve billed activity.

Review a recommendation

  1. Read the observation. Establish what was actually measured or detected.
  2. Read the reasoning. Identify assumptions and whether they are derived, inferred or experimental.
  3. Check scope. Review products, variants, audiences, placements, markets and time window.
  4. Check constraints. Confirm eligibility, inventory, margin, consent and brand requirements.
  5. Review the proposed action. Understand what will change, where and for how long.
  6. Review measurement. Confirm the primary measure, guardrails and end condition.

If a preview or impact estimate is available, treat it according to its evidence label. A modelled estimate is useful planning context but is not a realised result.

Choose the correct decision

Approve only when scope and authority are clear. Ask for revision when the underlying direction is useful but the proposal, evidence, guardrails or measurement needs work. Defer when timing or dependencies are unsuitable. Dismiss when the proposal should not return without materially different evidence, and record the reason.

Where Liva 7 supports preparation separately from publication, preserve that separation. A draft can be prepared without implying that it is live. Shopify-controlled publication, billing or permission steps remain merchant actions unless the installed integration explicitly and safely supports them.

Safe use and fallback

Do not execute when the intended item is unavailable, the target placement cannot be verified, the authority policy is missing, or evidence has materially changed since review. Retain the current storefront experience and return the recommendation to a reviewable state. High-risk and irreversible actions should default to Ask First.

You are finished when

  • the decision, reason, owner and time are recorded;
  • approved scope and limits are unambiguous;
  • execution and live verification are tracked separately; and
  • measurement or a safe stopping rule has been defined.