> ## Documentation Index
> Fetch the complete documentation index at: https://docs.adcontextprotocol.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Policy compliance

> AdCP policy compliance — how publishers enforce brand safety and regulatory checks during product discovery and media buy creation. Includes policy types and violation handling.

AdCP includes comprehensive policy compliance features to ensure brand safety and regulatory compliance across all advertising operations. This document explains how publishers should implement and enforce policy checks throughout the media buying lifecycle.

## Acceptance-policy discovery

Seller acceptance policy answers a narrower question than buyer governance: **what business, campaign, creative, targeting, destination, and format will this seller accept?** It does not give the seller authority over the buyer's plan and does not expose the seller's internal review workflow.

A seller that supports structured discovery publishes `media_buy.acceptance_policy_discovery` from `get_adcp_capabilities`:

```json theme={null}
{
  "catalog_url": "https://seller.example/.well-known/adcp-acceptance-policies.json",
  "catalog_digest": "sha256:54f04c3e2e8dfdf682b0da0cd0ee4d5265e54a6e0f72b9260785dfc1526fd08a",
  "default_profile_ids": ["seller-default", "us-political"]
}
```

The HTTPS document at `catalog_url` conforms to `acceptance-policy-catalog.json`. Each local `profiles[]` entry declares `coverage: "partial"` or `"complete"` and contains rules with a `disposition` of `allowed`, `conditional`, or `prohibited`. Conditional rules carry typed requirements such as advertiser verification, prior authorization, disclosure, targeting restrictions, or sales-assisted setup. Every `policy_ids[]` value resolves through that profile's digest- and version-pinned `policy_refs[]`. The profile's own `content_digest` covers its RFC 8785 canonical form with that field omitted, making a profile ID/version immutable. Registry-published platform policies may include a reusable `acceptance_profile`; a seller adopts it through `registry_profiles[]`, which pins both policy and profile versions and digests. For each adoption, resolve the exact policy version, RFC 8785-canonicalize the resolver's `canonical_content`, and require its SHA-256 to equal both the resolver `content_digest` and the pinned `policy_digest`; null canonical content or a mismatch fails closed. Verify `profile_digest` separately against the embedded profile. The seller MUST NOT copy and alter a registry profile under the same identity; seller-specific restrictions use a separate local profile and compose restrictively. A profile ID may occur only once across a catalog's local and registry lists. Registry publication alone never binds a seller.

Products may add `acceptance_policy_profile_ids[]`. Resolve the seller defaults and every product profile referenced by the contemplated purchase. All selected profiles apply; for matching rules, `prohibited` wins over `conditional`, which wins over `allowed`. A missing capability, an omitted rule in a partial profile, or missing buyer facts means **unknown**, never allowed. `complete` is exhaustive only for that profile's declared scope and version; the scope explicitly names countries, declared region aliases, or `all_jurisdictions: true` so omission cannot be mistaken for worldwide coverage.

A rule matches the decision surface when `applies_to[]` contains that surface and its `subject_category` equals a declared subject. Omitted `subject_facets`, `advertiser_roles`, `jurisdictions`, or `jurisdiction_groups` are wildcards; when present, each dimension must intersect the corresponding buyer fact. Expand `jurisdiction_groups` only through the containing profile's `region_aliases`; an unknown alias invalidates the profile and never matches permissively. Evaluate every matching rule independently, then choose the most restrictive disposition. Platforms with an exception to a broad prohibition represent it with non-overlapping facets or roles—for example, prohibit persuasive election facets while making `government_information` conditional for an `election_authority`. A request carrying both the exception facet and a prohibited advocacy facet remains prohibited.

Buyers may send `acceptance_context` on discovery with registry category IDs, optional category facets, advertiser roles, industry, advertiser jurisdictions, and delivery jurisdictions. `advertiser_jurisdictions` says where the advertiser is established; `delivery_jurisdictions` says where ads will run and is the field matched by rule `jurisdictions` and `jurisdiction_groups`. For example, `political_advertising` is the broad category; facets distinguish candidate or party ads, election or ballot-measure ads, issue advocacy, legislation or regulation, government information, political merchandise, and incidental or news references. This avoids a single ambiguous `political: true` flag while allowing future registry categories and facets without changing the protocol schema.

