Glossary

A fast lookup for the vocabulary of the Interchange. Where a term has a dedicated guide, the definition links to it. For the shape of how these objects nest, see the Object Model; for the design choices behind them, see the Philosophy primer.

​

A

AAO (Agentic Advertising Organization) — The public registry and compliance pipeline that decides which agents are real. An agent must be registered in the AAO registry to be connected as an inventory source; its compliance verdict is read live and is informational — it surfaces as a warning but does not block a storefront from going live. The registry is the source of truth, not a Scope3 allowlist. See Identity documents. AAO compliance — The registry’s computed verdict on an agent: it grades the agent’s self-declared capabilities against AAO test storyboards and returns passing, pending, degraded, or failing. It is informational — a non-passing verdict is surfaced prominently but never blocks going live. Contrast with authorization (a publisher’s adagents.json), which is enforced. See Identity documents. Acceptance policy — The content rules a storefront judges buyer transactions against — which advertisers, categories, and creatives it will and won’t carry. The operator authors it in plain language (with Murph); the agent reads what the operator wrote rather than a fixed category list. It is separate from the approval mode (auto vs manual): the policy is what is acceptable, the mode is whether a human reviews. The pre-screen sorts a media buy into clearly-on-policy / needs-a-look / clearly-against-a-rule, and an AI second opinion can only downgrade an auto-approval to human review — never approve or reject on its own. The platform does not auto-reject on its own. See Acceptance policy. Account — A buyer or seller workspace under an Organization. Membership, roles, and day-to-day operations — advertisers, campaigns, storefronts — live at the account level, while the contract and billing standing live on the organization. A user can belong to more than one account and switches between them per session. See Authentication. Activated social account — A connected social-platform account for which the organization has explicitly enabled mirror, read, write, routine sync, and up to 13 months of history. Connection and advertiser mapping cost nothing; an activated account is 4 IUs per account-month, drawn from the organization’s shared IU wallet at the price on the accepted Rate Card. The draw-down is recorded whether or not charging is switched on for the organization. See the Organization IU Rate Card. Ad platform connection — One authorization grant against an ad platform (Meta, Google Ads, TikTok, Amazon Ads, …): “I linked this account.” Can be made at the organization level (a manager account reaching many ad accounts) or the advertiser level (a single ad account). The connection carries the credential; the accounts it reaches are discovered from it, and each ad account is then mapped to one of your advertisers. See Ad Platform Accounts. Ask — Anything you are waiting on Scope3 for. Which part of Scope3 picks it up is its type: support (something is broken or blocking, or you want a person), product (a capability that does not exist yet), supply (inventory we do not carry), integration (a counterparty we do not connect to), or commercial (pricing, terms, billing, or a rate-card exception). Whichever type it is, an ask carries one status from the same short list — received, accepted, in_progress, done, closed — that follows the real work, plus a label and sentence written for you. Internal workflow states and ticket names are never shown. Support and supply asks reach done before ageing out of the list; a product ask, and a cancelled supply ask, leave the list rather than reporting a terminal status. Read your asks by asking Murph, from GET /api/v2/asks, or on /mcp/v3 with search({kind: "ask"}) and get({kind: "ask", id}) from either a buyer or seller account. That status is ours — where the work stands. You have a separate answer of your own: confirmed_resolved, accepted, still_blocked, or withdrawn. The two sit side by side rather than one overwriting the other, so “we called it resolved” and “I am still blocked” both stay visible. Note the two senses of accepted: as a status it means we took the ask into work; as your answer it means you have heard our answer and are not disputing it — which is not the same as saying you got what you wanted. Not to be confused with a buyer ask in a negotiation (see Negotiation posture), which is a demand-side request inside a deal, not something we owe you. See Ask Murph. Supply ask — An Ask of type supply: inventory we do not carry, that you want us to go get. It requires a buyer who can actually spend — a curator buying on behalf of demand qualifies; a publisher who wants demand for their own inventory does not, because that is a request for buyers rather than for supply, and counting it would inflate what looks like unmet demand for inventory. A withdrawn supply ask keeps its record: it stops notifying and leaves your active list, but it stays as evidence that the demand existed. Agent Registration — A WorkOS-managed way for an agent to establish its own identity. An unclaimed agent can verify its integration in a zero-spend sandbox; an authorized customer user can later grant the agent organization access. See Authentication. Ad Server — An operator-owned ad server (Google Ad Manager, FreeWheel, or SpringServe) connected as an inventory source. Interchange manages the sales-agent plumbing in front of it, so buyers transact through your storefront while the ad server reads its existing inventory, ad units, and placements. The setup uses either a supported direct integration or an Interchange-managed sales agent; sellers use the same ad-server connection surface either way. It stays enabled unless deactivatedAt is set, and whether it is live is derived from its connection status. Contrast with Sales Agent, which is a separate AdCP agent you point at by URL. See Choosing a source. adagents.json — The file a publisher publishes at /.well-known/adagents.json to declare which agents are authorized to sell its inventory. Resolution follows three paths: the publisher’s own file first; an authoritative_location one-hop redirect if that file is a pointer to a centrally-hosted file (how a network serves one file for many publishers); and a manager domain fallback if the direct file is absent — the domain’s ads.txt managerdomain is read and that manager’s file is used instead, so a network-managed publisher (e.g. a Raptive/CafeMedia domain delegating to cafemedia.com) resolves even though it hosts no file of its own. Authorization is bound to the publisher domain, not mere presence in the file. See adagents.json for network sellers and Discover agents. AdCP (Ad Context Protocol) — The open protocol for agentic media buying that the Interchange runs on. AdCP defines how participants discover, negotiate, and execute (get_products, create_media_buy, get_media_buy_delivery). One integration on AdCP reaches every counterparty. See adcontextprotocol.org. AdCP version negotiation — How a buyer and a source agree on a protocol version per request. The buyer pins a release-precision version (adcp_version, e.g. 3.1); the source advertises the versions it speaks (supported_versions), and a conformant source downshifts a pin to its highest supported release at or below the pin within the same major version rather than rejecting it with VERSION_UNSUPPORTED (which is reserved for a cross-major mismatch). See AdCP versioning & negotiation. Advertiser — Interchange’s commercial media identity on whose behalf campaigns run: a Brand Reference care of an Operator. This is a product projection; AdCP keeps Brand, Operator, Account, and Agent separate. A buyer-declared AdCP account uses (brand, operator, sandbox) as its natural relationship key, while an upstream-managed account_id names a seller-owned namespace entry with a declared account_scope. Direct self-serve from an account registered to the brand’s domain means the brand is its own operator (Coca-Cola care of Coca-Cola); self-serve is an interface, not an operator. When a buyer account has no registered domain, current v2 outbound AdCP calls temporarily use interchange.io as the operator until the real account domain is recorded. The current v2 advertiser resource is the top-level container for that identity’s media and may partition it by currency and sandbox mode. It owns a default optimization mode and linked sales-agent accounts; campaigns live underneath it. See the Advertiser guide. Advertiser mapping — The link between a platform ad account and one of your advertisers, so campaigns for that advertiser transact on the right account. Managed under Settings → Connections. See Ad Platform Accounts. Audience — A target or suppress list attached to a campaign to shape who a buy reaches. See the Signal guide.

