> ## 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 Registry

> The AdCP Policy Registry is a shared library of machine-readable compliance policies that governance agents reference by ID during campaign validation.

The Policy Registry is a community-maintained library of standardized, machine-readable advertising policies. It provides a shared vocabulary of regulations and industry standards that any governance domain can reference by ID.

## Quick start

Fetch a policy by ID:

```bash theme={null}
curl https://adcontextprotocol.org/api/policies/resolve?policy_id=us_coppa
```

List all regulation-category policies:

```bash theme={null}
curl https://adcontextprotocol.org/api/policies/registry?category=regulation
```

Bulk-resolve policies for an LLM evaluation prompt:

```bash theme={null}
curl -X POST https://adcontextprotocol.org/api/policies/resolve/bulk \
  -H "Content-Type: application/json" \
  -d '{"policy_ids": ["us_coppa", "eu_gdpr_advertising", "uk_hfss"]}'
```

Use the `policy` text and `exemplars` from the response in your governance agent's evaluation prompt. The exemplars calibrate the agent's interpretation of the policy -- include them as few-shot examples.

## Why a shared registry

Advertising compliance involves the same regulations and standards across many campaigns, brands, and governance agents. Without a shared registry, every governance agent would independently define policies for COPPA, GDPR, HFSS, and other well-known regulations -- creating inconsistency and duplication.

The registry solves this by providing:

* **Standardized policy definitions** with structured metadata (jurisdiction, policy category, enforcement level)
* **Natural language policy text** that governance agents (LLMs) use directly for evaluation
* **Calibration exemplars** (pass/fail scenarios) that align agent behavior
* **Version tracking** so brands can pin to specific policy versions

## Policy categories

Policies fall into two categories based on the nature of the obligation:

| Category | Enforcement | Description |
| - | - | - |
| **Regulation** | `must` | Legal requirements with jurisdiction scope. Violations have legal consequences. Governance agents reject actions that violate these policies. |
| **Standard** | `should` | Industry best practices, voluntary but recommended. Protects brand value and campaign effectiveness. Governance agents warn on violations but do not block. |

Enforcement levels follow RFC 2119 keywords:

* **`must`** -- Legal requirement. Governance agents reject violations.
* **`should`** -- Best practice. Governance agents warn but do not block.
* **`may`** -- Recommendation. Governance agents log for informational purposes only.

## How governance agents use policies

Governance agents are LLMs that interpret natural language policy text -- the same pattern used by [Content Standards](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.1/governance/content-standards/index.md). The registry's value is in structured metadata and calibration exemplars, not a custom rule language.

1. **Resolve applicable policies** from the brand's compliance configuration or buyer request
2. **Bulk-resolve from the registry** via `POST /api/policies/resolve/bulk`
3. **Filter by context** -- intersect policy jurisdictions/policy categories/channels with campaign parameters
4. **Include policy text + exemplars** in the evaluation prompt
5. **Apply enforcement level** -- `must` violations result in rejection, `should` violations result in warnings

## Policy structure

