Proposal: Taxonomy declaration as a core capability (3.1)

[mikulbhatt]

Summary

AdCP currently provides no mechanism for sellers to declare what classification systems — taxonomies — they support. A buyer agent discovering sellers through get_adcp_capabilities learns what tools are available and what extensions are loaded, but has zero visibility into the vocabularies those tools operate against. This means buyers cannot assess semantic compatibility before committing to a negotiation, and governance agents cannot contextualize their findings against the classification systems actually in play. This proposal adds a supported_taxonomies field to the get_adcp_capabilities response, making vocabulary an explicit, inspectable layer of the protocol.

---

From human negotiation to machine negotiation

When humans negotiate media deals, vocabulary is shared implicitly. "Auto intenders" means something specific in a phone call between two media planners who have worked together for five years. "Premium publishers" gets resolved over a Slack exchange — "do you mean editorial quality or CPM tier?" The context lives in people's heads. Ambiguity is resolved conversationally, often without either party noticing it happened. Two planners at Pinnacle Agency can spend a decade building a shared understanding of what "high-value sports audiences" means with their counterparts at StreamHaus, and that understanding never gets written down. It does not need to be. The relationship IS the specification.

When agents negotiate, none of that implicit context exists. An orchestrator agent cannot ask "what do you mean by that?" mid-transaction the way a human would over email. There is no history of lunches, no institutional memory of past deals, no tacit knowledge about what a particular seller means when they say "contextual relevance." Vocabulary must be declared explicitly. Classification systems must be visible. The shared understanding that two humans built over years of working together must be encoded in protocol constructs — because the protocol IS the relationship.

This is not automation of existing processes. It is a fundamentally new interaction contract between buyer and seller agents. When Pinnacle Agency's orchestrator sends a campaign brief to three different seller endpoints, it is not replicating a human RFP process at machine speed. It is conducting a negotiation where every term, every category, every segment definition must be unambiguous at the moment of exchange. There is no follow-up call to clarify. There is no "you know what I mean." There is only what the protocol declares.

And the first requirement of that contract is: both sides must know what vocabulary the other side speaks. Before a buyer can assess whether a seller's inventory aligns with campaign goals, before governance can evaluate whether brand safety constraints were properly applied, before any meaningful transaction can occur — both parties must have visibility into what classification systems are in play. That is what taxonomy declaration provides. It makes vocabulary explicit at the protocol level, so that orchestrators, governance agents, and sellers all operate from a shared, inspectable understanding of the taxonomies that define their interaction.

---

The problem: vocabulary blindness

Scenario A: Ontology blindness in a single transaction (illustrative)

Acme Outdoor is running a $2.4M campaign targeting outdoor enthusiasts. Pinnacle Agency's orchestrator sends a brief to StreamHaus specifying audience segments using IAB Content Taxonomy 3.0 category codes. StreamHaus's seller agent accepts the brief, maps the segments internally, and returns available inventory.

But StreamHaus uses a proprietary classification system for content categories. Their "Outdoor & Adventure" segment includes travel content that Acme Outdoor explicitly excludes — resort advertising, cruise promotions, luxury hotel reviews. The category names look compatible. The underlying definitions are not. The orchestrator has no way to detect this mismatch because AdCP provides no mechanism for StreamHaus to declare what taxonomy it actually uses, what coverage it provides, or how its categories map to industry-standard classifications.

The campaign runs. Delivery reports look clean — impressions served against "Outdoor & Adventure" content. But $380K of spend lands against travel content that dilutes brand positioning and triggers a governance review. The problem was not malice or negligence. It was vocabulary blindness: neither side had visibility into whether they were speaking the same language.

Scenario B: Multi-seller incompatibility at scale (illustrative)

Now scale the problem. Pinnacle Agency's orchestrator is executing a $6M cross-platform campaign for Acme Outdoor. It sends identical briefs — structured using IAB Content Taxonomy 3.0 — to three seller endpoints simultaneously:

• Seller A supports IAB Content Taxonomy 3.0 at full depth (4 levels). Perfect alignment.
• Seller B supports IAB Content Taxonomy 2.2, an older version with different category boundaries. "Outdoor Recreation" in 2.2 does not map cleanly to the 3.0 hierarchy — subcategories were restructured, and several segments that 3.0 splits into distinct nodes are merged in 2.2.
• Seller C uses a proprietary taxonomy with no declared relationship to any IAB standard. Their "Sports & Outdoors" category is a superset that includes fitness equipment reviews, gym membership content, and athleisure fashion — none of which align with Acme Outdoor's intent.

