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.
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.
Check types
Intent checks (orchestrator)
The orchestrator callscheck_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_governancewith 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-callscheck_governance - If the governance agent needs human review, the task goes async and eventually resolves to
approvedordenied
Runtime signal attestations
For anactivate_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.attestationsis the shared issuer, resolver, verifier, proof-format, and delivery allowlist.governance.runtime_attestations.signal_activationdeclares whether evidence isoptionalorrequiredfor signal activation and which signal-quality claim types apply.
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.
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 callscheck_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.
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.
Invocation requirement
When a governance agent is configured on the plan, buyer agents MUST invokecheck_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
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’sreallocation_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 acheck_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 ofnext_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)
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)
Execution check — purchase
Execution check — modification
Execution check — delivery
Response
approved (intent check)
create_media_buy to the seller before expires_at.
approved (execution check — purchase with delivery opt-in)
next_check signals that the governance agent expects delivery reporting starting at that time.
approved (execution check — delivery)
next_check.
denied (intent check)
conditions (intent counterproposal)
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)
Fields
Request
Delivery metrics
Response
Error codes
Related tasks
sync_plans— The plan this governance check validates againstreport_plan_outcome— Report what happened after the action was confirmedget_plan_audit_logs— View plan state and audit trail