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

# Content Standards

> AdCP Content Standards enable privacy-preserving brand suitability evaluation for AI-generated and ephemeral content that cannot leave publisher infrastructure.

# Content Standards Protocol

The Content Standards Protocol enables **privacy-preserving brand suitability** for ephemeral and sensitive content that cannot leave a publisher's infrastructure.

## The Problem

Traditional brand suitability relies on third-party verification: send your content to IAS or DoubleVerify, they evaluate it, return a verdict. This works for static web pages. It fundamentally cannot work for:

* **AI-generated content** - ChatGPT responses, DALL-E images that exist only in a user session
* **Private conversations** - Content in messaging apps, private social feeds
* **Ephemeral content** - Stories, live streams, real-time feeds that disappear
* **Privacy-regulated content** - GDPR-protected data that cannot be exported
* **CTV and linear TV** - Ad decisioning in live linear has a sub-second latency budget; there is no room to make a blocking call to a third-party verification service before insertion

For these platforms, **there is no traditional verification option**. The content simply cannot leave — or cannot wait. OpenAI cannot send user conversations to an external service. A messaging app cannot export private chats. A live broadcaster cannot block insertion on an external API response.

Yet these are exactly the environments where advertising is growing fastest - and where brands most need suitability guarantees. Without a privacy-preserving approach, brands either avoid these channels entirely or accept unknown risk.

## The Solution: Calibration-Based Alignment

Content Standards solves this by **using agents to protect privacy**. It's a three-phase model where no sensitive content ever leaves the publisher's infrastructure:

| Phase                  | Where It Runs             | What Happens                                                                                                                              |
| ---------------------- | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| **1. Calibration**     | External (safe data only) | Publisher and verification agent align on policy interpretation using synthetic examples or public samples - no PII, no sensitive content |
| **2. Local Execution** | Inside publisher's walls  | Publisher runs evaluation on every impression using a local model trained during calibration - content never leaves                       |
| **3. Validation**      | Statistical sampling      | Verification agent audits a sample to detect drift - both parties can verify the system is working without exposing PII                   |

This inverts the traditional model. Instead of "send us your content, we'll evaluate it," it's "we'll teach you our standards, you evaluate locally, we'll audit statistically."

**The key insight**: The execution engine runs entirely inside the publisher's infrastructure. For OpenAI, that means brand suitability evaluation happens within their firewall - user conversations never leave. For a messaging app, it means private content stays private. The calibration and validation phases provide confidence that the local model is working correctly, without ever requiring access to sensitive data.

**Sellers have full control over how they implement local execution.** A publisher might use a third-party AI vendor, build a custom model, use a rules-based classifier, or apply human editorial review at spot-check scale. What matters is that the implementation is calibrated against the verification agent's standards and that validation samples confirm alignment — the protocol does not mandate how sellers get there.

## What It Covers

* **Brand safety** - Is this content safe for *any* brand? (universal thresholds like hate speech, illegal content)
* **Brand suitability** - Is this content appropriate for *my* brand? (brand-specific preferences and tone)

## Key Concepts

Content standards evaluation involves four key questions that buyers and sellers negotiate:

1. **What content?** - What [artifacts](./artifacts) to evaluate (the ad-adjacent content)
2. **How much adjacency?** - How many artifacts around the ad slot to consider
3. **What sampling rate?** - What percentage of traffic to evaluate
4. **How to calibrate?** - How to align on policy interpretation before runtime

These parameters are negotiated between buyer and seller during product discovery and media buy creation.

## Workflow

```mermaid theme={null}
sequenceDiagram
    participant Brand
    participant Buyer as Buyer Agent
    participant Seller as Seller Agent
    participant Verifier as Verification Agent

    Note over Brand,Verifier: 1. SETUP PHASE
    Brand->>Verifier: create_content_standards (policy + calibration examples)
    Verifier-->>Brand: standards_id

    Note over Brand,Verifier: 2. ACTIVATION PHASE
    Brand->>Buyer: "Buy inventory from Reddit, use standards_id X"
    Buyer->>Seller: create_media_buy (includes content_standards reference)

    Seller->>Verifier: calibrate_content (sample artifacts)
    Verifier-->>Seller: verdict + explanation
    Seller->>Verifier: "What about this edge case?"
    Verifier-->>Seller: clarification
    Note over Seller: Seller builds local model

    Note over Brand,Verifier: 3. RUNTIME PHASE
    loop High-volume decisioning
        Note over Seller: Local model evaluates artifacts
    end

    Buyer->>Seller: get_media_buy_artifacts
    Seller-->>Buyer: Content artifacts
    Buyer->>Verifier: validate_content_delivery
    Verifier-->>Buyer: Validation results
```

