check_governance
Universal governance check for campaign actions. Both the orchestrator (buyer-side) and the seller call this task — thebinding field discriminates the commitment level:
The governance agent maintains all state. Callers do not chain check IDs or track conversation history — they post the action, and the governance agent correlates by
plan_id + buyer_campaign_ref.
Binding levels
Proposed (orchestrator)
The orchestrator calls withbinding: "proposed" before sending a tool call to a seller. This is an advisory check — no budget is committed. The governance agent evaluates the intended tool and payload 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
escalated, orchestrator halts pending human review
Committed (seller)
The seller calls withbinding: "committed" when processing a request on an account that has governance_agents (set during sync_accounts). This is a binding check — budget will be committed if approved. The seller presents the authentication credentials from the agent’s configuration.
Committed checks cover the full media buy lifecycle through three phases:
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.
Status values
Expiration
expires_at is present when the status is approved or conditions. A lapsed approval is no approval — the caller must re-call check_governance before proceeding.
Conditions
When the status isconditions, the caller MUST re-call check_governance with adjusted parameters before proceeding. Conditions with a required_value are machine-actionable — the caller can programmatically apply the value. Conditions without a required_value are advisory — the caller should interpret the reason and adjust accordingly.
Governance agents SHOULD return denied (not conditions) after 3 unsuccessful re-calls for the same action. This prevents infinite negotiation loops, particularly for seller-side checks where the seller has no visibility into the campaign plan.
Escalation
When the status isescalated, the action is halted. The escalation object provides the reason, severity, and whether human approval is required. The caller must not proceed until the escalation is resolved.
For committed checks (seller-side), escalated is operationally equivalent to denied — the seller cannot hold a request indefinitely while waiting for human review on the buyer side. Sellers SHOULD treat escalated as denied, return an error to the orchestrator, and let the orchestrator handle the human-in-the-loop flow. After the escalation is resolved, the orchestrator re-initiates the media buy and the seller gets a new request.
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
Proposed (orchestrator checking before sending to seller)
governance_context is present, the governance agent uses it for plan validation instead of parsing tool-specific payload structures. The caller extracts governance-relevant fields into this canonical shape so the governance agent doesn’t need to understand every tool’s payload format.
Committed — purchase
Committed — modification
Committed — delivery
Response
approved (proposed)
create_media_buy to the seller before expires_at.
approved (committed purchase with delivery opt-in)
next_check signals that the governance agent expects delivery reporting starting at that time.
approved (committed delivery)
next_check.
denied (proposed)
denied (committed delivery — geo drift)
conditions (committed purchase)
check_governance with the updated parameters before proceeding.
conditions (committed delivery — overpacing)
check_governance immediately. The next_check is set closer than normal so the governance agent can verify the correction.
escalated
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