​

B

Business Rules — The seller Page for what a storefront accepts and when a person reviews it. It combines the versioned advertiser, category, and creative acceptance policy with the current creative and media-buy approval gates. The policy says what is acceptable; a gate says whether human review happens. See Seller Pages. Brand / Brand Reference — Whose products are advertised: name, assets, safety posture, and story. A brand becomes an Advertiser only in an operator context (BrandRef × Operator); the same brand may therefore participate in more than one advertiser identity. The brand reference is the structured form sellers and creative agents read. See the Brand Story guide. Brand hierarchy (house / keller_type / parent_brand) — The corporate structure a brand declares in its brand.json: the house it belongs to, its keller_type (master, sub_brand, endorsed, or independent), and its parent_brand. Storefronts resolve a buy’s brand and operator up this hierarchy to apply a house discount — a discount keyed to a corporate house (e.g. nike.com) that reaches every brand and operator rolling up to it. See Identity documents. Budget (gross) — Every budget a buyer sets — campaign budget.total, per-product budgets on a media buy, package budgets — is gross: the fee-inclusive, all-in amount the buyer pays. The Interchange fee is carved out inside it at the Fee terms locked when each media buy was created, and the split is readable via the media buy’s budget_breakdown. Delivered spend on buyer surfaces is gross too — except on legacy media buys created before fee terms were locked, which report delivered spend net, as the seller reported it, and carry neither budget_denomination nor budget_breakdown. See Budgets and fees. Buyer discount — A discount a storefront sets for an advertiser, applied at product discovery. An advertiser has two facets, so a house discount is keyed to one axis: a brand discount (the advertiser’s brand or its house — coke.com, nike.com) or an operator discount (the advertiser’s buying agency/DSP or its house — groupm.com, wpp.com), each resolved up the brand hierarchy. Within an axis the nearest ancestor wins; across axes the larger discount wins (tie → brand). The narrower cases — an exact brand-and-operator advertiser, country terms, or freeform notes — live in a buyer instruction. When both match, the larger applies; either is floored at the storefront’s wholesale cost. Billing (agent vs operator) — The two ways a media buy is settled. agent (Interchange-cleared): Interchange invoices the buyer and pays the seller by bank transfer, net of fees — this requires the seller’s Payout details on file. operator (seller-cleared): the seller bills the buyer under their own external agreement; Interchange moves no media money. Normal storefronts are Interchange-cleared today. Seller-cleared storefront settlement is planned but is not configurable yet; existing official sales-adapter arrangements are the only current exception. See the seller billing overview and the buyer billing overview. Bring/build your own buyer agent (BYOBA) — Using software your organization builds or operates as its buyer interface to Interchange. BYOBA is an entry point, not a customer segment, plan, discount, or wallet. A BYOBA workload uses the same Organization IU Rate Card as the organization’s other buyer, storefront, and Murph activity. Buyer auto-approve override — An operator-set, per-buyer opt-in that lets one trusted buyer’s media buys skip review while the storefront stays in manual review for everyone else. It is relax-only (it can never put a buyer under review) and media-buy-only — it never affects creative review. An enabled buyer’s media buys bypass both the human queue and the acceptance-policy screen, so it is operational trust, not a commercial term. Effective only while mediaBuyApproval is manual. See Per-buyer auto-approve. brand.json — The file a brand or operator publishes at its own /.well-known/brand.json to declare the agents it owns and runs (role-typed, each with a jwks_uri signing-key root) and its corporate brand hierarchy. It is the demand/operator-side identity document — distinct from adagents.json’s supply-side authorization. See Identity documents.

​

C