<Warning>
  **Calibration is required before production use.** Content standards created via `create_content_standards` define what to evaluate, but calibration via [`calibrate_content`](/dist/docs/3.2.0-beta.3/governance/content-standards/tasks/calibrate_content) aligns the seller's local model with the verification agent's interpretation. Without calibration, the seller's local model produces uncalibrated evaluations — policy violations may go undetected or safe content may be incorrectly blocked. Always calibrate before activating a media buy with content standards.
</Warning>

**Key insight**: Runtime decisioning happens locally at the seller (for scale). Buyers pull content samples from sellers and validate against the verification agent.

## Adjacency

How much content around the ad slot should be evaluated?

| Context             | Adjacency Examples                        |
| ------------------- | ----------------------------------------- |
| **News article**    | The article where the ad appears          |
| **Social feed**     | 1-2 posts above and below the ad slot     |
| **Podcast**         | The segment before and after the ad break |
| **CTV**             | 1-2 scenes before and after the ad pod    |
| **Infinite scroll** | Posts within the visible viewport         |

Adjacency requirements are defined by the seller in their product catalog (`get_products`). The buyer can filter products based on adjacency guarantees:

```json theme={null}
{
  "product_id": "reddit_feed_standard",
  "content_standards_adjacency_definition": {
    "before": 2,
    "after": 2,
    "unit": "posts"
  }
}
```

### Adjacency Units

| Unit        | Use Case                              |
| ----------- | ------------------------------------- |
| `posts`     | Social feeds, forums, comment threads |
| `scenes`    | CTV, streaming video content          |
| `segments`  | Podcasts, audio content               |
| `seconds`   | Time-based adjacency in video/audio   |
| `viewports` | Infinite scroll contexts              |
| `articles`  | News sites, content aggregators       |

Different products may offer different adjacency guarantees at different price points.

## Sampling Rate

What percentage of traffic should be evaluated by the verification agent?

| Rate       | Use Case                                               |
| ---------- | ------------------------------------------------------ |
| **100%**   | Premium brand suitability - every impression validated |
| **10-25%** | Standard monitoring - statistical confidence           |
| **1-5%**   | Spot checking - drift detection only                   |

Sampling rate is negotiated in the media buy:

```json theme={null}
{
  "governance": {
    "content_standards": {
      "agent_url": "https://safety.ias.com/adcp",
      "standards_id": "nike_brand_safety",
      "sampling_rate": 0.25
    }
  }
}
```

Higher sampling rates typically cost more but provide stronger guarantees. The seller is responsible for implementing the agreed sampling rate and reporting actual coverage. Buyers retrieve collected artifacts via [get\_media\_buy\_artifacts](./tasks/get_media_buy_artifacts) (pull) or receive them via `artifact_webhook` (push) — both deliver artifacts sampled per the buy agreement.

## Validation Thresholds

When a seller calibrates their local model against a verification agent, there's an expected drift - the local model won't match the verification agent 100% of the time. **Validation thresholds** define acceptable drift between local execution and validation samples.

Sellers advertise their content safety capabilities in their product catalog:

```json theme={null}
{
  "product_id": "reddit_feed_premium",
  "content_standards": {
    "validation_threshold": 0.95,
    "validation_threshold_description": "Local model matches verification agent 95% of the time"
  }
}
```

| Threshold | Meaning                                                      |
| --------- | ------------------------------------------------------------ |
| **0.99**  | Premium - local model is 99% aligned with verification agent |
| **0.95**  | Standard - local model is 95% aligned                        |
| **0.90**  | Budget - local model is 90% aligned                          |

**This is a contractual guarantee.** If the seller's validation results show more drift than the advertised threshold, buyers can expect remediation (makegoods, refunds, etc.) just like any other delivery discrepancy.

