Skip to main content

check_governance

Universal governance check for campaign actions. Both the orchestrator (buyer-side) and the seller call this task — the binding 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 with binding: "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.
  1. Orchestrator decides to call a seller tool (e.g., create_media_buy)
  2. Orchestrator calls check_governance with the tool name and full payload
  3. If approved, orchestrator sends the tool call to the seller
  4. If denied, orchestrator does not send the tool call
  5. If conditions, orchestrator adjusts the payload and re-calls check_governance
  6. If escalated, orchestrator halts pending human review

Committed (seller)

The seller calls with binding: "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 is conditions, 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 is escalated, 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 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

Proposed (orchestrator checking before sending to seller)

When 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)

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

approved (committed purchase with delivery opt-in)

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 (committed delivery)

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

denied (proposed)

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

denied (committed delivery — geo drift)

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

conditions (committed purchase)

The seller MUST adjust its planned delivery, then re-call check_governance with the updated parameters before proceeding.

conditions (committed delivery — overpacing)

The seller MUST adjust pacing and re-call check_governance immediately. The next_check is set closer than normal so the governance agent can verify the correction.

escalated

The caller MUST NOT proceed. The action is halted until a human resolves the escalation.

Fields

Request

Delivery metrics

Response

Error codes