Discovery is advisory. Sellers may intentionally publish only partial rules, may apply account-specific or newly effective policies at execution time, and remain authoritative for an exact request. Buyer declarations are untrusted hints: sellers MUST classify creatives, destinations, advertiser identity, and targeting independently when those facts affect acceptance. Omitting or mislabeling a category or facet cannot bypass seller enforcement. A buyer MUST therefore handle a later structured `POLICY_VIOLATION` even when discovery appeared to allow the campaign. The catalog digest detects stale or substituted catalogs; it is not an acceptance guarantee.

Fetch `catalog_url` as untrusted remote configuration: require HTTPS, apply the shared URL canonicalization and public-network fetch protections, do not follow redirects, do not send seller or buyer credentials, pin DNS through connection, and bound time and response size. Verify the digest over the exact received bytes before parsing or caching. Resolve every `registry_profiles[]` reference from the shared registry at the exact policy and profile versions and verify both digests; a missing or mismatched reference is unknown and cannot fall back to a same-named local profile. Profile and rule descriptions are display-only untrusted text; matching uses typed fields only, and implementations MUST NOT place that prose into a privileged instruction context. Cache by canonical URL plus digest, never by URL alone. Buyers can request `acceptance_policy_profile_ids` explicitly through either discovery surface's `fields` projection.

## Overview

Policy compliance in AdCP uses the `brand` field when advertiser-specific context is available. `brand` is optional for `get_products` unless the request includes `catalog`; it is required for `create_media_buy`. Brand context enables publishers to:

* Filter inappropriate advertisers before showing inventory
* Enforce category-specific restrictions
* Maintain brand safety standards
* Comply with regulatory requirements

## Brand

Buyers should include `brand` in `get_products` when the advertiser is known so sellers can return context-rich recommendations and apply advertiser-specific policy checks. A catalog-bearing `get_products` request must include `brand`, and every `create_media_buy` request must include `brand`.

```json theme={null}
{
  "brand": {
    "domain": "acmecorp.com"
  }
}
```

The brand domain resolves `/.well-known/brand.json`. On a single-brand domain, `brand_id` can be omitted. On a house or portfolio domain, use `brand_id` to select the intended entry. The selected entry provides:

* **Brand name and identity** for verification
* **Industries** for policy filtering
* **Brand assets** for creative compliance

Callers can supply `brand.industries` as a per-request override when the canonical entry is missing or does not describe the campaign's current industry context. When that field is absent, sellers and governance agents resolve `industries` from the selected `brand.json` entry.

