Skip to main content

​
Governance responsibilities: buyer vs. seller

Campaign Governance uses the same check_governance task from two different positions in the transaction. The buyer-side orchestrator checks intent before it sends an action. The seller checks execution before it commits or changes delivery. Both checks go to the buyer’s configured governance agent, but they carry different evidence.

​
Roles

​
Setup: bind the seller to the governance agent

Before a seller can make seller-side checks, the buyer account must sync governance agent endpoints with the seller via sync_governance. This is account setup, not per-buy negotiation. The seller stores the configured governance agent endpoint and credentials for the account. Later, when a governed request arrives, the seller knows where to call check_governance.

​
Buyer-side intent check

The buyer-side orchestrator calls check_governance before every spend-commit action on a governed plan. The intent check sends: Only approved returns a governance_context token. The orchestrator attaches that token to the request it sends to the service. A conditions response instead carries consultation_context, a non-authorizing negotiation handle that the orchestrator returns only with the adjusted intent re-check. The governance agent binds the handle to the authenticated principal, caller, plan, tool, purchase type, and target audience and rejects a mismatch.

​
Seller-side execution check

When a seller receives a governed spend-commit request, it performs an independent execution check before confirming the action. The seller-side check sends: The seller must not treat the buyer’s intent check as sufficient by itself. The seller checks what it will actually deliver, which may differ from the buyer’s request because of inventory availability, seller defaults, or implementation constraints. The execution check is binary. If the governance agent denies it, the seller must not proceed; a conditions response is invalid on this path and does not authorize a commit.

​
Outcome reporting

After a seller responds, the buyer-side orchestrator calls report_plan_outcome. This lets the governance agent reconcile the approved action with the seller’s actual response and update budget state from confirmed outcomes. Outcome reporting is what prevents the governance agent from counting attempted actions as committed spend. The governance agent tracks the state that actually happened.

​
Common mistakes

​
Minimal sequence

  1. Buyer configures governance on the account with sync_governance.
  2. Buyer creates or updates a plan with sync_plans.
  3. Buyer calls check_governance with tool and payload.
  4. Buyer sends the seller request with governance_context.
  5. Seller prepares a candidate and calls check_governance with governance_context, caller, and planned_delivery.
  6. Seller commits atomically on approved or rejects on denied.
  7. Buyer calls report_plan_outcome with the seller result.
See the check_governance task reference for request and response fields, and the Campaign Governance specification for lifecycle and token validation details.