check_governance

Experimental. Campaign governance (sync_plans, check_governance, report_plan_outcome, get_plan_audit_logs) is part of AdCP 3.0 as an experimental surface — it may change between 3.x releases with at least 6 weeks’ notice. Sellers implementing it MUST declare governance.campaign in experimental_features. See experimental status for the full contract.

Universal governance check for campaign actions. Both the orchestrator (buyer-side) and the seller call this task. The governance agent infers the check type from the fields present:

Check type	Who calls	Discriminating fields	Purpose
Intent	Orchestrator	`tool` + `payload`	Validates the intended action before sending to a seller. No budget committed.
Execution	Seller	`planned_delivery` + `governance_context`	Validates what the seller will actually deliver. Budget is committed later via `report_plan_outcome`.

The governance agent maintains all state. Initial intent checks are addressed by plan_id; subsequent execution and lifecycle checks are addressed by the opaque governance_context. Services do not need the buyer’s plan ID and do not chain check IDs or track governance history. An account binds to one governance agent (see sync_governance and One governance agent per account). All lifecycle calls for a governed action go to that same agent.

Per-specialist review surfaces here. Internal decomposition (legal, brand safety, category) is not exposed as separate endpoints — it appears as agent-internal labels in categories_evaluated and, on denied, conditions, or informational approved responses, in findings[].details. Treat these values as opaque audit values; do not pattern-match against a fixed list.

Check types

Intent checks (orchestrator)

The orchestrator calls check_governance with tool and payload before sending a tool call to a seller. The governance agent evaluates the intended action against the campaign plan.

Orchestrator decides to call a seller tool (e.g., create_media_buy)
Orchestrator calls check_governance with the tool name and full payload
If approved, orchestrator sends the tool call to the seller
If denied, orchestrator does not send the tool call
If conditions, orchestrator adjusts the payload and re-calls check_governance
If the governance agent needs human review, the task goes async and eventually resolves to approved or denied

Runtime signal attestations

For an activate_signal intent check, the orchestrator MAY attach runtime_attestations[]: independently issued evidence that a signal-quality claim still holds at activation time. Each item is the shared portable AttestationReference, not a governance decision supplied by the buyer. AdCP does not define a credential issuance API or an orchestrator-side API for discovering or retrieving these references. Before calling check_governance, the orchestrator obtains each reference through an issuer-defined or other out-of-band mechanism. Evaluator-side resolution of a supplied credential locator still follows the portable-attestation procedure and the governance agent’s published allowlist. The governance agent advertises support in two capability locations:

adcp.attestations is the shared issuer, resolver, verifier, proof-format, and delivery allowlist.
governance.runtime_attestations.signal_activation declares whether evidence is optional or required for signal activation and which signal-quality claim types apply.

{
  "plan_id": "plan_nova_signal_launch",
  "caller": "https://buying.pinnacle-agency.example",
  "target_agent": "https://signals.meridian.example/adcp",
  "purchase_type": "signal_activation",
  "proposed_commitment": {
    "amount": 0,
    "currency": "USD"
  },
  "tool": "activate_signal",
  "payload": {
    "idempotency_key": "67da3ce4-f2aa-4b63-93a1-215106690f73",
    "signal_agent_segment_id": "segment_urban_commuters",
    "destinations": [
      {
        "type": "agent",
        "agent_url": "https://sales.streamhaus.example"
      }
    ]
  },
  "runtime_attestations": [
    {
      "issuer": {
        "type": "origin",
        "origin": "https://credentials.example"
      },
      "claim_type": "https://claims.example/audience/population-stability",
      "subject": {
        "type": "resource",
        "resource_type": "https://adcontextprotocol.org/claims/subjects/signal",
        "namespace": "https://signals.meridian.example/adcp",
        "id": "segment_urban_commuters"
      },
      "locator": {
        "type": "issuer_credential_id",
        "credential_id": "cred_population_2026_08",
        "resolver_id": "primary"
      },
      "content_digest": "sha256:cee39fac0bff75b76b0dd193c19e259d7bfed089dd9ae4a528a132d32ec7449a"
    }
  ]
}

For tool: activate_signal, the governance agent MUST confirm that each subject is the signal resource governed by the action. subject.id MUST match payload.signal_agent_segment_id; subject.namespace and any richer signal identity MUST match the signals agent and plan/action state known to the governance agent. The comparison is on the complete typed subject, not the opaque id alone. Runtime attestations apply only when payload.action is activate or omitted (the default). They MUST NOT be supplied for payload.action: deactivate. A capability with requirement: required requires evidence only for activation; missing evidence MUST NOT block deactivation. runtime_attestations[] is per-check evidence. It is not stored inside the plan and is not part of the plan_hash preimage. Delegation continuity remains plan-owned through delegations[]; runtime attestations do not create another delegation mechanism. For each presentation the response returns one runtime_attestation_evaluations[] item in the same order. The governance agent produces outcome, optional confidence, and reason_codes; buyer input cannot make those values authoritative. Each evaluation’s action_binding.action_id equals the response check_id.

