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
publisher-controlled and resolved per publisher: an unauthorized result warns
during setup and product authoring rather than blocking them, while buyer-facing
discovery hides unauthorized publishers and managed product coverage discloses
only the authorized set.
See Identity documents.
Brief Acceptance policy — The content rules in AI Business Rules that a Seller Account uses to judge 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. A deterministic hard match to an explicit
rule supplies a strong rejection signal in the human queue; it does not
auto-reject a submitted buy in the current rollout.
See AI Business Rules.
Account — A buyer or seller workspace. Buyer accounts hold advertisers and
campaigns; each seller account owns one storefront whether it sells inventory
the operator owns, represents, or manages. An account may begin standalone or
be explicitly attached to an Organization. Attachment is what moves
contract, billing, and administrator authority to the organization; a matching
email domain or CRM association does not attach it. A user can belong to more
than one account and switches between them per session. See
Account Access & Signup.
Account setup — The setup case for a buyer relationship: billing path,
currency, approvals, inventory mappings, and notes; for a pending buyer, the
admission decision.
Account type — Buyer to manage campaigns or Seller to sell inventory.
A Buyer Account has no sandbox/live lifecycle mode: permission is derived for
the requested operation from identity, Terms, plan and entitlement, standing,
and any transaction route requirements. Offer a sales agent is a signup choice that enables
a sales agent offering on an organization for registration and certification;
it is not another account type or commercial approval. Its compatibility API
value is PARTNER even though the field is named accountType.
Listing (Seller Account package) — The Seller Account foundation. It gives you
a Listing on Interchange while you bring your own sales agent, plus the
operational record for campaigns, media buys, creatives, approvals, delivery,
activity, and reporting. Its agent source is a COMPOSING source. AI Business
Rules are available. Saving, enabling, and evaluating AI Business Rules is not
an IU-rated activity today; other qualifying activity remains governed by the
organization’s accepted IU Rate Card.
Listing + Distribution — The standard paid Seller Account package for unlimited
self-serve advertiser invitations and management, public listing distribution and an
optional customer CNAME, and customer-branded AdCP and ChatGPT app channels. It does
not improve or rank the Interchange listing, enable Merchandising, or replace the
connected sales agent. Existing accepted offers continue to use the advertiser
capacity stated in their terms.
Activated social account — A historical v0-v3 Rate Card activity. It
remains readable on an agreement accepted under those catalog versions, but is
not added to a new Rate Card. See Enhanced Reporting.
Enhanced Reporting — The current Rate Card activity for one exact connected
account in a billing period after its Enhanced Reporting control is enabled and
its existing reporting subscription completes a successful sync. It is 4 IUs
at the standard rate. An enabled account without a reporting subscription or
successful sync draws no IUs. Ordinary connection, synchronization, and
campaign actions are included. Connection and advertiser mapping cost nothing. See the
Organization IU Rate Card.
Activation (Storefront connection) — The readiness and lifecycle of one
Storefront for one advertiser in a buyer account. Selection and billing policy
remain account-wide; activation is tracked separately for each advertiser as
provisioning, active, action required, waiting on seller, retrying, failed,
retiring, inactive, or not applicable. See
Storefronts.
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.
“Demand signal” describes evidence, not an object. You may see the phrase
used for what a supply ask is evidence of — real demand for inventory we
cannot yet fill. It is not a thing you create, read, or hold, and it is not a
kind of Signal, which is targeting material a seller authors. Where buyer
intent is a durable record it is a Brief; where it is something you are
waiting on us for, it is an Ask.
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 scoped 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 Collection — Canonical publisher-declared content identity, such as a
series, publication, event series, or rotation. An AdCP Collection is not a
generic capacity pool, placement, channel, portfolio, monthly grouping, or
parser container. The exact collectionId, collectionName, and
collectionDescription fields in static-avails-feed:v1 are legacy
compatibility grouping fields; their values do not establish AdCP Collection
identity. See Publisher domains and the
inventory source input guide.
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 grant — An expiring, accepted authorization from one
organization to another for exact advertiser IDs and reviewed read or campaign
capabilities. The advertiser owner keeps ownership, Campaign IDs, and its
backing account; the grantee never receives account, member, billing,
unrelated-advertiser, future-advertiser, or private-configuration access.
Names, domains, CRM associations, signup history, providers, external Business
Manager membership, and Partner status do not create a grant. See
Manage organization advertiser grants.
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 on the Sellers page. See
Ad Platform Accounts.
Audience — A target or suppress list attached to a campaign to shape who a
buy reaches. See the Signal guide.
Audience facts — Seller-provided statements about who a product’s
audience is, taught as Selling points from your Product marketing
material and matched onto a proposal’s merchandise block by the product’s
channel and creative format (a claim scoped to both must match both). Each
fact carries the seller’s own source alongside it — a verbatim document
quote, or a plain statement that the seller told us this — never something
Scope3 has independently verified. We present audience facts as your claims,
not as findings of our own; where you haven’t taught one for a product yet,
the proposal says so rather than describing the audience generically. See
Product marketing.
B
Bid Decision — The qualification judgment a storefront makes before it composes anything: pitch the brief in full, counter-pitch it with a credible reframe of the ask, or pass with a short branded decline. Decided against the seller’s Selling Doctrine and recorded on the proposal pass with the doctrine version and the rule that reached it. A pass withholds the composed proposal and returns the storefront’s existing no-fit response shape, so a buyer cannot tell a decline from nothing having matched. Passthrough inventory and already-finalized proposals are a different lane the doctrine never judged and still ship; the decline itself is recorded seller-side. See Selling doctrine. AI Business Rules — The seller Page for what a storefront accepts and when a person reviews it. It combines the versioned advertiser, category, and creative Brief 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 domain (previously called the operator domain) — The domain where a
seller’s identity lives: where Interchange picks up the logo and company
description (via brand.json / AAO), used to resolve the seller’s
listing. Confirmed on the storefront, distinct from a buyer account’s
operator domain (see Operator) and from the WorkOS organization
domains used for sign-in, SSO, invitations, and membership. See
Domains and Seller Pages.
Public listing domain — The hostname, a CNAME onto Interchange, on which a
storefront’s public listing and any channel app built on it (such as a ChatGPT
app) are served and verified. Entered and verified inside Public
distribution, the Listing page’s fourth step. Distinct from the Brand
domain (where brand.json lives) and from Publisher domains (the
properties a storefront sells).
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. Seller Accounts 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 Account Mapping — The seller-side record for one exact operator-and-brand
buyer relationship on a Seller Account, with private mappings to the native accounts
used by its inventory sources. Legacy v2 operation names retain seller_account
for compatibility, but those records are buyer relationships — not Interchange
Seller Accounts or Connected provider accounts. See
Buyer Account Mapping.
Buyer discount — A discount a Seller Account 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 Seller Account’s wholesale cost.
Billing (agent vs operator) — The two ways a media buy is settled.
The buyer Connections view labels agent as Consolidated and
operator as Direct. 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 Seller Accounts are
Interchange-cleared today. Seller-cleared settlement for Seller Accounts 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.
Billing mandate — A seller-specific commercial relationship that records
who sells and is paid, who operates, who is liable to pay, who holds payment or
invoice authority, and which exact advertiser or reviewed advertiser set the
terms cover. Its billingMandateReady projection is tracked separately from
advertiser access and supplies only necessary mandate evidence to a later
composing workflow. It never grants complete billing, proposal, Campaign,
execution, or spend authority and does not prove a funded or invoice rail. It
contains typed internal evidence references and audit evidence, not structured
credential fields. Recognizable credential and bank-account literals are
rejected from caller-authored free text, where credentials must never be placed;
semantically unknowable bare identifiers are not treated as credentials. See the
seller billing overview.
Billing policy (Storefront connection) — The account-wide choice of
Consolidated or Direct media billing for one buyer account and Storefront.
Direct billing acceptance is separate from Storefront selection and applies to
current and future advertisers. The policy becomes read-only when Interchange
sends the first activation for an eligible advertiser. See
Storefronts.
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, Seller Account, and Murph activity.
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 amode (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
provider 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 Seller-authoritative media buy
may come from a provider-account mirror (tracked) or a direct AdCP Seller
request (managed). Tracked 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 Seller Account
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.
Capability health observation: one health check’s reading on one
inventory source’s inventory or reporting capability, carrying status
(always healthy, degraded, or unhealthy — never a null or unknown
reading), what it saw last time (previousStatus), a machine-readable cause
and human-readable detail, who can act on a failure (owner), and when it
was observed (observedAt, lastOkAt). capabilityHealth.inventory /
.reporting on storefront readiness and
source diagnostics
each carry a derived status (the current verdict for that axis, computed
across every observer and discounting stale readings) alongside the
observations[] evidence behind it, so two checks can disagree and both stay
visible even though status still gives you one answer, and an axis nothing
has ever reported on reads null rather than healthy.
unhealthy is the compatibility wire value for the human-facing Erroring
state. Source Health surfaces otherwise use Healthy, Degraded,
Erroring, and Unknown consistently. The separate condition identifies
what happened: a timeout means an observer budget expired and is degraded
evidence, whereas error_response means the Source returned an error.
This page uses two different conventions for “nothing has reported,” because
they describe two different fields. capabilityHealth.inventory.status /
.reporting.status use null. The older, singular source.health.status
cell — one collapsed reading per source, predating the per-capability
observation set above — still uses the string unknown, and keeps doing so
for as long as that cell exists: it reads from a different, single-value
column that this observation model does not replace.
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.
Channel guest — A person who can remain in a connected support channel
without becoming a member of the Interchange account. Channel guests cannot
use account data or make account changes unless they separately receive an
account membership. See Review support channel participants.
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 or selector? The same ad unit is both, in different roles. It is
a component when you are deciding what to sell — the material a source
exposes and merchandising composes. It is a Selector when you are telling
the ad server where to run — an execution address. If the sentence is about
packaging, say component; if it is about addressing, say selector.
DECISIONED / ROUTED storefront types; use explicit
source capabilities and authentication requirements to distinguish them.
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.
Seller connections are managed on the Sellers page; creative, data and
measurement, and cloud-drive provider connections are managed under
Settings → Connections.
Connected provider account — A buyable external account exposed through a
Connection, either from an ad-platform integration or a registered AdCP
Seller source (called a storefront source in legacy v2). It remains owned and
operated in the upstream provider,
where its campaigns are authoritative. A buyer can map it to an Interchange
Advertiser and, where supported, subscribe to read-only tracked
campaigns mirrored from it. It is not an Interchange Seller Account.
Corporate IU discount — One plan-wide percentage discount authorized for a
billing organization. It applies to the organization’s shared IU plan across
buyer, Seller Account, Murph, and other rated workloads; it is not a Seller Account
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 engine — An AdCP creative service that declares generation and
transformation capabilities. Models and provider-specific controls belong to
those capabilities. A V3 creative_engine is the catalog entry; a connection
is an organization’s authorization grant to it. The
Creative Engines backend preview provides
discovery, connection setup, and campaign-scoped session reads for enrolled
Buyer Accounts. The Creative Engines Page lets those accounts browse registered
engines and manage their connections. V3 session writes and generation actions
are not included.
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 — A temporary, lossy billing
observation derived from the media buy’s authoritative AdCP BillingParty fact
for legacy rate-card and ledger compatibility. It is not a Seller Account,
execution, campaign, or authentication type and is never a client input. The
deprecated supportedRoutingTypes v2 response field is a behavior-free
placeholder and must not be used for eligibility. 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.
Destination — A place where buyers find a storefront’s Listing,
shown as a tab in Distribution: the Listing card (a PDF, available to
every storefront), then app destinations such as the ChatGPT app, Claude,
Slack, Discord, and WhatsApp. App destinations unlock once Public
distribution (the Listing page’s fourth step) is live; adding one is a
prerequisite-plus-artifact flow — what the destination needs, then the thing
you take away (a download, a request, a published token). See Seller
Pages.
Directed campaign — Deprecated vocabulary. mode: "directed" survives as a
compatibility wire value for campaigns that project exactly one
Seller-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 provider-side activity,
managed when authored through the canonical buyer lifecycle against one Seller. See
Campaigns on connected provider accounts.
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.
Distribution — The set of destinations where buyers find a
storefront’s Listing: the Listing card everyone has, plus app
destinations (the ChatGPT app today; Claude, Slack, Discord, and WhatsApp
coming soon) that unlock once Public distribution (the fourth step on the
Listing page) goes live. The Distribution package is the paid upgrade a
storefront adds to unlock its own public listing domain and every app
destination; it does not change ranking or presence in the Interchange
marketplace, which is its own switch (Listing step three). A storefront
that hasn’t published yet is a state, “Not listed yet,” never a step to
select, and an already-listed storefront returns to it by turning off the
Listed on Interchange marketplace switch (step three), with confirmation,
on the Listing seller UI page. See
Publisher domains
and Seller Pages.
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
Endorsement — Your mark that a Pair is a good answer to its brief. Endorsed pairs can shape later responses; removing the endorsement keeps the pair and its commentary. 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.
External advertiser — An advertiser operated by a buyer and connected to
your storefront over AdCP. You see the buyer’s activity with you, never their
campaign container.
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. 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.
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.
A duration_ms_exact value names a nominal spot length, not a
frame-exact requirement — see Pinned duration. A duration_ms_range is
enforced exactly as written.
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
Imported brief — A historical RFP added withorigin: imported, rather
than received as live or uploaded demand. It can form a Pair
but is excluded from the Demand Inbox scoreboard. See
Demand inbox.
Inbound AdCP campaign — A directed buyer campaign created when an external AdCP
client calls an enrolled Interchange-hosted Seller. The Seller Account 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, Seller Account, Murph, and other rated workloads while preserving
usage attribution for each. The standard IU Rate Card is not yet published in
production. New Rate Cards have three published activities: Brief response,
Enhanced Reporting, and Interchange media buy. A Rate Card accepted
under an earlier catalog keeps its original terms. During the controlled pilot,
a published activity may draw from the accepted IU balance and appear as usage
while monetary charging, invoices, and payment collection remain off. Monetary
charging begins only when it is explicitly 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, Seller Account, 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 Seller Account.
Comes in four kinds, distinguished by executionType: Ad Server, Sales
Agent, Modular source, and Linked source (each defined in this
glossary). A Seller Account can connect several. An inventory source can answer live
passthrough calls, expose cached components for merchandising, or both. See
Choosing a source.
L
Library — The Material and responses a seller uses to sell, including paired proposals, endorsed examples, and reusable slides. It is the canonical home for product marketing, not the advertiser creative library buyers use for campaign creatives. See Library. Library request — A recorded gap the agent encountered while composing, closed by an uploaded file or material a seller tells Murph. See Library requests. 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 Sellers 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.
Listing (previously called the media kit or Discovery Card) — The seller
identity buyers see in Marketplace: resolved name/logo, short description,
website, channels, and accepted countries. Managed storefronts declare
coverage; a pure pass-through storefront uses
upstream capabilities and leaves unknown fields unknown (a mixed or
BOTH-capable storefront declares coverage locally for its Storefront-built
sources). A channel app listing — for example the
ChatGPT app listing — is a read-only projection of it, not a separate object.
It may also show optional Advertising Policies: selected public Business
Rules text for a Seller Account on Listing or Merchandising. Source-native AdCP
policies from a connected sales agent remain independently applicable; a
legacy pure pass-through storefront without local rules shows only that
upstream disclosure. The listing is a storefront projection, not a V3 noun.
Not to be confused with the plan-catalog sense of “listing” used elsewhere for
IU rate cards. “Media kit” is retired for this object — see the
industry-collision note under Media kit below. The deprecated media_kit
V3 compatibility kind is a different, older object (Business Profile) that the
v3 agent surface now also spells listing; see media_kit (retired API
name) below for that alias. See Seller Pages.
The buyer-visible Listing object is distinct from the Seller Account package
also named Listing. The object is what buyers see; the package governs the
seller’s access to Interchange tools.
Sellers manage it on the Listing page (the retired Branding &
distribution page redirects here) as four steps completed in order:
Identity, What you do, Listed on Interchange marketplace (a switch), and
Public distribution — the gate for every Destination beyond the Listing
card. See Seller Pages.
Listing card — A downloadable PDF of a storefront’s live Listing, always
available as the first tab in Distribution, whether or not the
Distribution package is added. It always matches what is currently live.
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 audio source — An inspected WAV or MP3 a buyer uploaded to private Interchange storage, held under an opaque owner-scopedsource_uid rather than
a URL. Its bytes stay private. A promoted source is eligible for a
server-issued, bounded, revocable hosted HTTPS publication. Its adoption
contract is available only when both the account capability and bounded origin
are explicitly enabled; this change enables neither. When enabled, it returns
opaque identities and the hosted asset URL, never a storage reference; a
campaign association records manifest membership only and never sends to a
seller or destination, attaches to a media buy, or makes anything live.
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 Seller by name. The platform sends instructions down;
the execution system remains the source of truth. Contrast tracked
campaign.
Managed video source — A large video a buyer uploaded directly to private
Interchange storage, held under an opaque owner-scoped source_uid rather than
a URL. The bytes stay private: a source becomes deliverable only once it is
promoted and published as a bounded, revocable hosted HTTPS URL — the value
a creative uses, whether you assemble the creative by hand around that URL or
adopt the source directly with adopt_managed_video_source. See
Video creatives.
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 Seller’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-Seller 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.
Material — Seller-owned evidence or teaching input saved through the v3
agent surface, such as a media kit, deck, image, site, spreadsheet, inline
note, or historical reference. Each source refresh is an immutable revision;
Material can inform composition but does not own products, inventory, pricing,
Playbook instructions, or AI Business Rules. See
Seller workflows.
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 — Retired as the name for the seller identity buyers see in
Marketplace; see Listing. The industry reads “media kit” as including
merchandising material — audience stats, products, rates — which the listing
does not contain, so this term now refers only to Product Marketing source
material (see the retired media_kit compatibility API name below and
Product marketing).
Advertising Policies — Optional buyer-visible policy text on a listing.
A Seller Account on Listing or Merchandising elects whether Brief Acceptance,
Creative Policy, both, or neither are disclosed from its local AI Business
Rules. Approval mode, approvers, routing, per-buyer overrides, and revision
notes remain private. Source-native AdCP policy from
media_buy.portfolio.advertising_policies remains independently applicable; a
legacy pure pass-through storefront without local rules shows that upstream
value read-only.
media_kit (retired API name) — Historical name for the Business Profile
and its compatibility API. This is not the buyer-visible listing (see
Listing above); the ingredient itself is now your product marketing
material. See Product marketing.
As of 2026-09-01, the v3 agent surface spells this same deprecated
compatibility kind and Page listing (its canonical wire name); media_kit
is still accepted as a deprecated alias for the identical handler. The
rename is wire vocabulary only — despite the name, get(kind: "listing") and
save_media_kit still return and write the legacy Business Profile, not the
buyer-visible Listing. Every response is marked deprecated: true and points
to get({ kind: "seller", include: ["discoveryCard"] }) and save_seller,
which are the buyer-visible Listing.
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.
Material — A versioned teaching source a seller adds from a URL, site,
upload, crawl manifest, inline text, or prior work. A Material keeps the exact
source revision, relevance and confidentiality scope, review suggestions, and
confirmation receipts; it is evidence for Seller configuration rather than a
replacement for products, pricing, Playbook, AI Business Rules, signals, or Seller
identity. See Seller workflows.
Material candidate — An evidence-backed suggestion extracted from one
exact Material revision for a seller to review. A writable candidate names the
existing save tool and schema-valid arguments that can confirm it; an
unwritable candidate explains what is missing or unsafe. Reading, rejecting,
or correcting a candidate does not change Seller configuration.
Material confirmation receipt — The bounded record returned after a seller
explicitly confirms a writable Material candidate through the save tool named
in it. The receipt links the saved record to the Material ID, source revision,
candidate ID, and destination identity, and is available from
get(material).
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 inputs steer it — Product Marketing, Playbook, and AI 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.
Merchandising claim — Retired name for a Selling point. See
Product marketing.
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.
Custom modular sources is the customer-facing name for customer-specific
source composition included with Premium and Enterprise through the
Merchandising profile. Its stable internal feature key is modular-sources; it
is not a separate entitlement. Standard managed integrations are included with
every seller plan.
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.
Notification subscription: The authored record behind a Scope3 alert. It
names what it watches (scope and content), when it fires (a schedule, or a
typed condition), where it goes (route references), and who may change it
(provenance: user, contract, plan, or system, each with its own
mutability over disabling it, its trigger, or its routes). A subscription
decides whether and when you’re told something; the resulting notification,
and your read or acknowledged state on it, are separate records. No trigger
type fires yet — an Intelligence Unit (IU) allowance-consumption condition is
the first one planned. See
Notifications.
O
Organization API key — A WorkOS-managed credential shared by a script or automation owned by an organization rather than one person. Existing organization keys remain available during migration, but new integrations use user API keys. 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, Seller Account, 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 takes effect. 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. Each version also carries the storefront’s Selling Doctrine. See the Storefront guide. Storefront adapter — A supported expert integration that dispatches the entire buyer-facing storefront directly. It is configured as storefrontADAPTER 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 — A container that groups explicitly attached Buyer and Seller
accounts and can own a sales agent offering. It owns the shared contract, Terms
of Service, IU plan and wallet, billing Standing (Funded balance,
Credit line), and organization administrators. A standalone account is not
silently attached because its email domain or CRM company matches. 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
Participant roster — The list of provider identities observed in an account-owned support channel. Presence on the list is review evidence, not Interchange account authorization. See Review support channel participants. Pair — A brief joined to its response, seller commentary, and commercial outcome. An endorsed pair is an evaluation example; a response without a brief is a standalone shape example, not an evaluation. See Responses and pairs. Promoted — The state a managed video or managed audio source reaches after its uploaded bytes pass digest and media inspection against the exact pinned storage generation. Only a promoted source can be published as a hosted HTTPS URL for a hand-built creative or adopted directly into a creative manifest; anything earlier has not been verified. See Managed video source and Managed audio source. 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.
Pinned duration — A duration_ms_exact value on a canonical format option
(duration_ms_exact: 15000). How closely a creative must match it depends on
where the value came from:
- A pin carried over from a legacy format id — a seller still publishing
format_idslikeaudio_15s, whose duration is part of the name — is matched within 100ms either side. Duration measurement is not exact to the millisecond: an MP3 without a Xing header is measured from its byte rate, so re-tagging the same audio moves the number, and with a Xing header the value snaps to the MPEG frame grid (26.12ms at 44.1kHz, so exactly 15000ms is not even representable — 574 frames is 14994ms and 575 is 15020ms). Both a 14994ms and a 15047ms master satisfy such a pin. - A pin the seller declared directly in a canonical
format_optionsentry is their stated requirement and is matched exactly.
duration_ms_range carries no tolerance in either case; a seller who states a
window has stated its edges, and both ends are enforced as written. Sellers:
if you accept a genuine range, declare duration_ms_range rather than an exact
pin.
When a product declares several options of the same format_kind that differ
only by pinned duration, name the one you want with format_option_refs[] — a
creative that carries only format_kind is ambiguous against such a product and
will not attach.
Payout details — The bank account a Seller Account 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.
Pitch — The written argument a proposal pass can carry alongside its
plan: the thesis, the buyer’s brief mirrored back, the plan told as roles in
a strategy, how success will be measured, the case for the price, an honest
counter for what your catalogue lacks, and the invitation. Every sentence
cites at least one real source — the buyer’s brief, your inventory and
product data, your Playbook pricing, or your Playbook instructions — or it is
dropped before it renders; nothing composes unsourced. Seller-side only
today: it renders on your demand inbox
pass, not on what a buyer’s agent receives from get_products. See
The pitch.
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.
Principal — A seller-issued identity for one caller, named by an opaque
principal_id (for example prin_yq8Kd…). A principal is a routing and audit
handle, never a credential and never a grant: every principal reports empty
authority, so holding one gives no advertiser, account, spend, payment, or
Terms access. Two kinds exist — a buyer-agent principal (one automation your
organization runs, which holds credentials you administer) and an operator
principal (your organization acting as itself, created the first time an
organization credential calls Interchange, holding no administrable
credentials). Its lifecycle state is active, suspended, or retired; a
buyer agent is suspended once it has no active credential left, and its
principal_id is retained for audit and never reissued. See
Buyer-agent credentials.
Credential fact — Any identifier that describes a credential rather than
the Principal it authenticates: an OAuth client ID, an API key ID, an issuer
URL, a WorkOS organization ID, an operator domain, a brand.json or JWKS URL, a
signing key ID, a key fingerprint. Credential facts change when a credential is
rotated or replaced while the principal_id stays the same, and two credentials
associated with one buyer agent have different facts. A credential fact is
therefore never identity and must not be used as one. See
Buyer-agent credentials.
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.
Product marketing — Your own marketing material — media-kit site,
template decks, one-sheets, package menus, case studies, audience cards, spec
sheets, seasonal calendars — taught to the Merchandising Agent as versioned
entries (by link or upload), so it learns how you merchandise. Confirming the
same source again lands as a new version rather than a duplicate. What it
teaches the agent is a Selling point; each checkable one is reconciled
against your live inventory and verdicted Backed or Not backed (the
API reports the latter as gap), holding back a proven not-backed selling
point from shaping proposals. Retired names: Media Kit, Product
marketing corpus. See
Product marketing.
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.
Property Roster — The storefront’s canonical list of the properties it
sells or claims to sell: every Property its publishers declare plus the
domains the seller has claimed, grouped by publisher, each carrying its
authorization state (authorized, unauthorized, or unknown, resolved from
the publisher’s adagents.json; a domain whose file is still being
resolved shows as pending), any publisher-declared AdCP Collections, and the
creative formats discovered for each publisher — each labeled with its
provenance, declared by the publisher or imported from the AAO community
registry.
Authorization is a per-publisher state on the roster, not an admission
requirement — a seller can claim domains before their publishers formally
authorize the agent, and an unauthorized result warns during setup and product
authoring rather than blocking them. Buyer-facing surfaces are stricter:
storefront discovery hides unauthorized publishers, and managed product
coverage (publisher_properties) disclosed by Scope3’s embedded agent is
limited to the authorized set. A third-party agent’s complete products carry
that agent’s own declared coverage. The roster answers
“which sites, apps, and channels do I sell — and which of their publishers
have formally authorized me?” See
Publisher properties and coverage
and Identity documents.
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.
Q
Quick RFP — A seller RFP origin with bounded preset dimensions. Live Quick RFPs with a typed preset can reuse a dependency-versioned response skeleton while rescanning and reloading current commercial facts and applying current request inputs. Draft and evaluation turns, bounded legacy presets, and Quick origins without a preset compose normally but bypass caching. See Seller RFP lifecycle.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. Rendition (Material) — A versioned, derived view of one immutable Material source revision. It preserves supported page, slide, or sheet structure, semantic blocks, and reusable visual assets with stable source locations and extraction provenance; per-facet completeness states make unsupported or degraded interpretation explicit. Reusable slide — A slide from an uploaded deck or one-sheet that a seller marks reusable. It cannot carry a price of its own; a slide with pricing stays non-reusable until that figure is replaced with a rate-card value. See Reusable slides. 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. RFP — A seller-side record of one buyer request as it moves through response composition, review, release, feedback, and commercial outcome. It is not the buyer’s canonical AdCP Proposal. Revisions add immutable RFP turns instead of rewriting prior work. See the Seller RFP lifecycle. RFP turn — One immutable request-and-response revision inside an RFP. A turn records its purpose, origin, terminal response state, evaluation, exact composition receipt, feedback, and outcome attribution. See the Seller RFP lifecycle.S
Shape projection — The safe part of an endorsed pair the agent can use for a different buyer: block selection and order, seller positioning, and seller commentary. It excludes the other buyer’s identity, contacts, brief, budget, rates, and response text. See How your agent uses the Library. Selling Doctrine — A seller’s strategy for when to answer a brief and how hard to argue: a minimum category fit to respond, a counter appetite, and a floor posture, alongside the Playbook prose that shapes the argument itself. Versioned and activated as part of Operating Instructions rather than as a separate object, so reverting is activating the prior version. Ships with named starting points —premium_scarcity_house, volume_partner, and
consultative — that a seller adopts or edits. A storefront that has never set
one has no qualification gate at all and keeps pitching every brief it can
compose for; that state reads back as house_default, whose numbers are
display values rather than active thresholds, and is not adoptable by name
because it IS the absence of a doctrine. Doctrine governs judgment, never truth: it
selects and shapes claims, it cannot mint facts. See
Selling doctrine.
Selling point — One statement from your Product marketing material
about how you package, position, or prove your inventory — kept in your own
words, with the attribution it actually has: the verbatim quote and location
when it came from a document we parsed, the stated reason when that document
had nothing quotable, or “from you” when your agent presents it to buyers as
your own claim — because it’s your account of a page (media-kit links are not
fetched today), or, for a case-study story, material that hasn’t yet been
matched to an exact quote, whether that story came from a page or a document.
A selling point that makes a
checkable promise (a channel, a creative format, an audience signal) carries a
verdict against your live catalog — Backed or Not backed (the API
reports the latter as gap); a selling point with nothing checkable, or one
not yet checked, carries no verdict at all. A Not backed selling point is
held back from shaping proposals until you add the inventory it promises or
withdraw it. Retired name: Merchandising claim. See
Product marketing.
Settlement currency / Payment currencies — An Interchange-cleared Seller Account
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 Seller Accounts, 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 Seller Account cannot sell a pricing option in
a currency outside the set. Discovery only surfaces a product to a buyer in a
currency the Seller Account 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 Seller Account need not set it. Direct
sales adapter Sellers 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
Seller Account’s payment set via FX — see Cross-currency buying.
Cross-currency buying (FX) — Lets a buyer transact in a currency the Seller Account
does not settle in. The operator decides which currencies its Seller Account
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-Seller 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 Seller Account’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. For a Seller Account, an
external sales-agent source is a separate AdCP agent registered by URL
(executionType: AGENT) — distinct from the hosted Seller 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
Seller Account. 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 Account — An Interchange Account whose role is SELLER: the
private workspace where members, permissions, API keys, inventory, policies,
and seller operations live. It also supplies the public commercial identity
and transaction surface that buyers see as a Seller. Legacy v2 APIs call
this object a Storefront. Do not
use this term for an external ad-platform or AdCP account connected by a buyer;
that is a Connected provider account.
Seller-managed campaign — Retired product name. What it described is now a
tracked campaign (management: "tracked"): a read-only shell mirrored from
a connected provider account the platform did not set up. The compatibility API
value remains mode: "directed". See
Campaigns on connected provider accounts.
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.
Earlier docs and some in-product copy call this a signal component. It is
the same thing. Every API operation has always used
signal (create_signal,
list_esa_signals), and the docs now match.domain=<url domain>), so the platform carries
that mapping 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 mapping 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. Seller Account 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 legacy v2 name for a Seller Account, retained in v2
paths, operation names, response fields, and internal storage. New product and
v3 language uses Seller Account for the sell-side workspace and Seller
for the buyer-facing counterparty. See the legacy
Storefront guide.
Storefront selection — The account-wide decision that a buyer account
wants one Storefront available for activation. Always include and Always
exclude override automatic selection; Return to default restores it.
Selection is not owned by an advertiser, although advertiser markets and
channels are inputs to automatic selection. See
Storefronts.
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 Seller Accounts 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 provider 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 upstream campaign changes — 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
User API key — A WorkOS-managed credential that acts as the user who created it. Its effective access is the intersection of that user’s current account and resource authorization in the key’s organization with the key’s selected action scopes. A dedicated service user can own a durable headless integration. See Authentication. 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, so a buy or generation request that needs it is rejected until you relink the platform or re-map the account rather than silently using another account. The mapping then recovers automatically. See Ad Platform Accounts.W
Workflow skill — A bounded, versioned set of instructions that teaches an AI agent how to complete a client job safely with Interchange. A workflow skill can declare required tools, supporting assets, applicability, and evaluation scenarios; it does not grant permissions or prove completion. See AI Agent Skills. Work item — Something the platform is waiting on a seller for. Three kinds share the term: a creative review, a media-buy approval, and a modular source follow-up — a source-side task a modular inventory source raises for itself, such as confirming avails or resolving a trafficking error. The first two are decisions and usepending/approved/rejected/
revoked; the third is a task and uses
OPEN/IN_PROGRESS/BLOCKED/COMPLETED/CANCELLED. Deciding is not the
same as delivering: an approved media buy carries its own forwarding evidence,
and an approval with no forwarding timestamp is reconciliation work rather than
a completed one. See v3 Agent Surface (preview).