Governance taxonomy cleanup — consolidate, reclassify, and fill the creative-review gap

[bokelley]

Issue: rationalize the governance specialism taxonomy

Type: specialism enum / taxonomy clarity
Severity: high (blocks SDK platform-interface design; confuses adopters about what each agent IS)
Target: 3.x minor (additive: deprecate-then-remove some, add new) or 4.0 (if rename consolidations are breaking)

Problem

The current AdCP 3.0 GA AdCPSpecialism enum has 7 governance-adjacent values that don't form a coherent taxonomy:

governance-aware-seller
governance-delivery-monitor
governance-spend-authority
property-lists
collection-lists
content-standards
brand-rights      // related but separate; out of scope for this issue

Three concrete problems:

1. governance-aware-seller is a category error

It's not a governance agent — it's a seller scenario. A seller that respects governance signals (spending authority decisions, delivery monitor alerts) is just a good seller; this should be a compliance test every sales-* storyboard runs, not a separate specialism that an agent picks. Same pattern as signed-requests (cross-cutting compliance, not a separate specialism).

Empirical: surfaced during AdCP @adcp/client v6.0 SDK be-Emma test. The category mismatch was immediately visible — adopters reading the enum couldn't tell whether governance-aware-seller meant "I am a governance agent that's aware of sellers" or "I am a seller that's aware of governance." The latter was the spec intent; that's a sales scenario, not a separate role.

2. governance-spend-authority + governance-delivery-monitor aren't two things

Both describe a single role — an agent that makes runtime governance decisions for advertiser campaigns. The spec splits them by capability (gates spend vs. monitors delivery), but a single agent typically does both. Listing them as separate specialisms forces adopters to claim two specialisms for what's one role, and forces SDKs to design two platform interfaces for what's one shape (decision API).

3. There's a missing specialism: creative-review

content-standards is the rulebook (declarative, semi-static: "We don't run political ads in this market"). It's distinct from the runtime decision ("This specific creative is approved/rejected at submission time").

Today, runtime creative review is done inline by sellers (sync_creatives returns approved/rejected per row). There's no specialism for standalone creative-review-as-a-service agents — services that any seller can plug into for runtime per-creative approval. Brand-suitability vendors (DoubleVerify-style), GARM/IAB review services, and content-moderation platforms have no specialism to claim.

Proposal

A. Reclassify governance-aware-seller → cross-cutting compliance scenario

Mirror the signed-requests pattern. Remove governance-aware-seller from the AdCPSpecialism enum. Add a normative compliance scenario every sales-* storyboard runs (the seller MUST honor governance signals when an account has a registered governance agent).

Backwards compat: 3.x minor deprecates the enum value and emits a one-cycle warning when claimed; 4.0 removes it.

B. Consolidate to campaign-governance (1 specialism, both capabilities)

Replace governance-spend-authority and governance-delivery-monitor with a single campaign-governance specialism. The agent's get_adcp_capabilities response declares which capabilities it offers (spend-authority, delivery-monitor) via boolean flags or a capability enum.

// Today
specialisms: ['governance-spend-authority', 'governance-delivery-monitor']

// After
specialisms: ['campaign-governance']
capabilities: {
  campaign_governance: { spend_authority: true, delivery_monitor: true }
}

Backwards compat: 3.x minor accepts both old + new; deprecates the two old values; 4.0 removes them.

C. Add creative-review as a new specialism

Fills the gap. Standalone runtime per-creative review service. Distinct from content-standards (the rulebook):

Specialism	What	When invoked
content-standards	Declarative rulebook / taxonomy	Sellers fetch periodically
creative-review (NEW)	Runtime decision per submitted creative	Sellers call on each sync_creatives

Tools the spec would define:

• review_creative(creative) → { approved \| rejected \| pending_review, reason?, review_id }
• Status changes via the existing creative resource subscription channel

Backwards compat: purely additive.

D. Keep property-lists, collection-lists, content-standards as distinct specialisms

These are not redundant — each has its own shape (CRUD on different list/rule types). They sit under the "governance umbrella" narratively but the platform interface for each is distinct enough that consolidation would lose information.

Open question: do property-lists and collection-lists share enough shape (CRUD on authorization lists) to fold into one lists specialism with a kind: 'property' \| 'collection' discriminator? Either way works; adopters' preference should drive this.

Resulting governance taxonomy (after consolidation)

Specialism	Role	Shape
campaign-governance	Runtime decisioning for campaigns (spend + delivery)	Decision API
creative-review (NEW)	Runtime per-creative approval	Decision API
content-standards	Rulebook / taxonomy publishing	CRUD on rules
property-lists	Authorized property lists	CRUD on lists
collection-lists	Authorized collection lists (program-level brand safety)	CRUD on lists

Five governance specialisms (or four if lists fold). All share the umbrella conceptually; each has distinct platform shape.

Files affected

• schemas/v3/core/enums/adcp-specialism.json — remove governance-aware-seller, governance-spend-authority, governance-delivery-monitor; add campaign-governance, creative-review
• compliance/cache/{version}/specialisms/ — new compliance storyboards for campaign-governance, creative-review; cross-cutting scenario for governance-aware-seller folded into sales-* storyboards
• New tool definitions: review_creative-request.json / review_creative-response.json for the creative-review specialism
• docs/llms.txt — narrative taxonomy doc: governance umbrella, the 5 specialisms

Why this matters beyond the SDK

SDKs (including @adcp/client v6.0) need to design platform interfaces against the spec's specialism enum. Today's taxonomy forces SDKs to either:

1. Ship a confused interface that conflates the three governance specialisms (loses information)
2. Ship 7 separate interfaces (over-fragments)
3. Wait — which is what we're doing — and not ship governance interfaces until the taxonomy clarifies

Option 3 is fine for the SDK but blocks downstream tooling. The taxonomy fix unblocks 4-5 platform interfaces in the v6.0 SDK and equivalent shapes in any future Python / Go ports.

Source

Surfaced during AdCP @adcp/client v6.0 SDK design + a series of be-Emma adopter simulations (rounds 4-6). Specifically:

• The governance-aware-seller category error became visible when running the simulation against sales-guaranteed: the broadcaster needed to honor governance signals, but governance-aware-seller reads as a governance-agent specialism, not a sales scenario.
• The spend/delivery split became visible when sketching SDK platform interfaces — both required the same shape (runtime decision API).
• The creative-review gap became visible when designing what content-standards was vs. what runtime per-creative review services need.