The threshold answers the key buyer question: "If I accept your local model, how confident can I be that you're enforcing my standards correctly?"

## Policies

Content Standards uses **addressable policies** — an array of policy entries, each with a `policy_id`, enforcement level, and natural-language policy text. Policies embedded in AdCP task payloads are inline; registry-published policies use the same policy-entry shape but are served through the policy registry. Validation findings reference `policy_id` to identify which policy triggered:

### Policy fields

| Field                   | Required | Description                                                                                                                                              |
| ----------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `policy_id`             | Yes      | Unique policy identifier. Registry IDs are canonical; buyer-authored IDs are unique within their containing standards configuration, plan, or portfolio. |
| `enforcement`           | Yes      | Violation handling: `must` rejects, `should` warns without blocking, and `may` records informational results.                                            |
| `policy`                | Yes      | Natural-language requirement, prohibition, or recommendation evaluated by the governance agent.                                                          |
| `source`                | No       | Policy origin: `registry` or `inline` (the default). Policies embedded in task payloads are inline.                                                      |
| `version`               | No       | Semantic version of the policy text; inline policies default to `1.0.0`.                                                                                 |
| `name`                  | No       | Human-readable policy name.                                                                                                                              |
| `description`           | No       | Brief summary of the policy, up to 500 characters.                                                                                                       |
| `category`              | No       | Whether the obligation is a `regulation` or a `standard`.                                                                                                |
| `requires_human_review` | No       | Whether plans resolved against the policy require human review. Defaults to `false`.                                                                     |
| `jurisdictions`         | No       | ISO 3166-1 alpha-2 country codes where the policy applies.                                                                                               |
| `region_aliases`        | No       | Named jurisdiction groups used when matching the policy to a plan.                                                                                       |
| `policy_categories`     | No       | One or more regulatory or suitability categories used for automatic matching.                                                                            |
| `channels`              | No       | Advertising channels to which the policy applies; omission means all channels.                                                                           |
| `governance_domains`    | No       | Governance agent domains that can evaluate the policy.                                                                                                   |
| `effective_date`        | No       | ISO 8601 date when enforcement begins; before this date findings are informational.                                                                      |
| `sunset_date`           | No       | ISO 8601 date after which the policy is no longer evaluated.                                                                                             |
| `source_url`            | No       | Link to the source regulation, standard, or legislation.                                                                                                 |
| `source_name`           | No       | Name of the issuing body.                                                                                                                                |
| `guidance`              | No       | Implementation notes for governance-agent developers; not included in evaluation prompts.                                                                |
| `exemplars`             | No       | Structured `pass` and `fail` scenarios used to calibrate policy interpretation.                                                                          |
| `ext`                   | No       | Vendor-namespaced extension data for partner-specific metadata.                                                                                          |

Policy entries are closed objects: fields outside this table fail schema validation rather than being silently ignored. Put partner-specific, buyer-visible metadata under a vendor key in `ext` (for example, `ext.acme`) instead of adding sibling fields or encoding structured metadata inside the natural-language `policy` value.

```json theme={null}
{
  "policies": [
    { "policy_id": "no_violence", "policy_categories": ["brand_safety"], "enforcement": "must", "policy": "Avoid content depicting violence, weapons, or physical aggression." },
    { "policy_id": "no_controversial_politics", "policy_categories": ["brand_suitability"], "enforcement": "must", "policy": "Avoid controversial political content." },
    { "policy_id": "no_adult_themes", "policy_categories": ["brand_safety"], "enforcement": "must", "policy": "Avoid adult, sexual, or mature themes." },
    { "policy_id": "no_hate_speech", "policy_categories": ["brand_safety"], "enforcement": "must", "policy": "Block hate speech and illegal activities." },
    { "policy_id": "no_sedentary_glorification", "policy_categories": ["brand_suitability"], "enforcement": "should", "policy": "Avoid content that portrays sedentary lifestyle positively." }
  ],
  "calibration_exemplars": {
    "pass": [
      {
        "property_id": {"type": "domain", "value": "espn.com"},
        "artifact_id": "nba_championship_recap_2024",
        "assets": [{"type": "text", "role": "title", "content": "Championship Game Recap"}]
      }
    ],
    "fail": [
      {
        "property_id": {"type": "domain", "value": "tabloid.example.com"},
        "artifact_id": "scandal_story_123",
        "assets": [{"type": "text", "role": "title", "content": "Celebrity Scandal Exposed"}]
      }
    ]
  }
}
```