{
  "check_id": "check_signal_001",
  "check_type": "intent",
  "verdict": "approved",
  "plan_id": "plan_nova_signal_launch",
  "explanation": "Signal activation is within plan policy and the required population-stability credential verified.",
  "runtime_attestation_evaluations": [
    {
      "reference_digest": "sha256:c3eeeaaad0916bb04f14940f21303ce0abf27296c4cf979ba9c22e2e8245ac07",
      "credential_digest": "sha256:cee39fac0bff75b76b0dd193c19e259d7bfed089dd9ae4a528a132d32ec7449a",
      "proof_format": "https://formats.example/jcs-signed-json",
      "outcome": "verified",
      "confidence": 0.98,
      "evaluated_at": "2026-08-04T12:00:00Z",
      "evaluated_by": "https://governance.example/adcp",
      "valid_until": "2026-08-04T13:00:00Z",
      "action_binding": {
        "action_type": "https://adcontextprotocol.org/actions/governance-check",
        "action_id": "check_signal_001"
      }
    }
  ],
  "runtime_attestation_binding_digest": "sha256:3a746f172de517f24ad53ec0c12a4ad39d0f02dcf7187aa92eb26760d9438934",
  "governance_context": "eyJhbGciOiJFZERTQSIsImtpZCI6ImdvdjIwMjYwOCIsInR5cCI6ImFkY3AtZ292K2p3cyJ9...",
  "expires_at": "2026-08-04T12:15:00Z"
}

runtime_attestation_binding_digest binds the ordered evaluations plus findings that carry attestation_reference_digest. The signed governance_context carries the same digest, and get_plan_audit_logs retains ordered { reference, evaluation } pairs plus the full attestation-bound findings. An auditor first recomputes each evaluation’s reference_digest from its paired reference, then recomputes the binding digest. When the capability says requirement: required, missing evidence cannot approve the signal activation. A supplied expired, revoked, invalid, subject-mismatched, or digest-mismatched credential MUST NOT be ignored or treated as verified. Off-policy issuers, resolver IDs, credential origins, and verifier nominations are rejected before network access. Resolution failures surface as normalized outcomes and are evaluated under plan policy; they never silently become verified.

Execution checks (seller)

The seller calls check_governance with governance_context and planned_delivery when processing a request on an account that has a governance agent configured (set via sync_governance). Execution checks are always binding — if the governance agent denies, the seller must not proceed. Before executing the check, the seller verifies the signed governance_context token that arrived on the protocol envelope from the buyer. The buyer produces an intent-phase token (per the JWS profile); the seller’s execution check produces a purchase token bound by opaque action sub, optionally adding a provisional media_buy_id. Modification and delivery tokens require the durable media_buy_id.

on receive(create_media_buy request):
  token = request.envelope.governance_context
  persist(token)                                      # always persist for audit/forwarding
  verify(token, {                                     # per Security — Signed Governance Context
    sellerId:    my_adagents_url,
    phase:       "intent",                             # buyer produces intent tokens
    mediaBuyId:  null,                                 # intent tokens have no media_buy_id
  })                                                  # throws on any of 15 checks failing
  candidate = prepare_without_commit(request)
  call check_governance(candidate.planned_delivery, token)
  proceed only if governance_agent verdict = approved
  commit(candidate)                                  # atomic after approval

Sellers that have not yet implemented verification MUST still persist and forward the token unchanged — auditors and regulators rely on this. Verification is the ramp from “forward-only” compliance to cryptographic accountability and can be adopted incrementally. Execution checks cover the full media buy lifecycle through three phases:

Phase	When	What’s checked
`purchase`	Before confirming `create_media_buy`	Budget, geo, channels, flight dates, policies
`modification`	Before confirming `update_media_buy`	Change magnitude, reallocation, new parameters
`delivery`	Periodically during delivery	Pacing, spend rate, geo drift, channel distribution

Sellers can adopt committed governance checks incrementally:

Level 1: Purchase only — One call per create_media_buy. The minimum viable integration.
Level 2: + Modification — One call per update_media_buy.
Level 3: + Delivery reporting — Periodic calls during active delivery.

Budget periods

When the plan declares budget.periods, the governance agent partitions budget authority by time as well as by purchase type. The buyer never has to name a period: the governance agent derives it from the dates of the action. The existing flight, budget.total, and budget.allocations checks still apply, so a dated commitment has to fit its period and its purchase-type allocation. Which period a buy belongs to. On an intent check or an execution check with phase purchase or modification, the governance agent finds the period that contains the action’s whole flight: payload.start_time to payload.end_time on an intent check, planned_delivery.start_time to planned_delivery.end_time on an execution check. A period runs from its start up to but not including its end, so a flight ending exactly on a boundary stays in the earlier period and a flight starting on it belongs to the later one. Because periods do not overlap, at most one period contains a flight. The governance agent MUST deny the action when:

no period contains the flight, including a flight inside the unallocated remainder or one that crosses a boundary, or
the incremental commitment would take that period over its amount, counting everything already committed to the period.

