Policies

A policy answers six questions:

When an intent is submitted, the system selects the applicable policy and enforces its workflow.

Policy selection happens in this order:

1. Filter by scope: Find policies that apply to the target domain.
2. Filter by intent type: Keep policies whose intentTypes match the intent. If intentTypes is omitted, the policy can match all intent types.
3. Filter by intent origin: Keep policies whose intentOrigin matches how the proposal entered the system.
4. Evaluate conditions: Keep policies whose condition evaluates to true. A missing condition always matches.
5. Select by rank: Choose the highest-ranked matching policy.
6. Apply workflow: Require approvals from the selected workflow.

If no policy matches, the intent cannot execute.

Intent types identify the operation being proposed.

Omitting intentTypes creates a catch-all policy. Use this only for deliberate fallback or emergency controls.

Most policies govern user-signed proposals. If intentOrigin is omitted, the policy behaves as UserSigned and does not match system-signed proposals.

System-signed proposals are API-only. They are submitted without a client-side payload signature, signed by the platform internally, and matched only by policies with intentOrigin: "SystemSigned".

Use system-signed policies narrowly. Specify explicit intentTypes, keep the scope deliberate, and use conditions that check the service submitter. For example:

{
  "intentOrigin": "SystemSigned",
  "intentTypes": ["v0_CreateTransactionOrder"],
  "condition": {
    "expression": "context.submitter.type === 'Service' && context.submitter.custodyRoles.includes('gas-station-service')",
    "type": "Expression"
  }
}

Omit workflow only when automatic execution is intentional. If a system-signed policy includes a workflow, user-signed approvers must complete that workflow. System-signed approve and reject requests are not part of the API.

Conditions are JavaScript expressions that decide whether a policy applies.

{
  "condition": {
    "expression": "context.request.payload.parameters.amount > 50000000000n",
    "type": "Expression"
  }
}

Use conditions to distinguish business cases:

• Transaction amount.
• Ledger or asset.
• Destination type.
• Endpoint trust score.
• Author role.
• Service submitter role or subject.
• Role being assigned.
• Time window.
• Compliance status.

Policy conditions can use context.request for the current intent and context.references for entities referenced by the intent. For the full JavaScript reference, see Policy reference.

Workflows define who must approve an intent.

{
  "workflow": [
    { "role": "operator", "quorum": 1, "type": "RoleQuorum" },
    { "role": "compliance", "quorum": 1, "type": "RoleQuorum" }
  ]
}

For user-signed proposals, the maker's submitted intent counts as the first approval. If the first step requires operator, the maker must have operator. If the first step requires quorum 2, the maker plus one other eligible user must approve.

For system-signed proposals, the service submitter proposes the intent but does not provide a user approval. Any approval workflow is completed by user-signed approvers.

Workflow objects:

Policy scope works with domain governing strategy.

In a hierarchy, both target-domain policies and ancestor-domain policies may be relevant. The domain governing strategy decides how parent and child policies interact:

For domain behavior, see Domains.

Rank controls priority among matching policies. Higher rank wins.

Use rank intentionally:

• Higher rank for more specific, higher-risk cases.
• Standard rank for routine workflows.
• Low rank for catch-all fallback policies.
• High rank for emergency policies only when their intent types and scope are explicit.

A breakglass policy provides an emergency path for exceptional scenarios such as court orders, urgent freezes, lost access, or recovery from misconfiguration.

Good breakglass policies have:

• Explicit intent types.
• Narrow scope.
• High quorum.
• Independent approvers.
• Clear operating rules.

Breakglass is not a substitute for normal policy design. It should be part of Design your policies and included in the launch review before running Genesis.

Policies are created, updated, locked, and unlocked through intents. Policy-management policies should be stricter than routine operational policies because they control how governance can change.

For operations, see Manage policies. For examples, see Policy examples. For schema, workflow syntax, condition syntax, JavaScript rules, and common mistakes, see Policy reference.