Campaign — A unit of buying owned by an advertiser, labeled with a mode (discovery, performance, or directed) and a management state (tracked or managed). Managed campaigns use the canonical buyer product and media-buy lifecycle; tracked campaigns are read-only shells mirrored from a connected seller account the platform did not set up. Planning inputs (brief, objective) belong to the discovery and performance modes, not to managed as a class. A campaign that projects exactly one storefront-authoritative media buy may come from a connected-account mirror (tracked) or a direct AdCP storefront request (managed). Connected-account projections are read-only; managed buys use the canonical buyer media-buy lifecycle. See the Campaign guide. Cancellation approval — The seller approval required when a buyer cancels a committed guaranteed media buy. The buy keeps delivering while the storefront operator decides: approving terminates the buy (the cancel is forwarded to the source); rejecting keeps it active. Non-guaranteed and uncommitted buys cancel directly with no approval. See Media buy lifecycle: Cancellation. Catalog — An advertiser’s structured list of what it sells — products, offerings, job openings, hotels, listings — synced onto the advertiser so sellers can build ads from the real items (names, prices, images) instead of a static banner. A catalog arrives as a feed: either a remote url the platform re-fetches on a schedule, or items supplied inline (never both). Items pass validation and per-item review, and campaigns and creatives then reference the catalog. For a Shopify store, the product-export CSV from the Shopify admin is a supported feed as-is (feed_format: shopify). See the Catalog guide. Catalog activation — The lifecycle that turns a synced catalog into campaigns: save a transform (rules that fan items out into campaign groups, budget hints, and creative prompts), preview the resulting plan, execute it into campaign and creative-generation jobs, and refresh the feed to pick up changes. A catalog has exactly one active transform at a time. See Save catalog transform. Community fallback (community mirror) — A copy of a publisher’s adagents.json that the AAO registry hosts so an unpublished publisher is still discoverable. A community mirror lists no authorized agents — it exists to be found, never to authorize, so an empty mirror is not a denial. An owner-published document always supersedes it. This is different from an AAO-hosted publisher document, where AAO hosts the publisher’s configured document and the publisher origin must verify it with an authoritative_location stub. See Identity documents. Component / Inventory component — The raw material a source exposes — avails, ad units, placements, creative assets — before it is packaged for sale. A component is unpackaged and not directly sellable on its own; it is the stock that flows through a source (the pipe), and it is discovered rather than authored. Components are composed into Products at discovery time. Contrast with Product (component plus business rules), with Wholesale product (a product you author, which is directly sellable), and with Source (the connection that carries the component). The raw targeting material on the signal side has its own name — Ad-server targeting — because what a seller authors from it is a Signal, not a component. Component cache — The cached raw products/components Interchange reads from an inventory source when merchandising is enabled or when wholesale-mode reads need source material. Cache success means the source returns stable component ids, names/descriptions, pricing, formats, publisher properties or selectors, delivery type, and execution metadata. A cache complaint is not the same as a live passthrough failure. Comparative Proposal Ranking Pass — A managed comparison of up to 100 accepted proposal candidates under buyer instructions. It returns a score, rationale, and ordering without changing seller-authored proposal fields. The meter is currently calibrating and reports no charged IUs. See Evaluate proposals across storefronts. Composition vs Passthrough — Two ways the platform handles a buyer intent. Composition means the Merchandising Agent builds a proposal from cached components, operating instructions, pricing, and policies. Passthrough means the request flows straight to a single sales-agent source on the buyer’s own credentials with no Interchange optimization layer. The legacy routingType compatibility field records this path as ROUTED. Connection — A specific organization linking its own account on an existing Integration — self-serve, no engineering involved. Connecting a Snap ad account or a Google Ad Manager network is a connection; the integration that makes Snap or GAM connectable at all is the separate, Scope3-built thing. See Settings > Connections. Corporate IU discount — One plan-wide percentage discount authorized for a billing organization. It applies to the organization’s shared IU plan across buyer, storefront, Murph, and other rated workloads; it is not a storefront Buyer discount and does not stack. Plan & Billing shows list and effective prices before acceptance. See the Organization IU Rate Card. Coverage — The set of publisher domains or properties a product can run on. For managed network storefronts, run-of-network coverage comes from the storefront’s authorized publisher properties, usually resolved from adagents.json; when coverage disclosure is enabled, get_products surfaces it as publisher_properties. See Publisher properties and coverage. Creative review (Publisher approval) — The gate a buyer’s creative passes through before it serves on a publisher’s inventory. There are two independent gates: a storefront operator review (when the publisher has creativeApproval: manual, a human on their ops team approves or rejects each creative) and a source system review (the publisher’s ad server accepts or rejects the creative after it is synced). Both statuses are visible to buyers on get_campaign. See Creative approval. Creative source — A source whose components are creative assets: a creative library, asset feed, or a generation and approval workflow the Merchandising Agent draws on when answering a brief. A peer source type alongside inventory and signal sources. See Choosing a source. Credentials (source) — A buyer’s registered account for one inventory source, used where that source requires per-buyer authentication. Registered via POST /sales-agents/{agentId}/accountCredentials. See the Storefront guide. Credit line — A Scope3-granted spending ceiling beyond an organization’s funded balance, carried on its Standing as creditLimit (minor currency units, absolute — not monthly). A null or 0 creditLimit means the organization has no credit line: it can still spend a funded balance, but no credit is fronted until Scope3 grants a positive limit — apply for credit or contact Scope3. Contrast with Prepay.

​

D

DECISIONED / ROUTED compatibility field — Legacy server-derived metadata on a media buy. It records whether the current implementation used the platform composition path (DECISIONED) or an official sales-adapter path (ROUTED); it is not a client input or the future product model. Do not infer campaign mode, whether a buyer brought its own agent, the protocol endpoint, or the settlement method from this field. Those are independent concerns. See the Campaign guide. Default account — The ad account a platform connection uses for new buys when a request doesn’t name one. One per connection; set automatically when the grant reaches exactly one buyable account, otherwise chosen on the Connections tab. Organization (manager) accounts can never be the default. See Ad Platform Accounts. delegation_type — A field on each entry in a publisher’s adagents.json authorized_agents[] describing how authorization flows: direct (the agent sells directly), delegated (authority delegated to another party), or ad_network (network-level authorization). See Identity documents. Delivery — The reported metrics that roll up per package — impressions, spend, clicks — following the AdCP get_media_buy_delivery schema. Directed campaign — Deprecated vocabulary. mode: "directed" survives as a compatibility wire value for campaigns that project exactly one storefront-authoritative media buy (one upstream campaign, one AdCP media buy, one campaign shell); the concept it named is now expressed by the campaign’s management state — tracked when mirrored from seller-side activity, managed when authored through the canonical buyer lifecycle against one storefront. See Campaigns on connected seller accounts (alpha). Discovery Session — A refinable product-search conversation a buyer runs against sales agents. It produces ranked proposals the campaign selects from. See the Discovery guide. DSP advertiser (Amazon) — An Amazon DSP advertiser account: programmatic display, video, and CTV bought through Amazon DSP. A separate system from Sponsored Ads profiles under the same Amazon Ads login; one connection surfaces both, typed dsp vs sponsored_ads. See Ad Platform Accounts.