Both denials are denied verdicts with a critical finding. A denied response carries no governance_context. An asap start is evaluated as the time of the check, and boundaries are instants, not account-local dates. The flight comes from the task’s own fields: start_time and end_time, a flight object, or campaign dates. When a payload states the same side of its flight in more than one place, the values MUST agree; a payload that states two different flights is denied, because the service executes the task’s own fields and the governance agent must not place the buy by whichever field it read. Moving a buy. A modification whose new dates fall in a different period is checked as moving the buy’s whole commitment to that period: the period must have room for the buy’s existing commitment plus the incremental commitment, and the buy’s commitment leaves its old period when the modification settles. A modification whose new flight would straddle two periods is denied. A buy that needs to span two periods has to be two buys. A modification that states no dates keeps the flight the buy already has, and one that states only one end completes it from the buy’s retained flight. A buy is identified by its media_buy_id: the id carried by the modification or execution check, or, for the check that created it, the seller_reference the buyer reports on the completed outcome. A modification of a buy the governance agent has no settled commitment for, with no dates stated, cannot be placed and is denied. A seller’s planned_delivery on a modification SHOULD state the full resulting start_time and end_time. A modification that changes start_time or end_time so that the buy lands in a different period changes where its commitment is counted, even when the budget delta is zero or negative. The buyer SHOULD invoke check_governance for such a change and MUST NOT assume a decrease-only exemption covers it. Optional assertion. budget_period_id on the request lets a buyer assert which period it believes a buy belongs to. When present and different from the derived period, the check is denied. When the plan has no periods, or the action carries no flight, there is no derived period and the assertion cannot match, so the check is denied. Response. The response carries the matched budget_period_id whenever a single period contains the flight, on approved and denied verdicts alike, so the buyer can record which period each buy belongs to without re-deriving it. It is omitted when the plan has no periods, when the action carries no dates, and when no single period contains the flight. Retained flight. A governance agent MUST retain the flight of every dated commitment it settles, whether or not the plan had periods at the time, so that periods can be added to a plan that already has buys and the re-sync rules in sync_plans can be applied to them. Undated commitments. Periods govern commitments that carry a flight. An action without dates counts against budget.total and its purchase-type allocation only, and it never consumes a period’s amount. An action whose dates cannot be read, or that states only one end of its flight with nothing to complete it, MUST NOT bypass periods by being treated as undated; the governance agent denies it. Delivery checks. On delivery phase checks, a governance agent that evaluates pacing SHOULD evaluate it against the buy’s period rather than the whole plan flight. The buy’s period comes from the commitment the governance agent retained, not from dates the seller restates on the delivery check. A delivery check reports on a commitment that was already authorized, so it is not denied for its period.

{
  "$schema": "/schemas/3.3.0-beta.0/governance/check-governance-request.json",
  "plan_id": "nova-spring-2027",
  "caller": "https://orchestrator.example.com",
  "target_agent": "https://seller.example.com",
  "tool": "create_media_buy",
  "purchase_type": "media_buy",
  "budget_period_id": "q1",
  "proposed_commitment": { "amount": 25000, "currency": "USD" },
  "payload": {
    "idempotency_key": "nova-spring-q1-buy-0001",
    "total_budget": { "amount": 25000, "currency": "USD" },
    "start_time": "2027-01-15T00:00:00Z",
    "end_time": "2027-03-15T00:00:00Z"
  }
}

{
  "$schema": "/schemas/3.3.0-beta.0/governance/check-governance-response.json",
  "check_id": "chk_period_001",
  "check_type": "intent",
  "verdict": "approved",
  "plan_id": "nova-spring-2027",
  "budget_period_id": "q1",
  "explanation": "Flight sits inside budget period q1. Commitment: $25,000 of q1's $60,000.",
  "categories_evaluated": ["budget_authority", "flight_compliance", "budget_period"],
  "expires_at": "2027-01-14T01:00:00Z",
  "governance_context": "eyJhbGciOiJFZERTQSIsInR5cCI6ImFkY3AtZ292K2p3cyJ9.intent.signature"
}

A flight from 15 March to 15 April crosses the q1/q2 boundary, so the same plan denies it:

{
  "$schema": "/schemas/3.3.0-beta.0/governance/check-governance-response.json",
  "check_id": "chk_period_002",
  "check_type": "intent",
  "verdict": "denied",
  "plan_id": "nova-spring-2027",
  "explanation": "Flight 2027-03-15T00:00:00Z to 2027-04-15T00:00:00Z straddles budget periods q1 and q2; split it into one buy per period.",
  "findings": [
    {
      "category_id": "budget_period",
      "severity": "critical",
      "explanation": "Flight 2027-03-15T00:00:00Z to 2027-04-15T00:00:00Z straddles budget periods q1 and q2; split it into one buy per period."
    }
  ]
}

Governance agents that enforce periods declare governance.supports_budget_periods.

Invocation requirement

When a governance agent is configured on the plan, buyer agents MUST invoke check_governance before every operation classified by its request schema’s x-governed-commitment annotation. There is no dollar floor or cold-start exemption for commitment-bearing operations. Conditional tasks keep cancellation, pause, deactivation, decrease-only changes, estimates, and zero-cost retrieval outside the gate so governance cannot block risk-reducing cleanup. Service-side enforcement makes the MUST real through the signed governance_context token: a service receiving a governed commitment MUST require a valid, in-date intent-phase token addressed to that service. The service treats the context as the authoritative opaque plan binding; it does not require plan_id. Media-buy services that additionally declare online_execution_check prepare planned_delivery, call check_governance, and commit atomically only on approved. When no governance agent is configured on the plan, check_governance invocation is neither required nor meaningful — there is nothing to call. Sellers MAY refuse to transact on plans lacking a configured governance agent as a matter of their own commercial policy. See the specification for the full definition, including audit requirements, seller-side retention MUSTs, and interaction with idempotency.

Status values

Status	Meaning	Caller action
`approved`	Proceed as planned.	Act before `expires_at` or re-call.
`denied`	Do not proceed.	Return error to upstream caller.
`conditions`	Intent counterproposal; not authorization.	Apply conditions, then re-call `check_governance` with adjusted parameters.

