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:

curl https://adcontextprotocol.org/api/policies/resolve?policy_id=us_coppa

List all regulation-category policies:

curl https://adcontextprotocol.org/api/policies/registry?category=regulation

Bulk-resolve policies for an LLM evaluation prompt:

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. 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:

{
  "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.

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 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	Resolves policies via brand compliance config, evaluates actions against policy text in check_governance
Content Standards	Creates content standards from registry policies using registry_policy_ids
Property Governance	Declares registry: prefixed features in get_adcp_capabilities, evaluates properties against policy text
Creative Governance	Declares registry: prefixed creative features, evaluates creatives for AI disclosure and content compliance
Media Buy	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.

Property governance agent declares:

{
  "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:

{
  "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:

{
  "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:

{
  "tool": "get_products",
  "arguments": {
    "brief": "UK video inventory for Q1",
    "required_policies": ["uk_hfss", "eu_gdpr_advertising"]
  }
}

Seller declares enforcement:

{
  "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 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. 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. Governance agents match signal-declared attributes against plan-level restricted_attributes during 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