> ## Documentation Index > Fetch the complete documentation index at: https://docs.interchange.io/llms.txt > Use this file to discover all available pages before exploring further. # Media Kit, Playbook, and Business Rules > The three seller Pages that steer your storefront, what each one owns, and how to read or update it from chat, MCP Apps, and the v3 agent surface. There is no separate `merchandising` document. **Merchandising is what your storefront *does*** — the [Merchandising Agent](/v2/concepts/merchandising-agent) selling on your behalf — not a thing you save. Three nouns steer it, split by what kind of fact each one holds: | Noun | Kind | Owns | | ---------------- | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | `media_kit` | material — what buyers see | Resolved identity (brand name, logo, membership badge), the authored story (summary, footprint, channels, regions, verticals, evidence links) | | `playbook` | judgment — how you sell | Value-anchor pricing facts (floor/target/ceiling per condition), posture, packaging and selection guidance | | `business_rules` | constraint — what you accept | The acceptance policy, and the two approval gates (`creativeApproval`, `mediaBuyApproval`) | The Page names and read tools now use the same three nouns. **Selling Terms** is retired: structured prices and floors moved to Playbook, while approval gates moved to Business Rules. **Business Profile** became Media Kit and **Merchandising Rules** became Playbook. Your saved configuration and version history do not move or reset. In chat and any MCP Apps host, `get_media_kit`, `get_playbook`, and `get_business_rules` open the portable Pages. `/mcp/v3` remains a gated preview. The `get` and `save_*` examples below apply only to that surface; the `get_media_kit`, `get_playbook`, and `get_business_rules` Pages are available through the current seller MCP surface. ## One fact, one owner Playbook instruction content cannot duplicate structured Playbook pricing, Buyer Discounts, Media Kit facts, or Business Rules. It may refer to those facts without restating them. A conflicting version is rejected on save rather than left for the agent to reconcile later. Business Rules separates two decisions: approval gates decide whether human review runs, and the acceptance policy classifies what is on policy when review is enabled. With `mediaBuyApproval: manual` and no active policy, every media buy is held for review. Media Kit and Playbook guide what the agent presents and how it sells; neither controls the review gate. ## Reading a noun: `get` takes no id `media_kit`, `playbook`, and `business_rules` are singletons — exactly one per storefront — so `get` identifies them by `kind` alone. Passing an `id` for any of these three is a validation error. ```json theme={null} { "kind": "business_rules" } ``` ```json theme={null} { "kind": "playbook", "include": ["versions"] } ``` `include: ["versions"]` adds the full version history for `playbook` and `business_rules` (an array of `{ version, isActive, notes, createdAt }`); omit it and `get` returns only what is currently active. There is no separate "list versions" tool — version history is an `include`, the same way source diagnostics are. ## `media_kit` — what buyers see `save_media_kit` writes your authored story: a summary, channel and region footprint, verticals, and the evidence links it was sourced from. Omitted fields are left unchanged. ```json theme={null} { "summary": "Regional lifestyle and news network reaching auto intenders across the Southeast US.", "propertyCount": 42, "channels": ["display", "ctv"], "regions": ["US"], "verticals": ["news", "lifestyle", "automotive"], "evidenceUrls": ["https://example-media-group.com/advertise/media-kit-2026.pdf"], "notes": "Extracted from the 2026 media kit; property count is an estimate." } ``` ```json theme={null} { "mediaKit": { "identity": { "brandName": "Example Media Group", "logoUrl": "https://cdn.example.com/logos/example-media-group.png", "logoBackground": "dark-bg", "membershipStatus": "AAO_MEMBER" }, "profile": { "summary": "Regional lifestyle and news network reaching auto intenders across the Southeast US.", "propertyCount": 42, "channels": ["display", "ctv"], "regions": ["US"], "verticals": ["news", "lifestyle", "automotive"], "evidenceUrls": ["https://example-media-group.com/advertise/media-kit-2026.pdf"], "notes": "Extracted from the 2026 media kit; property count is an estimate." } } } ``` `identity` is **read-only**: brand name, logo, logo background, and membership badge are resolved from your registered brand identity, and `save_media_kit` has no fields for them. **What the kit can show today, and what it can't yet.** Brand name, logo, logo background, and membership status are the only resolved-identity fields a seller's own read exposes. Your brand colours exist and are already shown to buyers and join-link visitors — but not back to you here, an asymmetry we know about rather than a design choice. Fonts, tagline, audience/reach figures, case studies, and tentpoles aren't captured anywhere yet. There is also no price list of product templates on this noun yet — `media_kit` is its planned home, but no tool writes one today, so don't expect `save_media_kit` to accept prices. ## `playbook` — how you sell `save_playbook` has two independent halves you can send together or apart: `content` (posture and packaging guidance, versioned) and `pricing` (your value-anchor facts). ```json theme={null} { "content": "## Posture\nLead with premium CTV before offering display discounts. Hold value on flagship inventory during Q4.\n\n## Packaging\nBundle CTV pre-roll with display when a brief mentions video.", "notes": "Initial playbook, drafted from the Q4 sales deck.", "pricing": { "currency": "USD", "facts": [ { "id": "ctv-flagship", "label": "CTV flagship pre-roll", "appliesWhen": "Buyer requests CTV pre-roll on flagship shows", "pricingModel": "cpm", "targetPrice": 42, "floorPrice": 32, "strength": "hard_floor", "provenance": "2026 rate card, page 4" } ] } } ``` ```json theme={null} { "playbook": { "active": { "version": 3, "content": "## Posture\nLead with premium CTV before offering display discounts. Hold value on flagship inventory during Q4.\n\n## Packaging\nBundle CTV pre-roll with display when a brief mentions video.", "notes": "Initial playbook, drafted from the Q4 sales deck.", "createdAt": "2026-07-28T15:04:00Z", "ownershipIssues": [] }, "pricing": { "currency": "USD", "facts": [ { "id": "ctv-flagship", "label": "CTV flagship pre-roll", "appliesWhen": "Buyer requests CTV pre-roll on flagship shows", "pricing": { "pricingModel": "cpm", "currency": "USD", "targetPrice": 42, "floorPrice": 32 }, "strength": "hard_floor", "provenance": "2026 rate card, page 4" } ] } }, "createdVersion": 3, "replacedVersion": 2 } ``` `ownershipIssues` identifies any line in the active guidance that duplicates structured Playbook pricing, Buyer Discounts, Media Kit facts, or Business Rules. `pricing.facts` **replaces the whole list** — a fact you don't repeat in the request is removed, the same "whole document" semantics as `content`. ## `business_rules` — what you accept `save_business_rules` also has two independent halves: `content` (your acceptance policy, versioned) and the two approval gates. ```json theme={null} { "content": "## Acceptance policy\nWe do not accept gambling, tobacco, or political advertisers. Fast-food advertisers require review before their creative goes live.", "notes": "Adds a review requirement for fast-food advertisers." } ``` ```json theme={null} { "businessRules": { "creativeApproval": "manual", "mediaBuyApproval": "manual", "policy": { "version": 5, "content": "## Acceptance policy\nWe do not accept gambling, tobacco, or political advertisers. Fast-food advertisers require review before their creative goes live.", "notes": "Adds a review requirement for fast-food advertisers.", "createdAt": "2026-07-28T15:10:00Z" } }, "createdVersion": 5, "replacedVersion": 4 } ``` ### Turning off human review Moving `creativeApproval` or `mediaBuyApproval` to `auto` needs `acknowledgeNoHumanReview: true` on the same call: ```json theme={null} { "mediaBuyApproval": "auto", "acknowledgeNoHumanReview": true } ``` Leave it out and the save fails with a validation error rather than a silent no-op: ``` Moving media buys to `auto` means nobody reviews them, and your acceptance policy is no longer consulted for media buys. Pass acknowledgeNoHumanReview: true to proceed. ``` **`auto` doesn't relax your acceptance policy — it skips it.** The gate that decides whether a media buy needs review is checked *before* the policy runs. With `mediaBuyApproval: auto`, every buy forwards and the active acceptance policy is never consulted at all — not "the policy allows it," but "the policy doesn't run." With `mediaBuyApproval: manual` and no active policy, the opposite happens: nothing pre-clears and every buy is held for you. Activating a policy is what lets the clearly-on-policy subset forward on its own while you stay in `manual`. ## Every save is create-and-activate — there's no separate activate call `playbook.content` and `business_rules.content` are versioned and immutable. Saving one **creates a new version and makes it active in the same call** — the response's `createdVersion` and `replacedVersion` tell you what happened, and there is no `activate` input or `activate_*` tool on `/mcp/v3`. A version you save has full effect immediately; there's no draft state where it exists but hasn't taken effect. Rolling back is saving the earlier content again: doing so mints a new version with that content, which becomes active. There's no "reactivate version 2" call — history is append-only and every version you can read is one you (or something writing on your behalf) actually saved. `save_playbook` and `save_business_rules` also each take an unversioned half in the same call — `pricing` on the playbook, the approval gates on business rules. When a call carries both halves, `content` is written and activated **first**. If the unversioned half then fails, the version is already live and is **not** rolled back — there is no transaction spanning the two. The error response still names `createdVersion` (and `replacedVersion`) so you know a version exists before retrying, and the retry only needs to repeat the half that failed: sending `content` again would mint a second, identical version rather than fixing anything. ## Searching version history `media_kit`, `playbook`, and `business_rules` are singletons, so `search` doesn't search *them* — there is exactly one of each, and searching "your one playbook" isn't a meaningful query. What **is** list-shaped is their version history: ```json theme={null} { "kind": "playbook_version", "query": "CTV" } ``` ```json theme={null} { "sources": ["objects"], "objects": { "kind": "playbook_version", "total": 3, "matched": 1, "returned": 1, "truncated": false, "results": [ { "version": 3, "isActive": true, "notes": "Initial playbook, drafted from the Q4 sales deck.", "createdAt": "2026-07-28T15:04:00Z" } ] } } ``` `business_rules_version` works the same way over acceptance-policy history. Omit `kind` and `search` lists every list-shaped object it knows about, `playbook_version` and `business_rules_version` included. The one-endpoint, noun-shaped surface these tools live on. The three Pages you use today, and how they map to the platform. How the pre-screen reads your policy, and the three verdicts it returns. Component, Product, and the rest of the vocabulary these nouns build on.