Expiration

expires_at and governance_context are present only when the verdict is approved. A lapsed approval is no approval — the caller must re-call check_governance before proceeding.

Conditions

conditions is valid only for intent checks and carries no governance_context. It returns a separate consultation_context, which is only a negotiation handle: the buyer returns it with the adjusted plan_id + tool + payload re-check and MUST NOT send it to a service. The governance agent binds that handle to the authenticated principal, caller, plan, tool, purchase type, and target audience; any mismatch is rejected. The caller must receive approved before proceeding. Conditions with a required_value are machine-actionable; conditions without one describe the adjustment the buyer must make. Execution and lifecycle checks return either approved or denied. Governance agents SHOULD return denied after 3 unsuccessful intent re-calls for the same action. This prevents infinite negotiation loops.

Human review

When the governance agent determines that human review is required (e.g., the action exceeds the plan’s reallocation_threshold, or the plan carries human_review_required: true), it handles the escalation internally. The check_governance task goes async — the caller receives standard async task lifecycle statuses (submitted, working) and eventually gets approved or denied once the human acts. The caller does not need special handling for this case beyond supporting async tasks (see task lifecycle). For committed checks (seller-side), the seller sets a timeout. If the governance agent does not respond within the timeout, the seller treats it as denied and returns an error to the orchestrator. The orchestrator can re-initiate the media buy after the governance agent resolves.

Linking to outcomes

The response includes a check_id. Use this in report_plan_outcome to link outcomes to the governance check that authorized them.

When the governance agent is unavailable

If the governance agent is configured and the caller cannot reach it (timeout, network error), the caller MUST NOT proceed. Governance is a gate — when the gate is unreachable, the default is halt. The caller SHOULD retry with backoff and report the failure upstream.

Delivery cadence

The presence of next_check in a response is the signal that the governance agent expects ongoing delivery reporting. The seller SHOULD call no later than the next_check time. The governance agent MAY treat a missed deadline as a finding on the next delivery check.

Request

Intent check (orchestrator checking before sending to seller)

{
  "tool": "check_governance",
  "arguments": {
    "plan_id": "plan_q1_2026_launch",
    "caller": "https://orchestrator.example.com",
    "target_agent": "https://seller.example.com",
    "tool": "create_media_buy",
    "payload": {
      "idempotency_key": "buy-plan-q1-2026-001",
      "account": { "brand": { "domain": "acmecorp.com" }, "operator": "pinnacle-agency.example" },
      "brand": { "domain": "acmecorp.com" },
      "proposal_id": "prop_premium_video_300k",
      "total_budget": { "amount": 150000, "currency": "USD" },
      "start_time": "2026-03-15T00:00:00Z",
      "end_time": "2026-06-15T00:00:00Z"
    }
  }
}

On the first check_governance call, the governance agent extracts what it needs from payload. The response includes a governance_context string that the caller attaches to the protocol envelope and includes on all subsequent governance calls for this governed action. In 3.0 the governance agent MUST emit a compact JWS signed per the AdCP JWS profile so sellers can verify authenticity, authorization scope, and freshness (the 15-step seller checklist). Action-authorizing tokens critically bind authorized_task and the canonical authorized_payload_hash, so the receiving service can verify the request without access to governance-private state. The token also carries a required plan_hash audit-layer claim — see Plan binding and audit for canonicalization rules, retention obligations, and the eleven reference vectors governance-agent implementers SHOULD validate against before shipping.

Intent check (rights license)

{
  "tool": "check_governance",
  "arguments": {
    "plan_id": "plan_acme_summer_2026",
    "caller": "https://buying.pinnacle-agency.example",
    "target_agent": "https://rights.example.com",
    "purchase_type": "rights_license",
    "proposed_commitment": { "amount": 25000, "currency": "USD" },
    "tool": "acquire_rights",
    "payload": {
      "idempotency_key": "rights-acme-summer-2026-001",
      "account": { "brand": { "domain": "acmeoutdoor.com" }, "operator": "pinnacle-agency.example" },
      "rights_id": "acme-athlete-likeness-2026",
      "pricing_option_id": "standard_monthly",
      "buyer": { "domain": "acmeoutdoor.com" },
      "campaign": {
        "description": "AI-generated summer campaign creative",
        "uses": ["likeness"],
        "countries": ["US"],
        "start_date": "2026-04-01",
        "end_date": "2026-06-30"
      },
      "revocation_webhook": {
        "url": "https://buying.pinnacle-agency.example/webhooks/rights",
        "authentication": {
          "schemes": ["HMAC-SHA256"],
          "credentials": "rights_webhook_shared_secret_32_chars"
        }
      }
    }
  }
}

Execution check — purchase

{
  "tool": "check_governance",
  "arguments": {
    "caller": "https://seller.example.com",
    "governance_context": "gc_from_buyer_envelope",
    "phase": "purchase",
    "planned_delivery": {
      "media_buy_id": "mb_seller_456",
      "geo": { "countries": ["US"] },
      "channels": ["olv"],
      "start_time": "2026-03-15T00:00:00Z",
      "end_time": "2026-06-15T00:00:00Z",
      "total_budget": 150000,
      "currency": "USD",
      "frequency_cap": { "max_impressions": 3, "per": "user", "window": { "interval": 1, "unit": "days" } },
      "audience_summary": "Adults 25-54, US, premium video inventory",
      "enforced_policies": ["us_coppa"]
    }
  }
}