Today, the orchestrator discovers these incompatibilities only after the fact — through delivery anomalies, governance flags, or manual review. There is no pre-transaction signal. The orchestrator cannot ask "what taxonomies do you support?" because the protocol has no field for the answer.

The cost: $1.1M in misallocated spend across Sellers B and C, a two-week governance remediation cycle, and a client conversation that erodes trust. All because the protocol treated vocabulary as invisible.

What AdCP 3.0 already provides

AdCP 3.0 is not starting from zero on classification systems. Several taxonomy and vocabulary constructs already exist in the protocol, each serving a specific purpose:

• Media Channel Taxonomy. AdCP defines 20 standardized media channels — display, olv, ctv, retail_media, and others — that describe how buyers allocate budget across channel types. These channels provide a shared vocabulary for budget distribution and media mix planning.
• Advertiser Industry Taxonomy. 73 industry categories expressed in dot-notation (automotive.electric_vehicles, fashion_apparel.luxury, financial_services.banking, etc.) classify brands by vertical. This taxonomy enables seller agents to contextualize advertiser intent and match inventory relevance by industry.
• TMP context signals. The Trusted Match Protocol's context_match_request already carries taxonomy_source, taxonomy_id, and topics[] fields. Publishers can declare IAB Content Taxonomy 3.0 topics on real-time bid requests, enabling contextual matching at the impression level. This is taxonomy in action — but scoped to real-time signal exchange, not capability declaration.
• Signals Protocol. The get_signals tool uses natural-language signal_spec to discover data signals from provider catalogs published via adagents.json. This gives buyers a mechanism to explore what data a provider offers, but through free-text discovery rather than structured taxonomy declaration.

These are real, functioning vocabulary constructs. They demonstrate that AdCP already recognizes the importance of shared classification systems. The question is not whether AdCP needs taxonomies — it already has them. The question is what gap remains.

What's missing

The existing taxonomies each serve a bounded purpose: channels for budget allocation, industries for brand classification, TMP topics for contextual matching, signals for data discovery. What none of them address is capability-level taxonomy declaration — the ability for a seller to state, before any transaction begins, "here are the audience taxonomies, content taxonomies, and classification systems I support for campaign targeting and product matching."

Consider what a buyer learns today from get_adcp_capabilities:

• Tools the seller supports (get_products, create_media_buy, etc.)
• Protocols the seller implements (TMP, Signals, etc.)
• Geo targeting systems the seller uses for geographic targeting
• Creative specs describing supported ad formats and requirements
• Audience identifier types the seller can resolve (cookies, device IDs, etc.)
• Content standards governing brand safety and editorial quality

But nothing about the vocabulary the seller uses to classify audiences, content, or publisher quality for targeting purposes. A buyer calling get_adcp_capabilities today can determine whether a seller supports CTV inventory, accepts VAST creatives, and resolves UID2 identifiers — but cannot determine whether that seller classifies content using IAB Content Taxonomy 3.0, 2.2, or a proprietary system with no external mapping.

TMP's taxonomy_source and taxonomy_id work at the impression level — they enable contextual matching on individual bid requests in real time. They do not operate at the seller capability level, where a buyer needs to assess compatibility before committing to a campaign. Knowing that a seller can pass IAB 3.0 topics on a bid request is different from knowing that the seller's entire inventory classification system is built on IAB 3.0.

The Signals Protocol handles third-party data discovery — it lets buyers find signals from external data providers. But it does not address how seller-side taxonomies map to buyer-side intent concepts. When a buyer's brief specifies "outdoor enthusiasts" using IAB Audience Taxonomy 1.1 segment codes, the Signals Protocol cannot tell the buyer whether the seller's audience classification system speaks the same language.

The gap is structural: AdCP 3.0 has taxonomies for specific operational functions but no mechanism for sellers to declare taxonomy support as a capability. The supported_taxonomies field proposed here fills that gap. It sits alongside targeting, audience_targeting, content_standards, and creative_specs as another dimension of seller capability. The pattern already exists — sellers declare geo targeting systems, identifier types, creative formats, and content standards as capabilities. Taxonomy declaration follows the same pattern for classification systems: structured, inspectable, and available before the first transaction begins.

---

Proposed addition to the 3.1 specification: supported_taxonomies on get_adcp_capabilities