Combined with the `brief` field (which describes what's being promoted), publishers have fuller context for policy decisions. When `brand` is absent from a non-catalog discovery request, a seller may apply general policy rules or limit the products it returns rather than perform advertiser-specific checks.

For comprehensive guidance on briefs and brand information, see [Brief Expectations](/dist/docs/3.2.0-beta.9/media-buy/product-discovery/brief-expectations).

## Policy check implementation

Publishers must implement policy checks at two key points in the workflow:

### 1. During product discovery (`get_products`)

When a `get_products` request is received, the publisher should:

1. Require `brand` when `catalog` is present
2. When `brand` is present, validate it and resolve the selected brand entry and its `industries`
3. Apply advertiser-specific policy checks when that context is available
4. Otherwise, apply general policy rules or limit discovery
5. Filter out unsuitable products

**Example policy context resolution:**

```python theme={null}
def resolve_policy_industries(brand: dict | None) -> list[str] | None:
    if brand is None:
        return None

    manifest = fetch_brand_json(brand["domain"])
    brand_entry = select_brand_entry(manifest, brand.get("brand_id"))

    if "industries" in brand:
        return brand["industries"]
    return brand_entry.get("industries", [])
```

If this function returns `None`, apply general discovery policy or limit the returned products. Otherwise, evaluate policy against the resolved industries and any other applicable request context.

### 2. During media buy creation (`create_media_buy`)

When creating a media buy, the publisher must first require `brand`, then:

1. Validate the `brand` against publisher policies
2. Ensure consistency with the campaign brief
3. Apply the seller's internal review policy if needed
4. Return appropriate errors for violations

## Policy outcomes

AdCP does not define a separate policy-compliance status or response field. Use the task status and error model that matches the outcome.

### Products can be returned

When policy checks pass, return the ordinary completed response. An empty `products` array means the search completed but no products matched.

```json theme={null}
{
  "status": "completed",
  "products": [],
  "cache_scope": "public",
  "message": "No products matched the request."
}
```

### More information is needed

Use `input-required` only when the buyer must supply information before the seller can continue. Include `task_id` and `context_id` so the buyer can continue the same task, plus the status-specific reason and optional suggestions.

```json theme={null}
{
  "status": "input-required",
  "task_id": "task_policy_clarification_001",
  "context_id": "ctx_policy_clarification_001",
  "message": "Which country will this campaign target?",
  "reason": "CLARIFICATION_NEEDED",
  "suggestions": ["United States", "Canada"]
}
```

### Seller-side review continues asynchronously

Seller-internal review does not require buyer input or protocol-level approval orchestration. When a well-formed `brief` or `refine` request cannot finish within the current time budget, return `submitted` with a `task_id`; use `working` for subsequent progress. Those states communicate task completion only—the seller may use people, automation, or both internally. Wholesale discovery is synchronous and does not use these async states.

### The seller declines a well-formed request

When the request is valid and understood but the seller makes a business decision not to offer products, use the typed `rejected` outcome. This remains a successful transport response.

```json theme={null}
{
  "status": "rejected",
  "reason": "This publisher does not offer inventory for the requested campaign.",
  "suggestions": ["Try a different channel or publisher."]
}
```

### The request violates a policy

When the request itself violates an applicable content or advertising policy and can be corrected, return a failed response with `POLICY_VIOLATION`. Populate `errors[]` and mirror the fatal error in `adcp_error` so clients can handle both response layers.

```json theme={null}
{
  "status": "failed",
  "message": "The request violates an applicable advertising policy.",
  "errors": [
    {
      "code": "POLICY_VIOLATION",
      "message": "The requested campaign is not permitted on this inventory.",
      "field": "brand",
      "recovery": "correctable",
      "details": {
        "seller_policy_ref": "restricted-industries-rule-4",
        "policy_url": "https://publisher.example/policies/restricted-industries",
        "violated_rules": ["restricted-industry"]
      }
    }
  ],
  "adcp_error": {
    "code": "POLICY_VIOLATION",
    "message": "The requested campaign is not permitted on this inventory.",
    "field": "brand",
    "recovery": "correctable"
  }
}
```

## Creative Validation

All uploaded creatives should be validated against the declared brand identity:

1. **Automated Analysis**: Use creative recognition to verify brand consistency
2. **Human Review**: Manual verification for sensitive categories
3. **Continuous Monitoring**: Ongoing checks during campaign delivery

This ensures:

* Creative content matches the declared brand
* No misleading or deceptive advertising
* Brand safety for all parties

## Common Policy Categories

Publishers typically implement restrictions for:

### Blocked Categories

* Illegal products or services
* Prohibited content (varies by region)
* Categories requiring special licensing

### Restricted Categories (Conditional Acceptance)

* Alcohol (may require age-gating)
* Gambling/Gaming
* Cryptocurrency/Financial services
* Political advertising
* Healthcare/Pharmaceuticals
* Dating services

### Special Requirements

* Political ads may require disclosure
* Healthcare may need disclaimers
* Financial services need compliance review

## Implementation Best Practices

1. **Clear Communication**: Provide specific reasons for restrictions
2. **Contact Information**: Include sales contact for restricted categories
3. **Consistent Enforcement**: Apply policies uniformly across all advertisers
4. **Documentation**: Maintain clear policy documentation for advertisers
5. **Appeals Process**: Allow advertisers to request policy exceptions

## Internal review and buyer interaction

Keep the two human-in-the-loop paths distinct:

* **Buyer clarification:** Return `input-required` only when the buyer must answer a question. Include `task_id` and `context_id`, then continue that task context after the buyer responds.
* **Seller-internal review:** Keep the review mechanism private. For `brief` or `refine`, return `submitted` when the task cannot finish within the current time budget and `working` while it remains active. Do not use `input-required` merely because a seller-side process is involved.

After review, return the canonical completed, rejected, or failed outcome.

## Related Documentation

* [`get_products`](/dist/docs/3.2.0-beta.9/media-buy/task-reference/get_products) - Product discovery with policy checks
* [`create_media_buy`](/dist/docs/3.2.0-beta.9/media-buy/task-reference/create_media_buy) - Media buy creation with validation
* [Accounts & Security](/dist/docs/3.2.0-beta.9/media-buy/advanced-topics/accounts-and-security) - Authentication and authorization