​

E

Effective gross CPM — A media buy’s gross budget ÷ its impression goal × 1000: the buy’s all-in price per thousand impressions (for a buy priced at a single fixed seller CPM, this works out to seller CPM ÷ (1 − fee rate)). Use it for “budget ÷ CPM = impressions” math on gross budgets; returned as effective_gross_cpm in a media buy’s budget_breakdown, null when the buy has no positive impression goal or no gross budget. See Budgets and fees. Platform-license overlay — An optional license added to the same base platform and organization IU plan when contracted governance, SSO, integrations, support, SLA, or sized service capacity is needed. It is not a separate IU wallet or a second self-serve plan; “Enterprise” is only a working commercial name. See the Organization IU Rate Card. Event Source — A conversion-tracking source (pixel, server event) referenced by event-based optimization goals so the platform can optimize toward real outcomes. See the Campaign guide.

​

F

Fee terms / Fee rate — The commercial terms on a buyer’s Scope3 contract, resolved from its rate card. Today’s fee terms are a fee rate — a percent of spend, carved out inside the buyer’s gross budget, never added on top. The rate locks per media buy when the buy is created (the way the FX rate locks); later contract changes affect new buys only. Sellers never see a buyer’s fee rate. See Budgets and fees. Format (canonical) — The AdCP 3.1 way to identify a creative format: a bare format_kind enum value (image, html5, display_tag, image_carousel, video_hosted, video_vast, audio_hosted, audio_daast, native_in_feed, sponsored_placement, responsive_creative, agent_placement, custom) with no agent_url. Parameters — including video/audio duration — live in params (duration_ms_exact for a fixed value, duration_ms_range [min, max]). On a product these appear in format_options[]; on a package, via format_option_refs[] or a direct format_kind + params. For a newly executed or resubmitted package containing one unambiguous fixed-size image creative, Interchange narrows a broad canonical image selector to that creative’s width and height. During the legacy migration window, a dimensionless AAO image ref such as display_image may be sent beside the canonical selector with the same inline dimensions. Concrete legacy sizes and seller-specific format refs are preserved rather than rewritten. Format reference (legacy / v1) — The older way to identify a format: a structured object { agent_url, id } (e.g. { "agent_url": "https://creative.adcontextprotocol.org", "id": "video_vast" }), optionally with width/height/duration_ms. Sent on the wire as format_ids[]. Supported through the deprecation cycle but being replaced by the canonical format_kind path. A package may temporarily carry both representations during compatibility bridging, and their parameters must agree. video_standard and display_300x250_html are legacy ids, not format_kind values. Format Option ID — A stable identifier a seller publishes on a product’s format_options[] entry so buyers can pin a specific option via format_option_refs[]. Required when a product has multiple options sharing one format_kind. Frequency Cap — A buyer-side limit on how often a person sees an ad, set on the campaign or advertiser and enforced by Scope3 across all publishers in the campaign — distinct from publisher-side caps in package overlays. Shape: { "max_impressions": 5, "window": { "interval": 7, "unit": "days" } }. Funded balance — Money an organization has prepaid and Scope3 currently holds for it. Spend draws down the funded balance first; a Credit line (when granted) is what spend may run beyond it. An organization with a funded balance but no credit line is on Prepay.

​

G

Grant — One authorization of ad platform access: who authorized it (the platform user, plus the organization where the platform has one) and which accounts it can reach. A grant is what an Ad platform connection row represents; relinking with the same platform user and organization updates the existing connection in place rather than creating a duplicate. See Ad Platform Accounts.

​

I

Inbound AdCP campaign — A directed buyer campaign created when an external AdCP client calls an enrolled Interchange-hosted storefront. The storefront manages the 1:1 buy; Interchange anchors buyer identity, advertiser, contract terms, governance, journal, and reporting identity, then records accepted commitments and delivery on its ledger. It projects as mode: "directed". Inbound describes the protocol door, not a fourth campaign mode. See How Interchange uses AdCP. Intelligence Unit (IU) — A billing unit for metered intelligent work on the Interchange, rather than a raw model token or a unit of media. One billing organization uses one IU plan, corporate discount, rollover policy, and wallet across buyer, storefront, Murph, and other rated workloads while preserving usage attribution for each. The standard IU Rate Card is not yet published in production. Where a Rate Card has been accepted, activated social account-months draw against the wallet; other planned activity meters do not draw down, and no meter is charged until charging is switched on for the organization. See the Organization IU Rate Card. IU wallet — The billing organization’s shared pool of committed, pay-as-you-go, and eligible credit lots used by every IU-rated workload. Usage remains attributed by buyer, storefront, Murph, advertiser, and capability even though the balance is shared. A credit lot may carry its own expiry — the planned 100-IU setup credit runs for 60 days — and a lot can in principle restrict what spends it, though no current lot does. Integration — A platform capability Scope3 builds to speak an external system — Google Ad Manager, CitrusAd, and the like. Only Scope3 can add one; it is engineering work, not a customer action. An AdCP-speaking sales agent needs no integration at all — the protocol itself is the integration. Contrast with Connection, the self-serve act of linking a specific organization’s account on an integration that already exists. Interchange — Scope3’s operated platform where buyer agents and seller storefronts transact on AdCP. AdCP is the protocol; the Interchange is how it runs at scale — adding trust, identity, billing, legal, and observability. Inventory Source — A source that provides supply (ad space) to a storefront. Comes in four kinds, distinguished by executionType: Ad Server, Sales Agent, Modular source, and Linked source (each defined in this glossary). A storefront can connect several. An inventory source can answer live passthrough calls, expose cached components for merchandising, or both. See Choosing a source.

​

L

Learned default posture — The Negotiation posture the Merchandising Agent has saved as its own default — the first rule it writes for itself. Persisted once a posture has been converting consistently, and only when the gated, off-by-default learning loop is enabled; it is durable and visible in seller analytics. The agent applies it only as a fallback when it has no fresher read for the buyer in front of it, so your Operating Instructions always take precedence. See Seller analytics. Linked source — An inventory source whose supply comes from the platform rather than from your own ad server or agent — the curation use case. Linked inventory is discovered automatically from the ambient pool of LISTED, transacting storefronts and resolved at runtime, so there is no source row to create or manage; you participate by being LISTED. Registered logically as executionType: LINKED_STOREFRONT. See Choosing a source.