The get_adcp_capabilities response gains a new optional field, supported_taxonomies, that allows seller agents to declare the classification systems they operate against, their coverage depth, and the alignment methods they support.

Example response

{
  "adcp_version": "3.1.0",
  "tools": ["get_products", "create_media_buy", "list_authorized_properties"],
  "supported_taxonomies": {
    "taxonomies": [
      {
        "taxonomy_id": "iab-content-3.0",
        "name": "IAB Content Taxonomy",
        "version": "3.0",
        "coverage": "full",
        "hierarchy_depth": 4
      },
      {
        "taxonomy_id": "iab-audience-1.1",
        "name": "IAB Audience Taxonomy",
        "version": "1.1",
        "coverage": "partial",
        "hierarchy_depth": 2,
        "coverage_note": "Top two levels only; no sub-segment granularity below 'Sports & Recreation'"
      }
    ],
    "alignment_methods": ["exact_match", "hierarchical_traversal", "embedding_similarity"],
    "minimum_confidence": 0.7
  }
}

What this enables

• Buyer pre-assessment. The orchestrator can evaluate taxonomy compatibility before sending a brief. If a seller declares only IAB Content Taxonomy 2.2 and the campaign is structured against 3.0, the orchestrator can flag the mismatch, attempt a mapping, or route spend elsewhere — before a single impression is served.
• Governance context. When a governance agent evaluates semantic fidelity findings, it now knows what classification systems were in play. A mismatch between brief intent and delivery is assessed differently when the seller declared partial coverage versus full coverage. Governance can distinguish "the seller tried and fell short" from "the seller was operating in a completely different vocabulary."
• Campaign routing. For multi-seller campaigns, the orchestrator can route spend based on taxonomy alignment scores. Full IAB 3.0 support gets the bulk of outdoor-content spend; partial support gets lower allocation with tighter governance monitoring; incompatible taxonomies get excluded or flagged for manual review.
• Vocabulary visibility. The entire ecosystem gains transparency. Sellers that invest in comprehensive taxonomy support can differentiate themselves. Buyers can make informed decisions. Governance can set expectations. The invisible becomes inspectable.

---

The path from taxonomy to ontology

Version 3.1 delivers taxonomy declarations — the ability for sellers to declare support for hierarchical classification systems like IAB Content Taxonomy 3.0 or IAB Audience Taxonomy 1.1. Taxonomies are trees: parent-child relationships, category hierarchies, nested segments. They are well-understood in ad tech, widely adopted, and straightforward to declare.

But taxonomies are not the end state. Future versions of AdCP may evolve toward ontology support: richer concept relationships that go beyond hierarchical classification to include inference rules, cross-taxonomy mappings, and semantic constraints.

Capability	Taxonomy (3.1)	Ontology (future)
Structure	Hierarchical trees (parent/child)	Graphs with typed relationships
Relationships	"is a subcategory of"	"is related to," "excludes," "implies," "overlaps with"
Cross-system mapping	Not standardized; left to implementation	Declared mapping rules between taxonomies
Inference	None; categories are explicit	Rules engine: "if segment A and segment B, then exclude segment C"
Brand safety modeling	Category-level inclusion/exclusion	Contextual constraint graphs with severity and confidence
Granularity	Category IDs and hierarchy depth	Concept-level properties, weighted relationships, conditional applicability

This is crawl, walk, run for vocabulary itself. Taxonomy declaration in 3.1 is the crawl — make vocabulary visible. Ontology support in future versions is the walk and run — make vocabulary smart. You cannot skip to ontology without first establishing that agents can declare, inspect, and validate the classification systems they use. The taxonomy layer is the foundation.

---

Stakeholder considerations

Stakeholder	Consideration	Implication
Sellers	coverage: "partial" transparently advertises gaps in taxonomy support. Sellers may be incentivized to over-declare coverage to appear more capable.	The specification must define what "full" and "partial" mean with enough precision to be verifiable. Governance agents need a mechanism to test declared coverage against actual behavior.
Buyers (orchestrators)	Can route campaigns to sellers with compatible taxonomies, reducing misallocation risk and improving campaign performance.	Orchestrators gain a new optimization dimension. Campaign routing can factor in taxonomy alignment scores alongside price, reach, and audience quality.
Governance agents	Can contextualize semantic fidelity findings against declared taxonomy support. A seller with coverage: "partial" and an honest coverage_note gets different treatment than one claiming full support that fails verification.	Governance policies can reference taxonomy declarations: "flag any campaign where the seller's declared taxonomy version differs from the brief's taxonomy by more than one major version."
Brand safety	GARM category frameworks, IAS contextual segments, and DV content classifications are all taxonomies. They should be declarable through the same mechanism.	The taxonomy_id namespace must be extensible beyond IAB standards to accommodate brand safety classification systems, verification vendor taxonomies, and custom advertiser-specific segment definitions.

