Merchandising

Merchandising is how your storefront sells: pulling the right products, reference material, and policy together to answer a buyer brief. It is the how of selling, distinct from a product, which is what gets sold. Your Merchandising Agent does the selling; merchandising is the configuration it sells by. Four surfaces steer it. Each owns a different kind of fact, and all four are authored the same two ways — in chat with Murph, or in a portable Page you can open from any MCP Apps host. Selling terms and approval settings share the Selling Terms Page; acceptance policy and merchandising rules each have their own. Two more surfaces sit next to these and are configured separately: per-buyer terms live in buyer instructions and buyer discounts, and the markets you operate in live in your Business Profile.

​

One fact, one owner

Each fact has exactly one place it can be written. This is not a style preference — a merchandising-rules version that restates a price, a discount, a market, or an acceptance rule is rejected on save, and you are told which surface owns it. The reason is drift. Merchandising rules are prose your agent reads; selling terms are structured numbers the pricing engine enforces. If a $25 floor lived in both, the two would eventually disagree and the agent would have to choose between them mid-negotiation. So rules may refer to your terms, profile, or policy — “lead with premium packages”, “pricing follows selling terms” — but they may not restate their facts. If a rules version you saved earlier does contain such a fact, it stays readable and returns an ownershipIssues list naming the conflict. While that version is active, the conflicting lines are omitted from the copy your agent reads, and the structured surface stays authoritative. You cannot re-activate a flagged version; you save a cleaned-up one instead.

​

Versions and activation

Acceptance policy and merchandising rules are versioned and immutable. Saving never overwrites: it appends a new version and points your storefront at it. Exactly one version is active at a time, and that is the one your Merchandising Agent reads on its next composition. A version that has been saved but not activated has no effect at all. Activation is what puts a document to work, so the ordinary path is save and activate in one step — your version history never contains a half-applied update. Earlier versions remain readable for audit, and the Page lets you preview one, restore it, or reuse it as the starting point for a new version. Selling terms and approval settings are not versioned. A save takes effect immediately.

​

What changes when you save

Merchandising configuration is not inert — each surface changes what your storefront does on the next buyer request.

• Selling terms change the quote. Floors marked hard_floor are never crossed; a proposal composed after the save uses the new anchors.
• Merchandising rules change what gets offered and how it is described. The active version is read on the next composition.
• Acceptance policy changes what clears without you. With mediaBuyApproval: manual and no active policy, nothing pre-clears — every buy is held for you. Activating a policy is what lets the clearly-on-policy subset forward on its own.
• Approval settings change whether the policy is consulted at all. In auto mode the gate is skipped entirely: every buy forwards and nothing is evaluated. Moving a setting to auto is the single largest change you can make here, so treat it as a decision rather than a tweak.

​

Reading your current configuration

Every surface is readable before and after you change it:

• Ask Murph, or open the surface’s Page, to see the current document.
• GET /api/v2/storefront returns compositionPricing, creativeApproval, and mediaBuyApproval.
• The acceptance-policy and operating-instructions endpoints return the active version, the full version history, and each version’s ownershipIssues.

​

Next steps