The policy prompt enables AI-powered verification agents to understand context and nuance. **Calibration** examples provide a training/test set that helps the agent interpret the policy correctly.

See [Artifacts](./artifacts) for details on artifact structure and secured asset access.

## Updating policies

[`update_content_standards`](./tasks/update_content_standards) updates the supplied scope, registry policy references, bespoke policies, or calibration exemplars for an existing `standards_id`. A supplied `policies` array replaces the existing bespoke policies. Keep each `policy_id` stable across updates so findings and audit records continue to identify the same rule. Use the optional policy-level `version` when consumers need to distinguish revisions of that rule's text.

The current wire schemas do not define configuration-level version semantics, a policy-level `evaluation_mode`, or media-buy behavior for pinning and adopting later standards revisions. Policy entries accept `version` for revisions of that rule's text, but their closed schema rejects `evaluation_mode`. Unknown configuration or media-buy controls have no interoperable AdCP meaning even where a containing schema permits additional properties. Deployments that require partner-specific revision or mid-flight adoption controls can exchange them under the vendor-namespaced `ext` object, but those controls are outside the interoperable AdCP contract.

## Scoped Standards

Buyers typically maintain multiple standards configurations for different contexts - UK TV campaigns have different regulations than US display, and children's brands need stricter safety than adult beverages.

```json theme={null}
{
  "standards_id": "uk_tv_zero_calorie",
  "name": "UK TV - zero-calorie brands",
  "countries_all": ["GB"],
  "channels_any": ["ctv", "linear_tv"],
  "languages_any": ["en"]
}
```

<Info>
  **Code Format Conventions**

  Country and language codes are **case-insensitive** - implementations must normalize before comparison. Recommended formats follow ISO standards:

  * **Countries**: Uppercase ISO 3166-1 alpha-2 (e.g., `GB`, `US`, `DE`)
  * **Languages**: Lowercase ISO 639-1 or BCP 47 (e.g., `en`, `de`, `fr`)
</Info>

**The buyer selects the appropriate `standards_id` when creating a media buy.** The seller receives a reference to the resolved standards - they don't need to do scope matching themselves.

## Calibration

Before running campaigns, sellers calibrate their local models against the verification agent. This is a **dialogue-based process** that may involve human review on either side:

1. Seller sends sample artifacts to the verification agent
2. Verification agent returns verdicts with detailed explanations
3. Seller asks follow-up questions about edge cases
4. Process repeats until alignment is achieved

When a seller surfaces an edge case the verification agent does not handle well, that's signal to the buyer to improve their standards — refining the policy language or adding calibration exemplars. The calibration dialogue is also how publishers communicate what they actually see in their inventory, which is often more nuanced than the policy anticipated. Buyers who revisit calibration periodically get ongoing signal from publishers about real-world inventory nuance.

**Human-in-the-loop**: Calibration often involves humans on both sides. A brand suitability specialist at the buyer might review edge cases flagged by the verification agent. A content operations team at the seller might curate calibration samples and validate the local model's learning. The protocol supports async workflows where either party can pause for human review before responding.

```json theme={null}
// Seller: "Does this pass?"
{
  "artifact": {
    "property_id": {"type": "domain", "value": "reddit.com"},
    "artifact_id": "r_news_politics_123",
    "assets": [{"type": "text", "role": "title", "content": "Political News Article"}]
  }
}

// Verification agent: "No, because..."
{
  "verdict": "fail",
  "explanation": "Political content is excluded by brand policy, even when balanced.",
  "features": [
    {
      "feature_id": "brand_safety",
      "status": "passed",
      "explanation": "No hate speech, illegal content, or explicit material."
    },
    {
      "feature_id": "brand_suitability",
      "status": "failed",
      "explanation": "Political content is excluded by brand policy, even when balanced."
    }
  ]
}
```

Verdicts are **legible and auditable**, not opaque scores. The top-level `explanation` and per-feature `features[].explanation` fields tell the seller exactly which policy clause was triggered and why — not just a number. This means a publisher can understand decisions, dispute edge cases, and adjust how they classify content. Buyers can audit a sample of verdicts to verify their standards are being interpreted correctly.

