> ## 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](/dist/docs/3.2.0-rc.7/governance/content-standards/index). 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.2.0-rc.7/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](/dist/docs/3.2.0-rc.7/governance/policy-registry-sync).

## 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](/dist/docs/3.2.0-rc.7/governance/campaign/specification#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](/dist/docs/3.2.0-rc.7/governance/campaign/index)** | Resolves policies via brand compliance config, evaluates actions against policy text in `check_governance` |
| **[Content Standards](/dist/docs/3.2.0-rc.7/governance/content-standards/index)** | Creates content standards from registry policies using `registry_policy_ids` |
| **[Property Governance](/dist/docs/3.2.0-rc.7/governance/property/index)** | Declares `registry:` prefixed features in `get_adcp_capabilities`, evaluates properties against policy text |
| **[Creative Governance](/dist/docs/3.2.0-rc.7/governance/creative/index)** | Declares `registry:` prefixed creative features, evaluates creatives for AI disclosure and content compliance |
| **[Media Buy](/dist/docs/3.2.0-rc.7/media-buy/index)** | 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

<a id="feature-prefix-convention" />

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](/dist/docs/3.2.0-rc.7/governance/policy-attribution).
</Note>

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](/dist/docs/3.2.0-rc.7/governance/creative/policy-backed-rejections).

**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](/dist/docs/3.2.0-rc.7/governance/annex-iii-obligations) 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.
</Note>

## 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 — types of personal data that regulations restrict for ad targeting. These map to GDPR Article 9 special categories and are used across plans, signal definitions, and policy categories.

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 |

Data providers can reference these definitions when declaring `restricted_attributes` on their signal definitions. See [Declaring governance metadata](/dist/docs/3.2.0-rc.7/signals/data-providers#declaring-governance-metadata). Governance agents match signal-declared attributes against plan-level `restricted_attributes` during [`check_governance`](/dist/docs/3.2.0-rc.7/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