Execution check — modification

{
  "tool": "check_governance",
  "arguments": {
    "caller": "https://seller.example.com",
    "governance_context": "gc_from_buyer_envelope",
    "phase": "modification",
    "execution_commitment": { "amount": 50000, "currency": "USD" },
    "modification_summary": "Budget increase from $150,000 to $200,000 and flight extension to 2026-07-15.",
    "planned_delivery": {
      "media_buy_id": "mb_seller_456",
      "geo": { "countries": ["US"] },
      "channels": ["olv"],
      "start_time": "2026-03-15T00:00:00Z",
      "end_time": "2026-07-15T00:00:00Z",
      "total_budget": 200000,
      "currency": "USD",
      "frequency_cap": { "max_impressions": 3, "per": "user", "window": { "interval": 1, "unit": "days" } },
      "audience_summary": "Adults 25-54, US, premium video inventory",
      "enforced_policies": ["us_coppa"]
    }
  }
}

Execution check — delivery

{
  "tool": "check_governance",
  "arguments": {
    "caller": "https://seller.example.com",
    "governance_context": "gc_from_buyer_envelope",
    "phase": "delivery",
    "planned_delivery": {
      "media_buy_id": "mb_seller_456",
      "geo": { "countries": ["US"] },
      "channels": ["olv"],
      "start_time": "2026-03-15T00:00:00Z",
      "end_time": "2026-06-15T00:00:00Z",
      "total_budget": 150000,
      "currency": "USD",
      "frequency_cap": { "max_impressions": 3, "per": "user", "window": { "interval": 1, "unit": "days" } },
      "audience_summary": "Adults 25-54, US, premium video inventory",
      "enforced_policies": ["us_coppa"]
    },
    "delivery_metrics": {
      "statement_id": "stmt_mb_seller_456_0001",
      "statement_digest": "sha256:4b55f1157094ed8df2635250f71568701d294cb0da57845eba886a62e5434633",
      "sequence": 1,
      "issued_at": "2026-03-22T01:00:00Z",
      "reporting_period": {
        "start": "2026-03-15T00:00:00Z",
        "end": "2026-03-22T00:00:00Z"
      },
      "spend": 12500,
      "cumulative_spend": 12500,
      "currency": "USD",
      "impressions": 850000,
      "cumulative_impressions": 850000,
      "geo_distribution": { "US": 100 },
      "channel_distribution": { "olv": 100 },
      "pacing": "on_track",
      "audience_distribution": {
        "baseline": "platform",
        "indices": {
          "age:18-24": 0.8,
          "age:25-34": 1.4,
          "age:35-44": 1.3,
          "age:45-54": 1.1,
          "gender:female": 1.05,
          "gender:male": 0.95
        },
        "cumulative_indices": {
          "age:18-24": 0.85,
          "age:25-34": 1.35,
          "age:35-44": 1.25,
          "age:45-54": 1.1,
          "gender:female": 1.03,
          "gender:male": 0.97
        }
      }
    }
  }
}

Response

approved (intent check)

{
  "check_id": "chk_001",
  "check_type": "intent",
  "verdict": "approved",
  "plan_id": "plan_q1_2026_launch",
  "explanation": "Proposed create_media_buy is within plan parameters. Budget: $150,000 of $500,000 plan total. Geo: US (within plan). Channel: OLV (within 40-70% target range).",
  "categories_evaluated": ["budget_authority", "geo_compliance", "channel_compliance", "flight_compliance", "delegation_authority"],
  "policies_evaluated": ["us_coppa", "alcohol_advertising"],
  "expires_at": "2026-03-15T01:00:00Z",
  "governance_context": "eyJhbGciOiJFZERTQSIsInR5cCI6ImFkY3AtZ292K2p3cyJ9.intent.signature"
}

The orchestrator proceeds to send the create_media_buy to the seller before expires_at.

approved (execution check — purchase with delivery opt-in)

{
  "check_id": "chk_002",
  "check_type": "execution",
  "verdict": "approved",
  "explanation": "Planned delivery is within plan parameters. Budget: $150,000 of $500,000 plan total. Geo: US (within plan). Channel: OLV (within 40-70% target range).",
  "mode": "enforce",
  "expires_at": "2026-03-15T01:00:00Z",
  "governance_context": "eyJhbGciOiJFZERTQSIsInR5cCI6ImFkY3AtZ292K2p3cyJ9.purchase.signature",
  "next_check": "2026-03-22T00:00:00Z"
}

The seller proceeds with the media buy. The presence of next_check signals that the governance agent expects delivery reporting starting at that time.

approved (execution check — delivery)