​

M

M2M application — An organization-owned OAuth client for a deployed backend integration. It exchanges a client ID and secret for short-lived access tokens; organization admins can add a replacement secret, test it, and revoke the old one. See Authentication. Managed campaign — A campaign with management: "managed": authored or adopted through the platform spine (get_products → create_media_buy → update_media_buy), whether the buys came from discovery, an objective, or the buyer addressing one storefront by name. The platform sends instructions down; the execution system remains the source of truth. Contrast tracked campaign. Management state — The campaign axis (management: "tracked" | "managed") that answers who may act on the campaign. It is independent of where truth lives: in both states the storefront’s execution system is authoritative and the platform reflects it. Distinct from the older phrase platform-managed, which describes the discovery and performance modes (the platform selects and allocates); every platform-managed campaign is management: "managed", but so is a buyer-authored single-storefront campaign. Manager account — A platform’s organization-level container: Google MCC, Meta Business Manager, TikTok Business Center, Snap Organization, Reddit or Spotify Business, LinkedIn Organization. It reaches the ad accounts under it but is not itself buyable — Interchange lists it for context (typed organization) and expands the accounts under it into individually mappable ad accounts. For an agency, one manager-account Grant links the whole client portfolio — see the agency setup runbooks. See Ad Platform Accounts. Manager domain — The domain a publisher delegates to when a network manages its adagents.json centrally. A managed publisher can point to the manager with an ads.txt MANAGERDOMAIN=<domain> line or an authoritative_location stub; Interchange resolves that manager file to find the publisher’s properties and authorized agents. See adagents.json for network sellers. MCP (Model Context Protocol) — The tool-calling protocol an AI agent uses to drive the Interchange. v2 exposes three composite MCP tools — health, ask_about_capability, api_call — rather than a tool per endpoint. Measurement endpoint (ping.interchange.io) — Scope3’s first-party endpoint that the auto-injected impression (/agentic/imp) and click (/agentic/clk) trackers fire to. Powers impression counting, frequency capping, emissions measurement, and conversion attribution; carries identifiers and tokens, never raw PII. In Google Ad Manager it can surface under Associated ad technology providers and must be declared as a custom ad partner URL to serve in the EEA/UK/Switzerland/Brazil. See Creative → Measurement endpoint and EU consent. Media Kit — The seller Page for what buyers see: resolved identity, seller story, markets, channels, verticals, and evidence links. The Media Kit does not support product-template list prices yet. Current structured value anchors and floors live in Playbook. See Seller Pages. Media billing entity — The legal entity Scope3 invoices for an organization’s media spend, distinct from the organization’s interchange-fee payer. Configured at up to three levels — advertiser, account, organization — resolved most-specific-first; every media-transacting organization always has one at the organization level (the mandatory backstop). Country is identity metadata (tax, currency) and never routes an invoice. See Media billing entities. Media Buy — One AdCP transaction with one sales agent, spawned when a campaign executes (one per agent). Not directly creatable; tuned through the campaign update endpoint. See the Media Buys guide. Media buy status (AdCP) — The per-buy lifecycle status carried on the AdCP wire: pending_creatives (accepted but no approved creative attached, so not launchable), pending_start (creatives ready, flight not yet started), active (live and delivering), paused (halted, resumable), completed (flight finished or fully delivered), rejected (source declined), canceled (stopped before completion). A buy a source is still moderating stays pending_creatives and resolves through a submitted task. This AdCP wire status is distinct from the higher-level Interchange buyer rollup (PENDING_APPROVAL, ACTIVE, …) on the Media Buys guide. See Media buy lifecycle. Merchandising — Training your Merchandising Agent to sell: pulling the right products, reference material, and policy together to answer a buyer brief. This is the how of selling, distinct from a Product, which is what gets sold. Three Pages steer it — Media Kit, Playbook, and Business Rules — and each owns a different fact. See Merchandising. Merchandising Agent — Your storefront’s seller: the agent that meets buyers’ agents, reads their briefs, composes priced proposals in your voice, and runs the deal through. It does five jobs — Represent, Offer, Govern, Transact, Learn. You train it by working with Murph. See The Merchandising Agent. Modular source — An inventory source assembled from individual modules — an avails feed, a booking ledger, creative handoff, trafficking, status sync, reporting import, and human work — when inventory and execution do not come from one compliant upstream agent. Manual and back-office supply belongs here because each lifecycle responsibility needs an explicit module or human owner. Registered as executionType: MODULAR_SOURCE. See the Modular lifecycle guide. Murph — The assistant you talk to. Murph helps you set up, train, and coach your Merchandising Agent in plain language — never by hand-editing config — and operates the platform for buyers and operators too. Same Murph everywhere, different powers per role. See Ask Murph.

​

N

Negotiation posture — The stance the Merchandising Agent takes when shaping an offer and responding to buyer asks — one of direct_fit, hold_value, value_preserving_compromise, tradeoff_ladder, price_first, or wholesale_mirror. The agent derives a recommended posture from history and can save a Learned default posture; how that learning is converting is the Posture conversion readout. See Seller analytics.

​

O

