Skip to main content
policy.yaml holds named configuration values for a flow. They are referenced in CEL as policy.* and in prompts as {{variable}}.
policy.yaml

Inheritance

Policy is hierarchical. A child flow inherits the root and parent policy, and overrides specific keys:
Guards and prompt templates resolve a key by walking child → parent → root.

Budget thresholds

Cost control is configured here. When token spend crosses a declared percentage the platform emits platform.budget_threshold_crossed with a matching level:
If these keys are absent, budget monitoring is disabled. An emergency raises a mailbox item for a human. See Budget and cost.

Policy-sheet rows: business rules as typed tables

A handler can carry a list of rules:. Some rules decide which branch runs; others just compute a value the branch will use — by looking something up in a table, running a validation, or calling a compute module. Those tables and validations are declared here in policy. Condition rules (when:/case:/range:/else:) select the branch; value rows derive their values in the compute phase, before the handler decides what to do. The value rows come in three kinds: Lookup rows match an input tuple against an inline finite table:
nodes.yaml
A later rule reads computed.queue to pick the branch. Validation rows run a named validation set (declared under validation: in policy.yaml) and bind a typed result:
Compute-module rows run sandboxed algorithmic logic (Compute modules). The constraints on value rows:
  • Value rows derive only — they cannot emit, advance, or write state.
  • A condition rule consumes their computed.* binding and owns the branch.
  • One rule declares exactly one row type.
  • computed.* lives only for the handler — persist a value explicitly with data_accumulation.

Other policy-owned settings

policy.yaml is also where these are declared: