GovernAI policies are written in a small YAML-based syntax and evaluated in order — the first matching rule in a policy file determines the outcome, so more specific rules should come before general ones.
Basic structure
rules:
- match:
task_type: "customer_support"
contains_pii: true
action: redact_then_allow
route_to: "standard"
- match:
task_type: "code_generation"
action: allow
route_to: "code-optimized"
- match:
team: "finance"
spend_this_cycle: "> 80%_of_budget"
action: require_approval
notify: "team-lead"Match fields
| Field | Description |
|---|---|
task_type | The classified task category for the request (e.g. drafting, classification, code_generation). |
team | The requesting user's team, resolved from SSO group membership. |
contains_pii | Boolean, set by the platform's automatic PII detection on the request content. |
connector_source | Matches requests that retrieved content from a specific named connector. |
spend_this_cycle | Supports comparison expressions against the team or org budget for the current billing cycle. |
Action types
| Action | Effect |
|---|---|
allow | Request proceeds without modification. |
redact_then_allow | Detected PII fields are tokenized before the request reaches a model provider, and re-inserted in the final response shown to the user. |
require_approval | Any resulting write action is queued for a named approver instead of executing automatically. |
block | Request is rejected before reaching any model, and logged with the triggering rule. |
Routing directives
The route_to field accepts either a named model pool (defined once in your organization's routing configuration and reused across policies) or a specific model identifier for cases that need to pin an exact model.
routing_pools:
standard: ["primary-flagship", "secondary-flagship"]
code-optimized: ["code-model-a", "code-model-b"]
low-cost: ["compact-model-a"]Testing a policy before publishing
Every policy change can be run in shadow mode first — evaluated against live traffic and logged, without actually affecting request handling — so you can confirm a new rule matches what you expect before it goes live.