See [calibrate\_content](./tasks/calibrate_content) for the full task specification.

## Tasks

### Discovery

| Task                                                       | Description                                 |
| ---------------------------------------------------------- | ------------------------------------------- |
| [list\_content\_standards](./tasks/list_content_standards) | List available standards configurations     |
| [get\_content\_standards](./tasks/get_content_standards)   | Retrieve a specific standards configuration |

### Management

| Task                                                           | Description                                |
| -------------------------------------------------------------- | ------------------------------------------ |
| [create\_content\_standards](./tasks/create_content_standards) | Create a new standards configuration       |
| [update\_content\_standards](./tasks/update_content_standards) | Update an existing standards configuration |

### Calibration & Validation

| Task                                                             | Description                                              |
| ---------------------------------------------------------------- | -------------------------------------------------------- |
| [calibrate\_content](./tasks/calibrate_content)                  | Collaborative dialogue to align on policy interpretation |
| [get\_media\_buy\_artifacts](./tasks/get_media_buy_artifacts)    | Retrieve content artifacts from a media buy              |
| [validate\_content\_delivery](./tasks/validate_content_delivery) | Batch validation of content artifacts                    |

## Future: Secure Enclaves

The current model trusts the publisher to faithfully implement the calibrated standards. A future evolution uses **secure enclaves** (Trusted Execution Environments / TEEs) to provide cryptographic guarantees:

```mermaid theme={null}
flowchart TB
    subgraph VS["Verification Service"]
        Models["Models & Calibration Data"]
        Results["Aggregate Results"]
    end

    subgraph PUB["Publisher Infrastructure"]
        subgraph TEE["Secure Enclave (TEE)"]
            Agent["Containerized<br/>Governance Agent"]
        end
        Content["Content Artifacts"]
    end

    Models -->|"Pinhole IN:<br/>models, policy, examples"| Agent
    Agent -->|"Pinhole OUT:<br/>pass rates, drift metrics"| Results
    Content -->|"evaluate"| Agent
    Agent -->|"pass/fail verdict"| Content

    style TEE fill:#e8f5e9,stroke:#4caf50
    style Agent fill:#c8e6c9,stroke:#388e3c
    style PUB fill:#fafafa,stroke:#9e9e9e
```

**Content never crosses the pinhole** - only models flow in, only aggregates flow out.

### The Pinhole Interface

The enclave maintains a narrow, well-defined interface to the verification service:

**Inbound (verification service → enclave):**

* Updated brand suitability models
* Policy changes and calibration exemplars
* Configuration updates

**Outbound (enclave → verification service):**

* Aggregated validation results (pass rates, drift metrics)
* Statistical summaries
* Attestation proofs

**Never crosses the boundary:**

* Raw content artifacts
* User data or PII
* Individual impression-level data

This pinhole is the interface that needs standardization - it defines exactly what flows in and out while keeping sensitive content locked inside the publisher's walls.

### Why This Matters

* **Publisher** hosts a secure enclave inside their infrastructure
* **Governance agent** (from IAS, DoubleVerify, etc.) runs as a container within the enclave
* **Content** flows into the enclave for evaluation but never leaves the publisher's walls
* **Both parties** can verify the governance code is running unmodified via attestation
* **Models stay current** - the enclave can receive updates without exposing content

This provides the same privacy guarantees as local execution, but with cryptographic proof that the correct algorithm is running. The brand knows their standards are being enforced faithfully. The publisher proves compliance without exposing content.

This architecture aligns with the [IAB Tech Lab ARTF (Agentic RTB Framework)](https://iabtechlab.com/standards/artf/), which defines how service providers can package offerings as containers deployed into host infrastructure. ARTF enables hosts to "provide greater access to data and more interaction opportunities to service agents without concerns about leakage, misappropriation or latency" - exactly the model Content Standards requires for privacy-preserving brand suitability.

## Related

* [Artifacts](./artifacts) - What artifacts are and how to structure them
* [Brand identity](/dist/docs/3.2.0-beta.3/brand-protocol/brand-json) - Brand identity that can link to standards agents