Skip to main content
A brief gives a seller the campaign meaning needed for curation. It is not a second schema written in prose. Buyers preserve goals, context, semantic intent, preferences, and requirements without a structured AdCP representation in the brief; they put machine-representable facts in typed fields.

​
When a brief is used

For buying_mode: "brief", brief is required. For buying_mode: "wholesale", omit brief. For buying_mode: "refine", omit brief and use the refine array instead. The brand field is optional for get_products unless the request includes catalog. When supplied, the seller may use it to apply general policy rules or limit discovery. A create_media_buy request always must include brand. Offer filters remain hard in every lifecycle. The task changes curation and state behavior, not whether filters apply. The split tasks name them criteria.offer_filters; legacy get_products names the equivalent field filters.

​
Decompose the buyer request

Anything that has a structured AdCP field SHOULD use it. This costs fewer tokens, can be validated and applied by code, and avoids lossy prose extraction.

​
Structured-first example

The seller curates for the semantic audience and contexts, excludes offers that fail the product filters, scopes every returned forecast and price to the US age predicate, and returns only products that let packages select Nielsen DMA values later. The request does not ask for one product per DMA.

​
Hard requirements in prose

An explicit hard requirement remains binding even when the buyer puts it only in the brief. A seller MUST NOT downgrade “US only” or “must exclude news” to a preference merely because it was written in prose. When hard targeting came from prose and the seller’s structured interpretation materially affects product eligibility, pricing, or forecasting, the seller MUST confirm that interpretation in response-root targeting_resolution.brief_targeting for request_proposals and get_products, or in the affected refine_proposals.results[] entry when the interpretation came from the refinement ask. In other cases the seller SHOULD still confirm it as a best practice. Requirements without a typed AdCP representation remain visible in the natural-language response. brief_targeting is confirmation, not a counteroffer. If a product cannot honor the seller’s literal interpretation of a hard prose constraint, the seller omits that product. Structured modifications apply only to a buyer’s explicit targeting_overlay proposal flow. If prose contradicts a structured field, the seller MUST reject the request as INVALID_REQUEST rather than silently choose one interpretation. The buyer corrects the contradiction and retries.

​
How buyers evaluate targeting resolution

Unchanged structured overlays are not repeated. This prevents large values such as hundreds of postal codes from bouncing through discovery responses.

​
What belongs in the brief

Useful brief content includes:
  • business objective and why the campaign exists;
  • semantic audience meaning such as “outdoor enthusiasts” or “IT decision makers modernizing cloud infrastructure”;
  • creative and product context;
  • success priorities and tradeoffs not captured by typed metrics;
  • sensitive adjacency or competitive context without a typed control;
  • soft preferences, clearly distinguished from hard requirements.
Do not duplicate exact dates, budget, currency, channels, formats, geography, demographic predicates, or other values already carried in structured fields.

​
Seller processing

For request_proposals, sellers:
  1. Validate structured fields before natural-language interpretation.
  2. Reject contradictions between hard prose and structured fields.
  3. Apply filters, targeting, and required future-support matching.
  4. Interpret the remaining brief for curation and relevance.
  5. Scope product pricing and forecasts to effective targeting.
  6. Return draft proposals with brief_relevance where useful and disclose targeting resolution.
Sellers may ask focused clarification questions when semantic intent is too ambiguous to curate responsibly. They do not need clarification for exact values already supplied structurally.

​
Listing and refinement

Listing is not “targeting later.” It is non-curated product-feed behavior. Buyers may still send offer_filters, targeting_overlay, and required_overlay_support; returned products must honor them exactly as in proposal mode. The legacy get_products wholesale mode has the same rule. For action: "revise", refine requests are self-contained through opaque product/proposal IDs plus structured fields, a semantic ask, or both. action: "finalize" changes no commercial or targeting terms and cannot carry revision fields. See Refining products and proposals.

​
Implementation checklist

​
Buyers

  • Preserve business language and semantic intent in brief.
  • Extract machine-representable facts into structured fields.
  • Mark hard versus preferred requirements clearly.
  • Inspect every targeting resolution before selecting a product.
  • Treat configured product IDs as opaque and context-bound until expires_at.

​
Sellers

  • Apply hard requirements in every request surface.
  • Never infer a structured value when the buyer already supplied it.
  • Never silently resolve a contradiction or unsupported constraint.
  • Confirm brief-derived targeting when possible.
  • Bind effective targeting, price, forecast, and terms to the returned product.