Each policy in the registry follows the [policy-entry schema](https://adcontextprotocol.org/schemas/3.3.0-beta.1/governance/policy-entry.json):

```json theme={null}
{
  "policy_id": "uk_hfss",
  "version": "1.0.0",
  "name": "UK HFSS Advertising Restrictions",
  "description": "UK ban on paid online advertising of less healthy food and drink products.",
  "category": "regulation",
  "enforcement": "must",
  "jurisdictions": ["GB"],
  "policy_categories": ["health_wellness"],
  "governance_domains": ["campaign", "property", "content_standards"],
  "effective_date": "2025-10-01",
  "source_url": "https://www.legislation.gov.uk/ukpga/2022/17/contents",
  "source_name": "UK Parliament",
  "policy": "The UK Health and Social Care Act 2022 restricts paid online advertising of food and drink products classified as 'less healthy' under the Nutrient Profiling Model...",
  "exemplars": {
    "pass": [
      {
        "scenario": "A breakfast cereal brand runs a display ad featuring their low-sugar granola (NPM score 2) on UK websites.",
        "explanation": "The product scores below the NPM threshold (4 for food), so it is not classified as less healthy."
      }
    ],
    "fail": [
      {
        "scenario": "A large snack company runs paid Instagram ads in the UK featuring their crisps (NPM score 8) at 2:00 PM.",
        "explanation": "The product is less healthy (NPM >= 4), the company has 250+ employees, and paid online ads are prohibited."
      }
    ]
  }
}
```

## Temporal enforcement

Policies have optional `effective_date` and `sunset_date` fields. Governance agents use these dates to determine enforcement behavior automatically:

| Condition | Behavior |
| - | - |
| Before `effective_date` | Evaluate but treat as informational. Findings are reported at `info` severity regardless of the policy's declared enforcement level. |
| Between `effective_date` and `sunset_date` (or no `sunset_date`) | Enforce at the declared level (`must` = reject, `should` = warn). |
| After `sunset_date` | Stop evaluating. The policy no longer applies. |
| No `effective_date` | Enforce immediately (the policy has always been in effect). |

This means brands can reference upcoming regulations before they take effect. The governance agent evaluates them and reports what *would* have been flagged, without blocking campaigns. Once the effective date passes, enforcement activates automatically -- no configuration change needed.

For example, the EU AI Act Article 50 has `effective_date: "2026-08-02"`. A brand referencing this policy before August 2026 sees informational findings about AI disclosure compliance. After August 2026, violations are rejected.

For the operational pattern — how to pin a policy version, what happens when a registry policy version-bumps mid-campaign, how to use `effective_date` for staged adoption, the additive-only rule for inline `custom_policies`, and a working-group FAQ — see [Sync and versioning](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.1/governance/policy-registry-sync.md).

## Three tiers of policy application

| Tier | Source | Example |
| - | - | - |
| **Always-on** | Regulations that apply automatically based on brand category and campaign jurisdictions | COPPA for US children's brands, GDPR for EU campaigns |
| **Best practices** | Standards that brands opt into based on their industry | Alcohol advertising standards for beverage brands |
| **Brand-specific** | Custom policies in the brand's compliance configuration | Brand-specific competitor exclusions, custom content rules |

## Brand compliance configuration

Brands reference registry policies through their compliance configuration. See the [Campaign Governance specification](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.1/governance/campaign/specification.md#brand-compliance-configuration) for the conceptual model.

## Integration across governance domains

The registry is a shared resource consumed by all governance domains:

| Domain | How it uses registry policies |
| - | - |
| **[Campaign Governance](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.1/governance/campaign/index.md)** | Resolves policies via brand compliance config, evaluates actions against policy text in `check_governance` |
| **[Content Standards](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.1/governance/content-standards/index.md)** | Creates content standards from registry policies using `registry_policy_ids` |
| **[Property Governance](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.1/governance/property/index.md)** | Declares `registry:` prefixed features in `get_adcp_capabilities`, evaluates properties against policy text |
| **[Creative Governance](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.1/governance/creative/index.md)** | Declares `registry:` prefixed creative features, evaluates creatives for AI disclosure and content compliance |
| **[Media Buy](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.1/media-buy/index.md)** | Sellers declare `enforced_policies` on products, buyers send `required_policies` in requests |

## Governance domains

Each policy declares which governance sub-domains it applies to via `governance_domains`. This determines which types of governance agents can evaluate and declare the policy as a feature.

| Domain | Description |
| - | - |
| `campaign` | Campaign governance agents evaluate this policy during `check_governance` |
| `property` | Property governance agents can declare this policy as a property feature |
| `creative` | Creative governance agents can evaluate creatives against this policy |
| `content_standards` | Content standards agents can create standards from this policy |

For example, `eu_ai_act_article_50` has `governance_domains: ["creative", "content_standards"]` because it's about AI-generated content disclosure -- relevant to creative evaluation and content standards, but not to property or campaign-level governance.

Filter by domain via the API: `GET /api/policies/registry?domain=creative`

## The `registry:` prefix

Governance agents declare standardized capabilities using `registry:` prefixed feature IDs. This creates a shared vocabulary so buyers searching for "EU AI Act compliance" find agents using the same terminology.

**Convention:** `registry:{policy_id}` maps a feature ID to a registry policy. Unprefixed feature IDs are agent-defined.

> [!NOTE]
>
> The `registry:` convention is the **delegated** form of policy reference — buyer asks the seller's governance agent to evaluate the policy as a binary feature. The complementary **attribution** pattern, where producers tag mechanism-level filters and measurements with `policy_id` to record buyer-chosen thresholds and motivated evaluations, lives at [Policy Attribution](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.1/governance/policy-attribution.md).

The same registry entry can provide an actionable creative rejection vocabulary without creating a protocol enum. Governance agents advertise `registry:{policy_id}` compliance features, while sellers cite the bare `policy_id` in existing `CREATIVE_REJECTED` details. The registry owns the shared rule and calibration examples; the agent owns detection methodology; the seller owns the enforcement decision. See [Policy-backed creative rejections](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.1/governance/creative/policy-backed-rejections.md).

**Property governance agent declares:**

```json theme={null}
{
  "governance": {
    "property_features": [
      { "feature_id": "registry:us_coppa", "type": "binary", "name": "COPPA compliance" },
      { "feature_id": "registry:uk_hfss", "type": "binary", "name": "UK HFSS compliance" }
    ]
  }
}
```

**Creative governance agent declares:**

```json theme={null}
{
  "governance": {
    "creative_features": [
      { "feature_id": "registry:eu_ai_act_article_50", "type": "binary", "name": "EU AI Act Article 50 compliance" },
      { "feature_id": "registry:ca_sb_942", "type": "binary", "name": "California SB 942 compliance" }
    ]
  }
}
```

**Buyer filters by feature:**

```json theme={null}
{
  "feature_requirements": [
    { "feature_id": "registry:us_coppa", "allowed_values": [true] }
  ]
}
```

The governance agent fetches the policy text and exemplars from the registry to evaluate against. The buyer just references the policy ID. The `governance_domains` field on the policy validates that the agent type is appropriate for the policy.

## Buyer-seller transparency

Buyers list enforced policies in media buy requests. Sellers declare which policies they already enforce on their products.

**Buyer requests policies:**

```json theme={null}
{
  "tool": "get_products",
  "arguments": {
    "brief": "UK video inventory for Q1",
    "required_policies": ["uk_hfss", "eu_gdpr_advertising"]
  }
}
```

**Seller declares enforcement:**

```json theme={null}
{
  "product_id": "premium_video_uk",
  "enforced_policies": ["uk_hfss", "eu_gdpr_advertising"]
}
```

## API

The registry is served via the AgenticAdvertising.org API:

| Endpoint | Method | Description |
| - | - | - |
| `/api/policies/registry` | GET | List policies with filtering by category, jurisdiction, policy\_categories, domain |
| `/api/policies/resolve` | GET | Resolve a single policy by ID (+ optional version) |
| `/api/policies/resolve/bulk` | POST | Bulk resolve multiple policy IDs |
| `/api/policies/history` | GET | Revision history for a policy |
| `/api/policies/save` | POST | Create or edit a community policy (auth required) |

Registry-sourced policies (authoritative) cannot be edited via the community save endpoint. Community-contributed policies go through a review process.

## Mandatory human review

Policies and policy categories can declare `requires_human_review: true` to flag regulatory regimes that prohibit solely automated decisions — most notably GDPR Article 22 and EU AI Act Annex III. When a plan resolves any policy or category with this flag, the governance agent MUST set `plan.human_review_required = true` and MUST escalate every action for human review before execution.

Seeded categories carrying `requires_human_review: true`:

* `fair_housing` — US FHA, Annex III-equivalent housing decisions
* `fair_lending` — US ECOA, Annex III §5(b) creditworthiness
* `fair_employment` — US Title VII, ADEA, Annex III §1(b) recruitment
* `pharmaceutical_advertising` — FDA DTC, EU prescription ad bans

See [Annex III & Art 22 obligations](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.1/governance/annex-iii-obligations.md) for deployer guidance and the distinction between `reallocation_threshold` (budget reallocation) and `human_review_required` (decisions affecting individuals).

## Seeded policies

The registry ships with 14 seeded policies covering common advertising regulations and standards:

### Regulations

| ID | Jurisdictions | Description |
| - | - | - |
| `uk_hfss` | GB | UK ban on paid online advertising of less healthy food/drink |
| `us_coppa` | US | Children's Online Privacy Protection Act |
| `eu_gdpr_advertising` | EU | GDPR requirements for advertising data processing |
| `eu_ai_act_article_50` | EU | AI-generated content disclosure and C2PA provenance |
| `eu_ai_act_annex_iii` | EU | Annex III high-risk categories — credit, insurance pricing, recruitment, housing (mandates human review) |
| `ca_sb_942` | US | California AI Transparency Act for large platforms |
| `us_cannabis` | US | Cannabis advertising restrictions (state-by-state) |
| `tobacco_nicotine` | Global | Tobacco and nicotine advertising restrictions -- most jurisdictions ban tobacco advertising outright |
| `political_advertising` | EU | Political advertising transparency and disclosure (EU DSA, US state-level AI disclosure laws) |

### Standards

| ID | Policy Categories | Description |
| - | - | - |
| `alcohol_advertising` | `age_restricted` | Responsible alcohol advertising practices |
| `pharma_us_fda` | `pharmaceutical_advertising` | FDA-aligned pharmaceutical advertising |
| `gambling_advertising` | `gambling_advertising` | Responsible gambling advertising |
| `financial_services` | `fair_lending` | Financial product advertising disclosure |
| `csbs` | All | Common Sense Brand Standards -- content adjacency standard (enforcement: `must`) contributed to AgenticAdvertising.org |
| `childrens_advertising` | `children_directed` | Global standards for advertising directed at or seen by children (UK CAP/BCAP, EU AVMSD, ICC) |

> [!NOTE]
>
> Common Sense Brand Standards (CSBS) is a content adjacency standard governed by AgenticAdvertising.org. It defines content categories where advertising placement poses brand-reputation risk, applicable across industries and channels. CSBS originated at Scope3 and was contributed to AAO in 2026; formalization of the IP donation instrument is tracked in [#2314](https://github.com/adcontextprotocol/adcp/issues/2314). Until the formal donation record is complete, CSBS ships as a seeded policy under AAO custodianship rather than under a signed assignment.

## Policy category definitions

The registry defines policy categories — regulatory regime groupings that determine which sets of policies apply to a campaign. Categories are referenced by ID in campaign plans via `policy_categories`.

Each category definition includes:

| Field | Description |
| - | - |
| `category_id` | Unique identifier (e.g., `children_directed`, `fair_housing`) |
| `name` | Human-readable name |
| `description` | What regulatory regime this category represents |
| `regulatory_frameworks` | Specific laws and regulations grouped under this category |
| `restricted_attributes` | Personal data categories that must not be used for targeting when this category applies |
| `industries` | Industries where this category commonly applies |
| `guidance` | Implementation guidance for governance agents |

### Seeded categories

| Category | Restricted Attributes | Description |
| - | - | - |
| `children_directed` | — | COPPA, UK AADC, GDPR Article 8. Restricts data collection and targeting for children's content. |
| `political_advertising` | `political_opinions` | EU DSA Article 26, US state disclosure laws. Prohibits special category targeting for political ads. |
| `age_restricted` | — | Alcohol, tobacco, cannabis. Age-gating, time-of-day restrictions, and content placement rules. |
| `gambling_advertising` | `health_data` | Sports betting, casinos, lotteries. Jurisdiction-level legality, self-exclusion compliance, responsible gambling messaging. |
| `fair_housing` | `racial_ethnic_origin`, `religious_beliefs`, `sex_life_sexual_orientation` | US FHA, state fair housing. Prohibits targeting/exclusion by protected characteristics in housing ads. |
| `fair_lending` | `racial_ethnic_origin`, `religious_beliefs`, `sex_life_sexual_orientation` | US ECOA, CFPB guidance. Prohibits discriminatory targeting in credit/lending ads. |
| `fair_employment` | `racial_ethnic_origin`, `religious_beliefs`, `sex_life_sexual_orientation`, `health_data`, `genetic_data` | US EEOC (Title VII, ADA, GINA), state employment law. Prohibits discriminatory targeting in job ads. |
| `pharmaceutical_advertising` | `health_data` | FDA DTC, EU prescription ad bans. Fair balance, indication restrictions. |
| `health_wellness` | `health_data` | FTC health claims, supplement advertising. Substantiation requirements. |
| `firearms_weapons` | — | Platform-level and jurisdictional restrictions on firearms advertising. |

The `restricted_attributes` on a category are authoritative — when a plan declares a policy category, those attributes are automatically restricted for the campaign regardless of whether the plan also declares them in `restricted_attributes`.

## Restricted attribute definitions

The registry defines restricted attribute categories used across plans, signal definitions, and policy categories. They include GDPR Article 9 special categories and other policy-sensitive attributes such as age, familial status, and (in AdCP 3.3) sex or gender. Enum membership alone does not establish a legal classification or prohibit targeting. Applicable plan and policy restrictions determine whether an attribute can be used.

Each attribute definition includes:

| Field | Description |
| - | - |
| `attribute_id` | Unique identifier (e.g., `health_data`, `racial_ethnic_origin`) |
| `name` | Human-readable name |
| `description` | What personal data this category covers |
| `regulatory_basis` | Legal basis for restriction (e.g., "GDPR Article 9(1)") |
| `includes` | Examples of data that falls within this category |
| `excludes` | Common data that might seem related but is explicitly outside this category |
| `signal_patterns` | Naming patterns governance agents can use to detect undeclared signals that likely touch this data |
| `guidance` | Implementation guidance |

### Seeded attributes

| Attribute | Regulatory Basis | Includes |
| - | - | - |
| `racial_ethnic_origin` | GDPR Article 9(1) | Race, ethnicity, national origin, tribal affiliation |
| `political_opinions` | GDPR Article 9(1) | Party affiliation, voting patterns, political donations |
| `religious_beliefs` | GDPR Article 9(1) | Religion, denomination, religious practice indicators |
| `trade_union_membership` | GDPR Article 9(1) | Union membership, collective bargaining participation |
| `health_data` | GDPR Article 9(1) | Medical conditions, prescriptions, health behaviors, disability |
| `sex_life_sexual_orientation` | GDPR Article 9(1) | Sexual orientation, gender identity, relationship status indicators |
| `genetic_data` | GDPR Article 9(1) | DNA profiles, genetic test results, hereditary conditions |
| `biometric_data` | GDPR Article 9(1) | Fingerprints, facial geometry, voice prints, gait analysis |
| `sex_gender` | Applicable campaign or seller policy | Sex- or gender-based audience classifications, including core `female`, `male`, and `non_binary` gender predicates; available in AdCP 3.3 |

The new core `demographics.gender` predicate maps to `sex_gender` for structural matching, independently of whether execution uses native seller controls or signals. A signal carrying `demographic_predicate.gender` MUST declare `sex_gender` in `restricted_attributes`; a signal with both age and gender predicates MUST declare both corresponding attributes. The core predicate alone does not imply sex life or sexual orientation.

The existing `sex_life_sexual_orientation` registry definition and provider-declared metadata retain their meaning. Adding a core gender predicate MUST NOT remove or rewrite any existing signal attribute declaration; a provider that already declares `sex_life_sexual_orientation` retains it and also declares `sex_gender` when it adds the new predicate. The table's legacy definition does not authorize automatic reclassification of external provider metadata.

Adding the attribute does not alter the restrictions on existing seeded policy categories. Implementations MUST evaluate effective targeting against the applicable plan and resolved policies, including constraints inherited from product defaults or preserved from package state. For the separately agreed AdCP 3.2 interim binding, cooperating integrations use the custom `gender` restriction instead of sending the AdCP 3.3 enum value.

Data providers can reference these definitions when declaring `restricted_attributes` on their signal definitions. See [Declaring governance metadata](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.1/signals/data-providers.md#declaring-governance-metadata). Governance agents match signal-declared attributes against plan-level `restricted_attributes` during [`check_governance`](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.1/governance/campaign/tasks/check_governance) validation — signals with matching restricted attributes are blocked from targeting for that campaign.

## Contributing policies

Community members can contribute new policies via the API or admin interface. Contributed policies:

* Must include `policy_id`, `version`, `name`, `category`, `enforcement`, and `policy` text
* Are created with `source_type: community` and `review_status: pending`
* Go through review before becoming available in the registry
* Cannot overwrite registry-sourced (authoritative) policies


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.