{
  "check_id": "chk_003",
  "check_type": "execution",
  "verdict": "approved",
  "explanation": "Delivery on track. Week 1 spend: $12,500 of $150,000 (8.3%). Pacing is on target for 13-week flight. Geo and channel distribution match plan parameters.",
  "delivery_statement": {
    "statement_id": "stmt_mb_seller_456_0001",
    "statement_digest": "sha256:4b55f1157094ed8df2635250f71568701d294cb0da57845eba886a62e5434633",
    "sequence": 1,
    "issued_at": "2026-03-22T01:00:00Z",
    "seller_reference": "mb_seller_456",
    "reporting_period": {
      "start": "2026-03-15T00:00:00Z",
      "end": "2026-03-22T00:00:00Z"
    },
    "cumulative_spend": 12500,
    "currency": "USD",
    "canonical_payload": {
      "seller_reference": "mb_seller_456",
      "delivery_metrics": {
        "statement_id": "stmt_mb_seller_456_0001",
        "statement_digest": "sha256:4b55f1157094ed8df2635250f71568701d294cb0da57845eba886a62e5434633",
        "sequence": 1,
        "issued_at": "2026-03-22T01:00:00Z",
        "reporting_period": {
          "start": "2026-03-15T00:00:00Z",
          "end": "2026-03-22T00:00:00Z"
        },
        "spend": 12500,
        "cumulative_spend": 12500,
        "currency": "USD",
        "impressions": 850000,
        "cumulative_impressions": 850000,
        "geo_distribution": { "US": 100 },
        "channel_distribution": { "olv": 100 },
        "pacing": "on_track",
        "audience_distribution": {
          "baseline": "platform",
          "indices": {
            "age:18-24": 0.8,
            "age:25-34": 1.4,
            "age:35-44": 1.3,
            "age:45-54": 1.1,
            "gender:female": 1.05,
            "gender:male": 0.95
          },
          "cumulative_indices": {
            "age:18-24": 0.85,
            "age:25-34": 1.35,
            "age:35-44": 1.25,
            "age:45-54": 1.1,
            "gender:female": 1.03,
            "gender:male": 0.97
          }
        }
      }
    }
  },
  "expires_at": "2026-03-29T00:00:00Z",
  "governance_context": "eyJhbGciOiJFZERTQSIsInR5cCI6ImFkY3AtZ292K2p3cyJ9.delivery.signature",
  "next_check": "2026-03-29T00:00:00Z"
}

The seller continues delivery and schedules the next governance check for next_check.

denied (intent check)

{
  "check_id": "chk_004",
  "check_type": "intent",
  "verdict": "denied",
  "plan_id": "plan_q1_2026_launch",
  "explanation": "Proposed media buy targets CA (Canada) which is not within the plan's geography.",
  "findings": [
    {
      "category_id": "strategic_alignment",
      "severity": "critical",
      "explanation": "Geo targeting includes CA but plan only covers US.",
      "details": {
        "plan_countries": ["US"],
        "payload_countries": ["US", "CA"]
      }
    }
  ]
}

The orchestrator MUST NOT send the tool call to the seller.

conditions (intent counterproposal)

{
  "check_id": "chk_004b",
  "check_type": "intent",
  "verdict": "conditions",
  "plan_id": "plan_q1_2026_launch",
  "explanation": "Reduce the proposed budget before re-checking.",
  "consultation_context": "consult_01K1W8Q4X5Y6Z7",
  "conditions": [
    {
      "field": "payload.total_budget.amount",
      "required_value": 100000,
      "reason": "The proposed amount exceeds delegated authority."
    }
  ]
}

The buyer adjusts the indicated field on the complete request-arguments object and re-calls check_governance with the same plan_id, target_agent, tool, and consultation_context. Paths are rooted at that complete object, so payload.* changes the downstream task arguments while proposed_commitment.* changes the declared ceiling. The buyer does not send the consultation handle to the service.

denied (execution check — delivery geo drift)

{
  "check_id": "chk_005",
  "check_type": "execution",
  "verdict": "denied",
  "explanation": "Delivery has drifted outside plan parameters. 12% of impressions delivered in CA (Canada) which is not within the plan's geography.",
  "findings": [
    {
      "category_id": "strategic_alignment",
      "severity": "critical",
      "confidence": 0.98,
      "explanation": "Geo distribution shows 12% delivery in CA, but plan only covers US.",
      "details": {
        "plan_countries": ["US"],
        "actual_distribution": { "US": 88, "CA": 12 }
      }
    }
  ]
}

The seller MUST pause delivery immediately and correct the geo targeting before resuming.

Fields

Request