Organization API key — A WorkOS-managed credential shared by a script or automation owned by an organization rather than one person. Organization admins create and revoke these keys in API Access settings. See Authentication. Organization IU Rate Card — The versioned offer that defines one billing organization’s IU plan sizes, list prices, corporate discount, rollover, overage, term, and activity prices across buyer, storefront, Murph, and other rated workloads. It is separate from legacy media-pricing arrangements. The standard Rate Card is not yet published, and its pilot prices and IU denomination are not final; an authorized administrator will see and accept the exact effective version before it becomes binding. See the Organization IU Rate Card guide. Operating Instructions — The internal versioned guidance behind Playbook. Exactly one version is active at a time; sellers manage it as Playbook guidance. See the Storefront guide. Storefront adapter — A supported expert integration that dispatches the entire buyer-facing storefront directly. It is configured as storefront ADAPTER routing, not as an inventory source. Contrast with an external sales agent, which remains private upstream supply behind the storefront. See Choosing a source. Operator — The organization that owns and manages an account — who the account holder is for commercial purposes. It applies to both sides: on the sell side the operator owns a storefront (a publisher, sales house, or ad network); on the buy side the operator manages a buyer account (an agency, trading desk, or DSP house). Its operator domain is the brand/company domain where the operator’s identity lives — where we pick up the logo and company description (via brand.json / AAO), and often the domain the operator’s email points to (e.g. raptive.com, groupm.com). On the buy side it is confirmed on the buyer account and remains separate from the WorkOS organization domains used for sign-in, SSO, invitations, and membership. It is the account-owning entity, not inventory: on the sell side it is distinct from a Publisher (a domain of inventory the operator adds), and the operator domain is never itself a product’s coverage — Raptive is the operator (raptive.com) and adds the publisher cafemedia.com. (The storefront setup form currently labels the sell-side operator domain “Storefront domain.”) Do not use Operator as a synonym for Seller. On the buy side, an Advertiser is a Brand Reference care of this operator. When a brand buys directly from an account registered to its domain, its own organization is the operator; self-serve is only the interface used to do so. A current v2 buyer account with no confirmed or legacy domain uses interchange.io as a temporary platform-operator fallback. Organization — The top-level entity in the organization/account hierarchy. It owns the commercial relationship with Scope3 — the contract and Terms of Service, one shared IU plan and wallet when an IU Rate Card is bound, and the billing Standing (Funded balance, Credit line) — and holds one or more Accounts, where membership and day-to-day operations live. Not to be confused with an Organization account, which is an ad-platform manager container (a Google MCC or Meta Business Manager), not a Scope3 entity. Organization account — See Manager account. The organization account type on a discovered platform account marks a manager container that can never be selected, mapped, or used for buys. Distinct from an Organization, the Scope3 entity that owns your accounts.

​

P

Playbook — The seller Page for how a storefront sells. Its versioned instructions steer packaging, naming, selection, and explanation; its structured pricing holds current value anchors, floors, ceilings, and currency. Instructions may refer to those facts but may not copy them into prose. See Playbook pricing. Pacing / Pacing Period — Pacing is how spend is spread over time (even, asap, front_loaded). A pacing period is a labeled time window within the flight with its own weight or budget; each product becomes one package per period at execute. See the Pacing periods guide. Package — One product for one pacing period inside a media buy, carrying its own budget, pacing, bid price, and optimization goals. Spawned at execute. Its packageId is stable for the life of the package but is an opaque string: the trailing number on a storefront-minted id is a dispatch-order position, not the pacing period, so identify a period from pacingPeriod.index/label rather than the id. See Package identity and the id numbering scheme. Performance campaign — A platform-managed campaign where the buyer supplies an objective and Interchange controls cross-seller allocation toward that objective. It is mode: "performance" on the shared campaign resource. Payout details — The bank account a storefront operator saves so Interchange can pay them: beneficiary name and address, account number or IBAN, one bank identifier (Fedwire/ABA routing number, CHIPS ABA, SWIFT-BIC, or local bank code), and payout currency. Entered once in Settings → Billing or via set_payout_details; encrypted at rest, used only to execute payouts, and the account number is never displayed after save (reads return the last four characters). Required for agent billing on media buys. See Set payout details. Payout entity (payee) — A legal entity within a seller organization that receives payouts into its own bank account. Organizations selling through multiple legal entities (for example, separate companies per market) register one payee per entity and payout currency under Settings → Billing → Payout entities (or via set_payout_payee); the beneficiary name on each account must match that legal entity. Each payee carries its own encrypted account details and is paid independently. See Set payout payee. Brief — The canonical artifact for buyer intent across live discovery, uploads, CRM intake, synthetic evaluation, and prospective demand. It carries origin provenance and anchors product composition and proposals. Posture conversion — The learning readout in seller analytics: which negotiation posture the Merchandising Agent actually used (the selected posture) is booking, and whether following the history-derived recommended posture booked better than diverging from it (followed vs diverged win rate). See Seller analytics. Prepay — A funding posture where an organization spends only against a Funded balance it has deposited, with no Credit line (creditLimit is null or 0). To spend beyond the funded balance, the organization applies for credit or contacts Scope3 to be granted a positive limit. Product — A packaged, sellable unit: one or more Components plus the business rules around them — rate card, who approves, what bundles. The Merchandising Agent composes products in real time when it answers a brief. Contrast with a Component, which is the raw, unpackaged material, and with Merchandising, which is the act of selling the product. Two kinds reach buyers, told apart by id prefix: a composed product (cf_…) is built to a brief at discovery time, and a Wholesale product (wh:…) is one you authored. Composed product (cf_…) — A product the Merchandising Agent builds to a brief at discovery time, from your wholesale products and components plus your business rules. You do not author or manage one: it exists because a buyer asked a question, and its id prefix (cf_) is how you tell it apart from a wholesale product (wh:) in reporting and in a media buy. Requires product composition to be enabled. Passthrough product — A product that belongs to a third-party sales agent you have connected, offered to buyers as that agent returns it. It is not a composition input and it is not yours to author — the agent is the system of record, and Interchange reads and forwards. Contrast with a Wholesale product, which you author, and a Composed product, which is built from yours. See Choosing a source. Wholesale product — A product you author on a managed sales-agent source: name, description, inventory selectors, creative formats, and pricing, with a draft → active → archived status. It is what AdCP returns for get_products(buying_mode: "wholesale"), and it plays two roles depending on your storefront. On its own it is directly sellable — an active wholesale product is discoverable by buyers. With product composition enabled it is also an input: the Merchandising Agent draws on your wholesale products to build composed products for a brief. Distinct from a Component, which is raw material you never author, and from a third-party agent’s own buyer-facing products, which are passthrough and are not composition inputs. See Create products from ad-server inventory. Property — An individual site or app under a Publisher (e.g. recipeswithessentialoils.com); a publisher has 1:N properties. Each carries its own publisher_domain, property_id, and tags in the publisher’s adagents.json, and is the unit an AdCP publisher_properties selector resolves to. Distinct from the Publisher it lives under and the Operator that sells it. See Publisher properties and coverage. Property List — A named buyer-owned include or exclude set of domains, apps, or CTV identifiers. Buyers use property lists to shape where campaigns run; a seller’s agent receives an ADCP PropertyListReference and resolves it on demand. See Property Lists and Property-list briefs for sellers. Proposal — A recommended media plan a seller returns from discovery — named budget allocations across products, with rationale and brief alignment — that a buyer can apply to a campaign in one step. Storefronts with product composition author draft proposals when a brief supports a multi-product plan. A draft proposal can be finalized (a get_products refine with scope: "proposal", action: "finalize"): the storefront re-validates that every product in the plan is still available at current pricing and commits the proposal with an expires_at deadline. A committed proposal is a price and composition commitment — not an inventory reservation — and can be executed in one step by passing its proposal_id (with a total_budget) to create_media_buy before it expires; each committed proposal executes at most once. Distinct from a storefront proposal, which freezes a discovery offer into a shareable proposalCode a buyer redeems later (see Storefront proposals). See the Discovery guide. Proposal Evaluation Pass — A managed evaluation of up to 10 valid proposal or proposal-less product candidates under buyer instructions. Each candidate is accepted, rejected, or sent through bounded seller refinement; accepted results can carry buyer-owned enrichment. The meter is currently calibrating and reports no charged IUs. See Evaluate proposals across storefronts. Publisher — A domain an Operator adds to its storefront as inventory (e.g. cafemedia.com); a storefront has 1:N publishers. It hosts an adagents.json — directly, or as a managerdomain that fans out to many managed sites — from which we resolve the publisher’s Properties. A product’s coverage is keyed off its publisher(s), not the operator domain. Distinct from the Operator (the selling entity): Raptive is the operator (raptive.com); cafemedia.com is a publisher it adds. See Identity documents. Publisher domain — The domain that identifies a publisher property in coverage and authorization flows, such as wholesomeyum.com. It is distinct from the seller’s operator domain and from a network’s manager domain. Buyers see publisher domains in product publisher_properties. See Publisher properties and coverage. Run-of-network (RON) — A product or offer covering the seller’s full authorized publisher-property set for the relevant source, rather than a seller-authored subset. RON coverage is derived from publisher identity and authorization; an ad-server mapping is not proof of RON coverage.

