Skip to main content
Jordan sits at her desk studying a dense brand safety spreadsheet on her monitor — rows of partner names and excluded programs that need to become machine-readable Jordan is staring at a spreadsheet. A holding company just sent Nova Motors’ CTV “do not air” list — 200+ programs organized by network, a mix of specific shows, entire genres, and content ratings. Some entries are app-level exclusions. Some are individual programs that air on five different platforms. One section says “ALWAYS EXCLUDE kids programming” and three rows later says “animation rated G or PG is permitted.” This spreadsheet makes sense to a human trafficking linear TV. It does not make sense to an AI agent managing programmatic CTV across a dozen sellers. Jordan needs to turn this into something machines can enforce. Property lists handle the app-level exclusions — she’s done that before. But the program-level exclusions? A show doesn’t belong to a single app. It airs everywhere. She needs a construct that identifies the program itself, independent of where it runs. That’s what collection lists are for.

​
The gap in brand safety

Three-layer brand safety diagram — properties on top, collections in the middle, content standards at the bottom — Jordan points at the collection layer she is building Before collection lists, AdCP had two brand safety layers:
  • Property lists control where ads run — which apps, sites, and platforms. Jordan can say “not on this news app” and every seller enforces it.
  • Content standards control what content is adjacent to an ad — per-impression evaluation against a natural language policy. They handle nuance like “exclude kids content except G/PG animation.”
The missing layer is what program the ad runs in. A specific crime drama airs on three streaming platforms and cable syndication. Excluding it from one property doesn’t exclude it from the others. Jordan needs to say “not in this program, anywhere” — and have every seller understand what she means. Collection lists fill this gap. Together with property lists and content standards, they form three composable layers: Most buyers use one or two layers. A buyer who only needs to exclude specific programs uses a collection list alone. The three-layer model is a composition framework, not a requirement.

​
Resolving program identifiers

Jordan maps program names to distribution identifiers at a display — green lines connect resolved programs, amber lines show unresolved ones she marks for follow-up The spreadsheet lists programs by name. Machines need identifiers. Jordan’s buyer agent resolves each program name to a platform-independent distribution identifier — an IMDb ID, Gracenote ID, or EIDR ID that uniquely identifies the program regardless of which CTV platform carries it. Most programs resolve immediately. A few don’t — the agent flags these for Jordan to confirm manually. This is the translation step: human-readable names become machine-readable identifiers that every seller in the ecosystem understands. Gracenote ID guidance: Use root-level IDs — SH-prefixed for series, MV-prefixed for movies, SP-prefixed for sports programs. Episode-level IDs (EP-prefixed) don’t belong in collection lists; episode-level evaluation is a content standards concern.

​
Building the collection list

A funnel filters collections through rating, genre, and explicit exclusion layers — Jordan reviews the clean resolved list emerging at the bottom Jordan’s buyer agent creates a collection list on the governance agent, combining explicit program exclusions with structural filters:
The explicit entries handle the named programs. The filters handle the structural exclusions — no TV-MA content, no news genre. The filters are the safety net: any new TV-MA series on any platform is automatically excluded without Jordan updating the list. The “kids vs. G/PG animation” contradiction? That’s not a collection list problem — it requires evaluating actual episode content, not metadata. Jordan puts that in content standards where it belongs.

​
How filters compose

Include filters are allowlists, exclude filters are blocklists. When both are present for the same dimension, include applies first, then exclude narrows further. Example: genres_include: ["drama", "comedy"] + genres_exclude: ["crime"] first includes only drama and comedy collections, then removes any also tagged as crime. A collection tagged ["drama", "crime"] is excluded — the exclude filter wins.

​
Sellers match against their inventory

Split scene — Jordan's governance agent sends the collection list to Priya at StreamHaus, whose inventory lights up showing matched exclusions When Jordan’s product-discovery request references the collection list, Priya’s sales agent at StreamHaus fetches it, matches entries against StreamHaus’s collection inventory, and excludes matched programs from the inventory represented by each returned product. The matching uses distribution identifiers — StreamHaus declared Gracenote IDs on their collections in adagents.json, so the match is automatic. The seller returns the result with each product: for this product, 59 of the list’s 200 resolved entries matched its collection inventory and 141 did not. The product’s list_applications receipt identifies the list snapshot and evaluation time, while its price and forecast reflect the inventory remaining after those 59 matches were excluded. A different product can report different counts from the same list. The list is cached for a week (collection metadata changes less frequently than property metadata). When the governance agent re-resolves the list — a new season changes a show’s content rating, or Jordan adds programs — sellers receive a webhook and refresh their cache.

​
Targeting integration

Collection lists are referenced in targeting overlays alongside property lists:
A media buy can reference both simultaneously — “run in these approved shows, but never in these specific programs even if they appear on the approved list.” The exclude list always wins on overlap.

​
Combining several collection lists (experimental)

Brand-wide and campaign-level lists have different owners and lifecycles, so a package can reference several of them with the plural fields collection_lists and collection_lists_exclude (experimental in AdCP 3.3, feature id media_buy.collection_lists):
A package MUST NOT set both collection_list and collection_lists, or both collection_list_exclude and collection_lists_exclude; the singular fields are unchanged. In a request, set the old field to null when switching to the plural one. Exclude still wins on overlap. If a stored singular field is set, an update that sets the plural field for that direction MUST also null the singular one, otherwise the merged state is rejected with INVALID_REQUEST before any mutation. A seller that does not list media_buy.collection_lists in experimental_features MUST reject these fields with UNSUPPORTED_FEATURE, and a buyer MUST NOT rely on exclusion being applied unless the seller lists it and the product declares matching overlay_support; an older seller may silently ignore unknown fields. List identity is (agent_url, list_id): JSON Schema uniqueItems compares whole objects, so it cannot catch refs that differ only in auth_token. A seller MUST reject a repeated identity within one array, whatever its auth_token, with INVALID_REQUEST before any mutation, and MUST NOT deduplicate, merge, or pick between the entries. Conformance tooling enforces this from x-adcp-validation.unique_by. A seller declares support per product in overlay_support.collection_lists / collection_lists_exclude as true or { "max_references": N }, and a buyer filters with required_overlay_support. Singular support does not imply plural support. A create or update with more references than max_references MUST be rejected with UNSUPPORTED_FEATURE, identifying the field, and MUST NOT be truncated. A seller that cannot resolve every list MUST NOT apply a subset. Property and collection lists use the same product-response receipt. Matching is a seller claim about one returned product at one point in time, not a report written back to the governance agent.

​
Jordan’s three-layer configuration

By the time Jordan is done, Nova Motors’ CTV brand safety is expressed in three machine-readable artifacts:
  1. Property list — excluded apps and approved CTV platforms
  2. Collection list — excluded programs by distribution identifier + TV-MA and news genre filters
  3. Content standards — the nuanced kids/animation policy that requires per-episode judgment
Each layer is independently managed, independently cacheable, and independently enforceable. When the holding company sends an updated do-not-air list next quarter, Jordan’s agent diffs it against the existing collection list and updates only what changed. No more spreadsheets. No more per-network manual trafficking. One list, enforced everywhere.

​
Relationship to property lists

Property lists and collection lists are sibling constructs — both are inventory lists managed by governance agents with the same lifecycle pattern (create, get, update, list, delete, webhook). They differ in what they address:

​
Tasks

​
Collection list management