Field	Type	Required	Description
`plan_id`	string	Initial	Campaign governance plan identifier. Required before a context exists; optional on continuation checks. If sent with a context, it must match the token binding. Services do not require or interpret it.
`caller`	string (URI)	Yes	Claimed agent URL. The transport credential must resolve to the same URL, which is used for authorization and audit. Intent callers must be the authenticated plan owner or hold an active delegation; execution callers must match the preserved target audience.
`purchase_type`	enum	No	The kind of financial commitment being validated: `media_buy` (default), `rights_license`, `signal_activation`, or `creative_services`. When omitted, the governance agent assumes `media_buy`.
`target_agent`	string (URI)	Intent	Exact downstream service URL. Required on intent checks and signed as the token audience. It is routing metadata and is not included in `payload`.
`budget_period_id`	string	No	Optional assertion of the plan budget period this action belongs to. The buyer never has to name a period; the governance agent derives it from the action’s flight. Denied when it differs from the derived period. See Budget periods.
`proposed_commitment`	object	Conditional	Intent-only task-neutral `{amount, currency}`. Required for `buy_products`, `accept_proposal`, `control_media_buy`, `update_media_buy`, `acquire_rights`, commitment-increasing `update_rights`, `activate_signal`, and `build_creative`. For update/control it is the positive delta; for `accept_proposal` it derives from `proposal.commercial_terms`; for `buy_products` it derives from the purchase payload. Use amount `0` for a verified no-cost or non-increasing action.
`execution_commitment`	object	Update execution	Seller-computed `{amount, currency}` positive delta for `update_media_buy`. The seller derives it from authoritative current state atomically with the revision check and write. It must not exceed or change the currency of `proposed_commitment`; a mismatch requires a fresh intent.
`tool`	string	Intent	The AdCP tool being checked, including compact `buy_products`, `accept_proposal`, and `control_media_buy`. Present on intent checks; `tool` + `payload` identifies an intent check.
`payload`	object	Intent	Full downstream tool arguments exactly as they will be sent to `target_agent`. Present on intent checks.
`proposal`	CanonicalProposal	`accept_proposal`	Exact committed proposal being authorized. The governance agent verifies `terms_digest` over `commercial_terms` and binds that digest into its decision; the downstream payload carries the same digest.
`governance_context`	string	Execution	Opaque context from a prior approved response. Required with `planned_delivery` or `delivery_metrics`; the governance agent derives the plan from it. Services persist and forward it without business-level parsing.
`consultation_context`	string	Intent re-check	Non-authorizing handle from a conditions response. Return only with the adjusted intent and the same authenticated principal, caller, plan, tool, purchase type, and target audience; never forward it to a service.
`phase`	enum	Execution	`purchase`, `modification`, or `delivery`. Defaults to `purchase`. Present on execution checks.
`planned_delivery`	object	Execution	What will actually be delivered. Present on execution checks. When `total_budget` is present, `currency` is required and must equal the intent-authorized currency. Creates compare the total with the ceiling. Updates carry their seller-computed positive delta separately in `execution_commitment`; `total_budget` remains the post-update delivery total. `media_buy_id` is optional during purchase prepare and required for modification/delivery. See planned delivery.
`delivery_metrics`	object	Delivery	Seller-attributed canonical delivery statement. Required when `phase` is `delivery`; it describes an existing commitment and is never charged again.
`delivery_metrics.statement_id`	string	Delivery	Immutable seller-issued statement ID. Reuse with different content is a conflict.
`delivery_metrics.statement_digest`	string	Delivery	`sha256:` plus lowercase hex SHA-256 of RFC 8785 JCS over `{seller_reference, delivery_metrics}`, excluding this field.
`delivery_metrics.sequence`	integer	Delivery	Monotonically increasing sequence for the governed action.
`delivery_metrics.issued_at`	date-time	Delivery	When the seller issued the statement.
`delivery_metrics.reporting_period`	object	Delivery	Exact start and end timestamps for this statement.
`delivery_metrics.cumulative_spend`	number	Delivery	Finite, non-negative cumulative seller-attributed spend.
`delivery_metrics.currency`	string	Delivery	Plan currency for spend fields.
`delivery_metrics.audience_distribution`	object	No	Audience demographic composition relative to a baseline. Used for bias/fairness drift detection.
`delivery_metrics.audience_distribution.baseline`	enum	Yes	Reference population: `census` (national population), `platform` (platform’s user base), or `custom`.
`delivery_metrics.audience_distribution.baseline_description`	string	No	Description of the baseline when `baseline` is `custom` (e.g., “US adults 18+ with broadband access”).
`delivery_metrics.audience_distribution.indices`	object	Yes	Index values for the current reporting period. Key format: `dimension:value` (e.g., `age:25-34`, `gender:female`). Value of 1.0 means parity with baseline; above 1.0 means over-indexed; below 1.0 means under-indexed.
`delivery_metrics.audience_distribution.cumulative_indices`	object	No	Index values across all reporting periods. Same format as `indices`. Helps governance agents detect trends vs. one-period noise.
`modification_summary`	string	No	Human-readable summary of what changed. SHOULD be present for `modification` phase.
`runtime_attestations`	AttestationReference[]	No	Signal-quality evidence for `purchase_type: signal_activation`; maximum 10. When supplied, `tool` is required and must be `activate_signal`. Items use the shared portable-attestation schema and cannot carry an authoritative buyer decision or confidence.

Delivery metrics

Field	Type	Description
`reporting_period`	object	Reporting window with `start` and `end` timestamps (ISO 8601). Required.
`spend`	number	Spend during the reporting period.
`cumulative_spend`	number	Total spend since the media buy started.
`impressions`	integer	Impressions during the reporting period.
`cumulative_impressions`	integer	Total impressions since the media buy started.
`geo_distribution`	object	Actual geographic distribution. Keys are ISO 3166-1 alpha-2 codes, values are percentages.
`channel_distribution`	object	Actual channel distribution. Keys are values from the channels enum, values are percentages.
`pacing`	enum	`ahead`, `on_track`, or `behind`.
`audience_distribution`	object	Audience composition relative to a baseline. Contains `baseline` (enum), optional `baseline_description` (string, for custom baselines), `indices` (current period), and optional `cumulative_indices` (all periods). Keys are `dimension:value` strings, values are index numbers (1.0 means parity).

Response