---

Crawl, walk, run

Crawl: optional and informational

supported_taxonomies is an optional field in the get_adcp_capabilities response. Sellers that include it provide useful signal. Sellers that omit it are not penalized — their capabilities response remains valid. Governance agents log taxonomy declarations when present but do not enforce them. Buyers can use the information for routing but are not required to. This phase establishes the field, encourages adoption, and generates data about how the ecosystem uses taxonomy declarations.

Walk: expected, with governance validation

supported_taxonomies becomes an expected field — not technically required, but its absence triggers a governance advisory. Governance agents validate that declared taxonomy_id values reference entries in a recognized taxonomy registry. A seller claiming iab-content-3.0 is checked against the registry to confirm the taxonomy exists and the declared version is valid. Coverage claims are logged and compared against delivery patterns over time: if a seller declares coverage: "full" but consistently misclassifies segments in the lower two levels, governance flags the discrepancy.

Run: required, with verification and gaming detection

supported_taxonomies is a required field. Sellers must declare their taxonomy support, and governance agents actively verify those declarations. Coverage verification uses sample-based testing: governance sends known-category content through the seller's classification pipeline and compares results against declared capabilities. Gaming detection identifies patterns of over-declaration — sellers claiming full coverage of taxonomies they demonstrably do not fully support. Persistent over-declaration affects governance trust scores and may trigger enhanced monitoring.

---

Backward compatibility

supported_taxonomies is a new optional field on the get_adcp_capabilities response. Existing 3.0 consumers that do not recognize the field will ignore it per standard JSON handling — no parsing errors, no behavior change. Sellers that do not include the field continue to work exactly as they do today. No existing schema is modified. The field follows the same additive pattern as content_standards, audience_targeting, and creative_specs — all of which were added to capabilities without breaking existing consumers. In crawl mode, the absence of supported_taxonomies is not an error — it simply means taxonomy context is unavailable for governance evaluation.

---

Open questions

1. Taxonomy registry. Who maintains the canonical registry of taxonomy IDs and versions? Is this an AAO-maintained registry, an IAB responsibility, or a decentralized system where taxonomy publishers register their own identifiers?

2. Gaming prevention. How do we prevent sellers from declaring coverage: "full" for taxonomies they only partially support? Coverage verification at the "run" phase requires tooling. What does that tooling look like, and who operates it?

3. Brand safety taxonomy inclusion. Should GARM categories, IAS segments, and DV classifications be first-class entries in supported_taxonomies? Or do brand safety taxonomies warrant their own declaration field (e.g., supported_safety_taxonomies) to distinguish classification systems used for targeting from those used for avoidance?

4. Coverage verification methodology. What constitutes acceptable coverage verification? Sample-based testing introduces statistical confidence questions. A seller could pass a 100-sample verification test but fail on edge cases in production. How do we balance verification rigor with practical overhead?

5. Path to ontology timeline. At what point does the ecosystem benefit from moving beyond taxonomy declarations to full ontology support? Is there a measurable signal — adoption rate, mismatch frequency, governance finding patterns — that indicates readiness for the next phase?

6. Custom and proprietary taxonomies. How should sellers declare proprietary classification systems that have no external registry entry? Should there be a taxonomy_type: "proprietary" flag with additional metadata requirements (documentation URL, mapping to a standard taxonomy, etc.)?

---

Working group context and prior decisions

This proposal builds directly on governance working group discussions and decisions already in motion:

Governance WG Slack discussion (April 2025): The working group established that there is no strict, predefined requirement for what a governance protocol must include — this will be agreed between buyer and seller within the framework of the Policy Registry and applicable regulations. The group agreed that maintaining an auditable log is recommended for self-protection, while the level of detail shared with counterparties remains open to interpretation where proprietary or commercial considerations apply. The consensus was to design a logging approach that supports both internal and shareable views.

Brian O'Kelley's response confirmed two key design points that inform this proposal:

