> ## Documentation Index
> Fetch the complete documentation index at: https://agenticadvertisingorg-feature-feedback.mintlify.site/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](/docs/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/v3/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](/docs/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](/docs/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](/docs/governance/campaign/index)** | Resolves policies via brand compliance config, evaluates actions against policy text in `check_governance` |
| **[Content Standards](/docs/governance/content-standards/index)** | Creates content standards from registry policies using `registry_policy_ids` |
| **[Property Governance](/docs/governance/property/index)** | Declares `registry:` prefixed features in `get_adcp_capabilities`, evaluates properties against policy text |
| **[Creative Governance](/docs/governance/creative/index)** | Declares `registry:` prefixed creative features, evaluates creatives for AI disclosure and content compliance |
| **[Media Buy](/docs/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
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.
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](/docs/governance/policy-attribution).
**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](/docs/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) |
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 — 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](/docs/signals/data-providers#declaring-governance-metadata). Governance agents match signal-declared attributes against plan-level `restricted_attributes` during [`check_governance`](/docs/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