Field	Type	Description
`check_id`	string	Unique identifier for this governance check. Use in `report_plan_outcome` to link outcomes.
`check_type`	enum	`intent` or `execution`. Conditions are valid only for intent.
`verdict`	enum	`approved`, `denied`, or `conditions`.
`plan_id`	string	Echoed on an initial plan-addressed check; optional on context-addressed continuation checks.
`budget_period_id`	string	The plan budget period that contains the action’s whole flight. Present when the plan has periods and the action is dated and one period contains it, on any verdict. See Budget periods.
`explanation`	string	Human-readable explanation of the decision.
`findings`	array	Per-category issues found. Present when `verdict` is `denied` or `conditions`. MAY also be present on `approved` for informational findings. Each finding has `category_id`, `severity`, `explanation`, and optionally `policy_id`, `details`, `confidence` (0-1), `uncertainty_reason`, and `attestation_reference_digest` when it relies on a runtime evaluation. `category_id` is an agent-internal label, not a protocol-level enum — treat as opaque for display/audit, not for machine pattern-matching.
`conditions`	array	Intent-only counterproposal. `field` is rooted at the complete check request arguments (for example `payload.total_budget.amount` or `proposed_commitment.amount`). Adjustments must be re-checked and never authorize execution.
`consultation_context`	string	Present only with `conditions`. Correlates negotiation attempts but carries no authorization.
`categories_evaluated`	string[]	Governance categories evaluated during this check (e.g., `budget_authority`, `geo_compliance`, `channel_compliance`). Agent-internal labels — each string is defined by the governance agent’s policy model and is how internal specialist review (legal, brand safety, category) surfaces for audit from behind the agent’s single endpoint. Not a protocol enum; not safe to pattern-match against a fixed list.
`policies_evaluated`	string[]	Registry policy IDs evaluated during this check.
`mode`	enum	`audit`, `advisory`, or `enforce` — governance mode active when this check was evaluated. Recorded by the governance agent from its runtime configuration at check time, not from a plan field. Lets counterparties, regulators, and auditors distinguish whether an `approved` decision reflects deliberate `enforce` enforcement or `audit`-mode silent logging.
`expires_at`	string	Present only when `verdict` is `approved`. The caller must act before this time or re-call.
`next_check`	string	When the seller should next call `check_governance` with delivery metrics. Present when the governance agent expects ongoing delivery reporting.
`delivery_statement`	object	Canonical retained seller statement. Present on delivery execution checks and used by the buyer as the exact reconciliation target in `report_plan_outcome`.
`delivery_statement.canonical_payload`	object	Exact `{seller_reference, delivery_metrics}` record retained so auditors can recompute the statement digest after excluding `statement_digest`.
`runtime_attestation_evaluations`	AttestationEvaluation[]	Ordered evaluator-of-record results, exactly one per request presentation. Each result binds to `check_id`.
`runtime_attestation_binding_digest`	string	Required with runtime evaluations. Digest of ordered evaluations and attestation-bound findings; the signed governance context and audit log carry the same value.
`governance_context`	string	Opaque authorization context. Present only when `verdict` is `approved`. Attach it to the protocol envelope and forward it on subsequent governance calls; conditions and denied responses never carry one. When runtime attestations are evaluated, the signed context carries the same `runtime_attestation_binding_digest` returned in the response.

Error codes

Code	Recovery	Description
`PLAN_NOT_FOUND`	correctable	No plan with this ID. The buyer may not have synced the plan yet.
`VALIDATION_ERROR`	correctable	The request mixes intent and execution fields, omits a shape-dependent field such as `target_agent` or `execution_commitment`, changes a consultation binding, or carries an invalid amount/currency. Correct the named field and retry; send exactly one check shape.
`CAMPAIGN_SUSPENDED`	transient	Campaign governance is suspended pending human review. Wait for the escalation to resolve; contact the plan operator if it persists.
`PERMISSION_DENIED`	correctable	Authenticated identity is missing/mismatched, the buyer-side caller is not authorized by `delegations`, or the target/executing service is not authorized by `approved_sellers`. Retry only with the correct authenticated identity or after authority is granted.
`GOVERNANCE_UNAVAILABLE`	transient	The configured governance agent could not be reached. Retry with backoff; do not perform the governed action while the gate is unavailable.

sync_plans — The plan this governance check validates against
report_plan_outcome — Report what happened after the action was confirmed
get_plan_audit_logs — View plan state and audit trail

​check_governance

​Check types

​Intent checks (orchestrator)

​Runtime signal attestations

​Execution checks (seller)

​Budget periods

​Invocation requirement

​Status values

​Expiration

​Conditions

​Human review

​Linking to outcomes

​When the governance agent is unavailable

​Delivery cadence

​Request

​Intent check (orchestrator checking before sending to seller)

​Intent check (rights license)

​Execution check — purchase

​Execution check — modification

​Execution check — delivery

​Response

​approved (intent check)

​approved (execution check — purchase with delivery opt-in)

​approved (execution check — delivery)

​denied (intent check)

​conditions (intent counterproposal)

​denied (execution check — delivery geo drift)

​Fields

​Request

​Delivery metrics

​Response

​Error codes

​Related tasks

check_governance

Check types

Intent checks (orchestrator)

Runtime signal attestations

Execution checks (seller)

Budget periods

Invocation requirement

Status values

Expiration

Conditions

Human review

Linking to outcomes

When the governance agent is unavailable

Delivery cadence

Request

Intent check (orchestrator checking before sending to seller)

Intent check (rights license)

Execution check — purchase

Execution check — modification

Execution check — delivery

Response

approved (intent check)

approved (execution check — purchase with delivery opt-in)

approved (execution check — delivery)

denied (intent check)

conditions (intent counterproposal)

denied (execution check — delivery geo drift)

Fields

Request

Delivery metrics

Response

Error codes

Related tasks