• get_plan_audit_logs already returns budget tracking, validation history, and compliance summary grouped by governance_context (experimental in 3.0, 6-week change notice)
• The Policy Registry already does versioning, effective_date (informational before enforcement), and a hard invariant that bespoke policies can only add restrictions, never relax them

Issues and PRs already filed:

• Document campaign governance audit trail: internal vs shareable views #3139 — Document campaign governance audit trail: internal vs shareable views → Resolved via PR docs(governance): audit-trail internal-vs-shareable views + Addie anonymous knowledge tools #3175 (merged). Brian's PR adds docs/governance/campaign/audit-trail.mdx with field-by-field tagging (buyer-side, seller-shareable, regulator-shareable), 4-field minimum compliance attestation, and four worked examples across enforce/advisory/audit modes.
• Document Policy Registry sync pattern: version pinning, change handling, effective_date transitions #3140 — Document Policy Registry sync pattern: version pinning, change handling, effective_date transitions

Taxonomy declaration complements these decisions: #3175 defines what audit fields to share, while this proposal defines what vocabulary context to make visible so those audit findings are meaningful. A semantic fidelity finding that says "the seller mapped your term incorrectly" is incomplete without knowing what classification systems both parties were using.

Industry collaboration: Yahoo is co-leading the semantic matching and context graph workstreams within AdCP, and partnering with Google on the open-source BigQuery Agent Analytics SDK where these same vocabulary declaration patterns are being applied to agentic systems beyond advertising.

---

Relationship to other tracks

Semantic fidelity depends on taxonomy declaration. A governance agent cannot verify whether a seller correctly interpreted a buyer's intent without knowing what classification systems both parties were using. If the buyer's brief uses IAB Content Taxonomy 3.0 category codes and the seller operates against a proprietary taxonomy, semantic fidelity measurement must account for the translation layer. Taxonomy declaration makes that translation layer visible. See #3363 for the full semantic fidelity proposal.

Decision provenance references taxonomy declaration. When a governance agent audits the chain of decisions that led to a particular ad placement, it needs to know what classification systems informed each decision point. "The orchestrator selected this seller because the seller declared full IAB Content Taxonomy 3.0 support" is a provenance statement that depends on taxonomy declarations being part of the protocol record. See #3364 for the full decision provenance proposal.

Both tracks are weakened without taxonomy declaration. Semantic fidelity without vocabulary visibility is measuring accuracy without a baseline. Decision provenance without taxonomy context is recording decisions without recording the frameworks that informed them. Taxonomy declaration is the foundation that makes both capabilities meaningful.

---

Related: See also #3363 — Proposal: Semantic fidelity as a core governance capability (3.1) | #3364 — Proposal: Decision provenance and lineage as core governance capabilities (3.1) | #3365 — Proposal: AdCP Reference Media Ontology — a shared vocabulary for agentic advertising (3.1)

[bokelley]

Thanks for filing!

Triage

Classification: RFC / Proposal
Bucket(s): spec / protocol
Status: ready-for-human

What the experts said: (RFC path — scope adoption is a human decision, not an expert review question)

My take: Well-formed proposal to add optional supported_taxonomies to get_adcp_capabilities, following the same additive pattern as content_standards and audience_targeting. Six open questions — taxonomy registry governance, coverage verification methodology, gaming prevention — make this a working-group scope decision before it becomes a PR. This is the vocabulary-declaration layer that companion proposals #3363, #3364, and #3365 all depend on; the four should be evaluated as a cluster.

@bokelley, your call: (A) adopt into 3.1 governance track and assign to working group review; (B) defer to 3.2 pending registry/verification tooling; or (C) adopt only the field shape now and defer registry/governance questions to a follow-on issue.

---

Triaged by Claude Code. Session: https://claude.ai/code/cse_01EBJw8sDDjm8PuyiC2dcxRt

---

Generated by Claude Code

[bokelley]

Thanks for filing!

Triage

Classification: Proposal / RFC
Bucket: spec / protocol
Status: deferred

My take: supported_taxonomies on get_adcp_capabilities fills a real gap — buyers currently have no structured way to assess vocabulary compatibility before committing to a negotiation. This is part of a four-issue set (#3362, #3363, #3364, #3365) targeting 3.1; none are yet in the active 3.1 scoping list, so they're parked here pending the working group's scope decision.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_017ovY7JJhKSdu4k2qBzi4WC

---

Generated by Claude Code