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 returnspassing, 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.
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.
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.
Registered with executionType: MANAGED_SALES_AGENT; it stays enabled unless
deactivatedAt is set, and whether it is live is derived from its managed-source
status (operational.isLive). 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 — The top-level container for a buyer’s media. Owns a brand, 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
Brand / Brand Reference — The brand identity behind an advertiser: name, assets, safety posture, and story. 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 Scope3 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 a buyer, applied at product
discovery. A buy has two buyer facets, so a
house discount is keyed to one axis: a
brand discount (the advertiser or its house — coke.com, nike.com) or an
operator discount (the 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 operator-and-brand intersection, 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 (Scope3-cleared): Scope3 invoices the buyer and pays the seller by
bank transfer, net of fees — this requires the seller’s Payout details on
file. operator (direct): the seller bills the buyer under their own
external agreement; Scope3 moves no money. A storefront without payout details
transacts on operator billing only. See the
seller billing overview and the
buyer billing overview.
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 and labeled with amode: discovery, performance, or directed. Platform-managed campaigns
carry planning inputs and produce media buys at execution; a directed campaign
is the read-only shell around exactly one seller-managed media buy. 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, segments, 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). Components are composed into
Products at discovery time. Inventory components come from an inventory
source; there are also creative and signal components. Contrast with Product
(component plus business rules) and with Source (the connection that carries
the 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.
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 Scope3 optimization layer (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.
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 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 vs ROUTED — The two routing types of a media buy, derived server-side from the storefront the media buy executes against — never a client input.DECISIONED media buys let Scope3 allocate budget and optimize across
agents. ROUTED media buys (adapter storefronts) pass through to a single sales
agent on the buyer’s own credentials with no Scope3 optimization. A single
campaign can mix both. 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 — A seller-managed campaign mirrored into the buyer API.
The seller is the source of truth; one upstream campaign maps to one AdCP media
buy and one directed campaign. See
Directed campaigns (alpha).
Demand Signal — An inbound expression of buyer interest a storefront can
shape its inventory and pricing around. See the
Storefront guide.
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 toseller 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.
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 bareformat_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.
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; the two are mutually exclusive. 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
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 byexecutionType: 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 asexecutionType: LINKED_STOREFRONT. See
Choosing a source.
M
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 (typedorganization) 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 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.
Merchandising rules, acceptance policy, and pricing and terms all steer it.
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, trafficking, status sync, reporting import — when
inventory and execution do not come from one compliant upstream agent. The
classic shape is manually uploaded avails that are then trafficked downstream
(for example, into Cadent). 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 ofdirect_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
Operating Instructions — Versioned guidance that steers how a storefront responds to demand. Exactly one version is active at a time. See the Storefront guide. 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 (viabrand.json / AAO), and normally the domain the operator’s
email points to (e.g. raptive.com, groupm.com). 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.
Organization — The top-level entity in the organization/account hierarchy.
It owns the commercial relationship with Scope3 — the contract and Terms of
Service, 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
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. See
the Packages guide.
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 Scope3 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.
Planning Brief — The free-text intent a buyer attaches to a campaign (the
brief field) that steers discovery and auto-selection — e.g. “Premium video
for tech-savvy professionals.”
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.
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.
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 — A seller-settled 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 a seller-settled
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.
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.
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 — The AdCP/API wire object for a targeting or optimization input —
audience, contextual, or outcome. On seller surfaces, the operator-facing term
is Signal component. See the Signal guide.
Signal component — A named targeting definition a seller creates from one
or more source-native targeting primitives. It is storefront-ready and is
carried as a signal on the AdCP/API wire. Contrast with Ad-server
targeting, which is the raw targeting already present in the connected ad
server.
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
component; the seller chooses and combines it when authoring one.
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 whose components are signals: 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.
Storefront — The sales-agent surface a buyer connects to. Wraps one or more
inventory sources, a business profile, and operating instructions. One
storefront reaches every buyer agent on the Interchange. See the
Storefront guide.
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).
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 withmapped_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.