Skip to main content
AdCP 3.0 Proposal - This protocol is under development for AdCP 3.0. Feedback welcome via GitHub Discussions.
Creative Governance standardizes how creatives are evaluated by specialized governance agents. It applies the same feature-based pattern as Property Governance — agents declare features they can evaluate, accept creative manifests, and return feature values.

Overview

Creative governance agents evaluate creatives and return feature values. Different agents evaluate different features: The protocol doesn’t define a fixed feature taxonomy. Vendors declare what they evaluate via get_adcp_capabilities and compete on coverage.

How it works

1. Agent declares features

A creative governance agent advertises its capabilities using the same feature definition pattern as property governance:
The orchestrator reads these declarations via get_adcp_capabilities before evaluating any creative. If a required feature is absent from an agent’s declaration, the orchestrator surfaces the gap immediately rather than discovering it mid-evaluation.

2. Orchestrator evaluates a creative

The orchestrator calls get_creative_features with a creative manifest:

3. Agent returns feature values

The agent evaluates the creative and returns feature values. The response shape is the same regardless of agent type:

4. Orchestrator applies requirements

The orchestrator evaluates the feature values against buyer-defined requirements — the same pattern as property list feature requirements:
  • Security: reject if auto_redirect is true
  • Quality: reject if brand_consistency is below 80
  • Categorization: reject if iab_casinos_gambling is true and campaign excludes gambling

Design principles

Feature IDs enforce strictness, not schema rigidity. A categorization agent that declares iab_casinos_gambling using IAB Content Taxonomy 3.1 ID 181 is as strict as any custom schema — the discipline lives in the agent’s methodology, not in the wire format. An orchestrator that requires iab_casinos_gambling: false gets a binary pass/fail answer regardless of how the agent detected the content. The feature ID is the contract. The protocol staying schema-agnostic means adding a new IAB category or scanning technique does not require a protocol change. Confidence is opt-in, not mandatory. The confidence field on a feature result is optional. Security scanners typically omit it — a creative either contains a credential harvesting pattern or it does not. Categorization agents include it because content detection is probabilistic: a creative may be 94% likely to contain gambling content. The agent decides what to disclose. An orchestrator that cannot tolerate ambiguity requires value: false and ignores confidence entirely; an orchestrator that wants to threshold probabilistic results uses it. This is the same field that exists on property-feature-value for property governance. Orchestrator-enforced consistency. An orchestrator that requires iab_casinos_gambling from its categorization agent discovers at capability-check time — before any creative is evaluated — whether the agent supports that feature. If it does not, the orchestrator fails fast and surfaces the gap. This mirrors how property governance works: IAS and DoubleVerify evaluate different property features; the orchestrator determines which features are required and routes accordingly. Mandating a fixed feature set in the protocol schema would mean every new IAB category or custom brand requirement requires a protocol revision. The protocol defines the enforcement mechanism; the orchestrator defines the requirements. Opaque detailed intelligence. Feature values on the wire are pass/fail (binary) or scores (quantitative). Detection methodology, threat intelligence, and detailed scoring breakdowns stay behind the vendor’s access-controlled detail_url and methodology_url.

Multi-agent collaboration

Creative governance evaluations typically involve multiple specialist agents working in parallel — the same pattern property governance uses for sustainability, quality, and suitability agents. Each agent uses the same get_creative_features task. The orchestrator calls them in parallel, collects independent result sets, and applies its requirements across all of them. No agent needs to know about the others. This means a buyer can:
  • Add a new specialist agent without changing existing agents or the evaluation protocol
  • Apply different confidence thresholds per agent type
  • Replace one vendor with another without changing the evaluation logic for other agents
The orchestrator’s feature requirements — not the protocol schema — define what “complete” creative governance means for a given campaign.

Async evaluation

If evaluation takes time (e.g., sandboxed execution for malware scanning), the agent returns status: "working" and delivers results via the standard webhook mechanism. No custom status values or webhook events needed — the existing async task pattern handles this.