Conditional rules

One policy that reshapes itself per request.

Rules read the submitted payload and change the route before the first stage activates. They run once, at submission, in priority order, and the resolved route is frozen onto the request so later policy edits never disturb in-flight work.

Anatomy of a rule

{
  "id": "high-value-executive",
  "priority": 1,
  "conditions": [{ "field": "amount", "operator": "gt", "value": 50000 }],
  "actions": [{ "type": "add_stage", "stage": {
    "order": 3, "name": "Executive approval", "mode": "any_of", "approverRole": "approval_admin"
  }}]
}

Operators

eq, neq, gt, gte, lt, lte, in, not_in, contains, starts_with, ends_with, empty, not_empty, between.

Actions

Action	Effect
`add_stage`	Appends a stage to this request’s route
`skip_stage`	Removes a stage by its order
`auto_approve`	Finalizes the request as approved immediately

What the builder exposes

The policy builder keeps rules deliberately simple: one condition, one action per rule. That ceiling is a product decision. Routing stays explainable to the person waiting on the outcome.