​

R

Recruitment — Getting an organization to join the marketplace at all — a seller signing, a buyer connecting. It is a demand signal to go land the relationship, not engineering work: nothing needs to be built for a new organization to join, only sold. Retraction — A cancel of a media buy that has not yet been committed to a source (no forwarded leg, no reserved inventory). The pending request is withdrawn and forwarded directly as a cancel with no operator approval. Contrast with Cancellation approval, which applies to committed guaranteed buys. See Media buy lifecycle: Cancellation.

​

S

Settlement currency / Payment currencies — An Interchange-cleared storefront confirms a primary settlement currency (defaultCurrency, ISO-4217) before going live, and may also list additional payment currencies (paymentCurrencies) — the full set of currencies it will be paid in (the primary is always included). For those storefronts, a media buy must be denominated in one of these currencies unless the marketplace admits the buyer currency via FX. On a settled currency there is no FX, so the currency a buyer pays in is exactly the currency the seller is paid in, and a storefront cannot sell a pricing option in a currency outside the set. Discovery only surfaces a product to a buyer in a currency the storefront can transact, and returns no products (not an error) when it can transact none of the buyer’s currency. Empty paymentCurrencies falls back to defaultCurrency, so a single-currency storefront need not set it. Direct sales adapter storefronts run by our expert agents skip seller settlement currency because Interchange does not pay the seller on that path; the buyer’s declared media-buy currency is forwarded to the downstream platform account. The marketplace may additionally accept a buyer currency outside an Interchange-cleared storefront’s payment set via FX — see Cross-currency buying. Cross-currency buying (FX) — Lets a buyer transact in a currency the storefront does not settle in. The operator decides which currencies its storefront settles in (paymentCurrencies, no FX); the marketplace decides which buyer currencies it accepts via FX — a global set Scope3 curates, covering the major traded currencies plus key emerging markets. FX is therefore global and automatic: no per-storefront opt-in. When it applies, the source keeps being paid in its own (settlement) currency (unchanged); Scope3 sits on the curation edge and converts each source cost to the buyer’s currency before quoting, at the platform spot rate (ECB-backed, refreshed daily). The rate is the same for every buyer at a given time (not a per-buyer rate), and it is snapshotted onto a media buy when the buy is created — billing the source and settling the campaign at the locked rate for its whole life. The source never sees a second currency; the cross-currency relationship is entirely a property of the storefront’s curation edge. See the Cross-currency buying guide. Sales Agent — An AdCP-compatible seller endpoint that answers discovery and executes media buys. status (ACTIVE, PENDING, COMING_SOON) says whether the agent is live; requiresAccount says whether this buyer must register credentials before using it. These are independent. As a seller, an external sales-agent source is a separate AdCP agent you register by URL (executionType: AGENT) — distinct from your storefront, which is itself the sales agent buyers reach, and from an Ad Server source. It can be used as a live passthrough source, as a component source for merchandising, or both. See Choosing a source. Seller — The supply-side participant offering inventory through a storefront. A seller may be a publisher, sales house, ad network, or platform partner. Use Seller when the point is the role in a transaction or release audience (buyers / sellers); use Operator only when the point is the account-owning organization. Seller-managed campaign — Retired product name. What it described is now a tracked campaign (management: "tracked"): a read-only shell mirrored from a connected seller account the platform did not set up. The compatibility API value remains mode: "directed". See Campaigns on connected seller accounts (alpha). Selector — An address for inventory inside a connected ad server, such as a custom-targeting key/value, ad unit, or placement. A seller-authored property or tag mapping can point to a selector for execution addressing; it does not grant publisher authorization or define buyer-visible coverage. The same ad unit is a Component when the subject is what you sell and a selector when the subject is where it runs — see the note under Component. Sandbox — The safe, non-production path every reasoning step has. Agents declaring sandbox: true are exercised through sandbox endpoints; demo reporting is one query parameter away (?demo=true). New skills land on sandbox and graduate to production explicitly. SESOFI (single-endpoint-single-object-full-intent) — The architectural pattern keeping the surface coherent: each high-level intent maps to one endpoint that accepts one object describing the full intent. It cuts agent round-trips and eliminates partial-state bugs. See the Philosophy primer. Signal — A targeting or optimization input — audience, contextual, or outcome. A seller authors a signal by choosing and combining source-native targeting primitives; it is then storefront-ready and travels as a signal on the AdCP/API wire. One word for the whole lifecycle: what you author and what ships are the same object. Contrast with Ad-server targeting, the raw material you author from. See the Signal guide. Property signal — A Signal whose job is addressing rather than targeting. A property is identified inside an ad server by a custom-targeting key-value (in Google Ad Manager, domain=<url domain>), so the platform carries that binding on the same rail as any other signal: the key is synced on the ad server source, and the values resolve storefront-side. It is not something a buyer targets and it will not appear in a brief — it exists so a Property you declared in adagents.json can be found in the ad server that serves it. The default binding is computed from your currently-authorized properties, not stored, so it cannot drift; only your own overrides (aliases, www-vs-apex, apps) persist. Distinct from a Signal in the ordinary sense (audience, contextual or outcome) and from Coverage, which is which properties a product may run on rather than how each one is addressed. See Publisher properties and coverage. Ad-server targeting — Source-native targeting available through an ad server source, such as GAM audience segments, custom targeting keys, and custom targeting values. Browsing this material does not create or import a signal; the seller chooses and combines it when authoring one. This is the raw material a signal is built from — it is what a Selector addresses on the inventory side and what you pick from on the signal side. Signal RAG — Retrieval-augmented matching that surfaces the most relevant signals for a brief or audience instead of requiring an exact lookup. See the Signal guide. Signal source — A source that carries signals rather than inventory: audience segments, taxonomies, or measurement. A peer source type alongside inventory and creative sources. See Choosing a source. Source — The connection layer: where a component comes from. A source is the pipe you connect, credential, and test; the component is the material that flows through it. Sources come in families by what they carry — inventory sources (ad server, external sales agent, Linked source, Modular source), Creative source, and Signal source — each set by executionType. Don’t confuse a source (the connection) with bare “inventory” (the stock). See Inventory sources. Sponsored Ads profile (Amazon) — An Amazon Sponsored Ads profile: retail media (Sponsored Products, Sponsored Brands, Sponsored Display), one profile per marketplace/country, tied to a seller or vendor account. Typed sponsored_ads; contrast with DSP advertiser (Amazon). See Ad Platform Accounts. Standing — An organization’s funding and verification posture, returned on the account for admins: its Credit line (creditLimit), the currency it is denominated in, and a verification level. A null or 0 creditLimit means no credit line (Prepay); a positive value is the granted ceiling. Setup credit — The planned one-time 100-IU credit for a billing organization accepting an IU plan for the first time, valid for 60 days from the commercial signup commit once an effective Rate Card makes the offer available. Being an existing customer does not disqualify an organization; having already received the credit does. Storefront provisioning may complete asynchronously without moving that window. It is one lot in the organization’s shared IU wallet and may be spent on any IU-priced activity. It does not roll over or stack, and is not currently available while the standard Rate Card remains unpublished. See the Organization IU Rate Card. Storefront — The sales-agent surface a buyer connects to. Wraps one or more inventory sources, a Media Kit, a Playbook, and Business Rules. One storefront reaches every buyer agent on the Interchange. See the Storefront guide. storefrontReviewStatus — The per-creative status of a publisher’s operator review, returned on each entry in mediaBuys[].creatives[] from get_campaign. Values: pending (in the review queue), approved (publisher accepted), rejected (publisher declined), revoked (previously-approved creative pulled by the publisher). Null on storefronts that run automatic creative review (creativeApproval: auto). See Creative approval and Creative review in this glossary. Syndication — Distributing a storefront’s inventory so it reaches buyers across the Interchange through a single registration rather than per-buyer integrations.

​

T

Task (async) — A long-running operation the platform tracks asynchronously (~60s to Minutes-Days). The caller polls or listens for completion rather than blocking — discovery, execution, and approvals can all run as tasks. Test Cohort — A held-out or experimental group configured on a campaign so the platform can measure incremental lift against a control. Configured as part of the campaign’s full intent. TMP (Trusted Match Protocol) — The open AdCP standard for request-time targeting signals — cross-publisher frequency capping, audience activation, and contextual/URL targeting — delivered by the TMP Router, which fans a small request out to context- and identity-match providers, merges the responses, and returns targeting signals without making the buying decision. Generalizes the single-vendor RTD module — one provider, header-bidding only — into a multi-provider, multi-surface standard. Sellers connect via the prebid module or by self-hosting the router container. See Real-time targeting (TMP). Tracked campaign — A campaign with management: "tracked": mirrored from a connected seller account the platform did not set up. The shell is derived from the media buys underneath it, read-only by construction, and updates automatically as the seller changes things — the platform observes and accounts, it never acts. It remains tracked and read-only. A managed campaign is created through the canonical buyer product and media-buy lifecycle instead.

​

U

Unreachable mapping — An Advertiser mapping whose platform ad account no active connection reaches — typically after the only connection that reached the account was unlinked. The mapping is kept, not deleted; it is excluded at buy time (a buy on it fails with mapped_account_unavailable rather than silently using another account) and it recovers automatically when you relink the platform or re-map the account. See Ad Platform Accounts.