Routing policies

Policy inputs

A routing policy evaluates information about a request and selects from routes available to that workload. Common inputs include task name, required capabilities, data classification, environment, region constraints, and caller authorization. Keep the set narrow enough that operators can understand it. A route should not be selected from user-controlled fields that have not been validated by the application.

Document each input, its source, and behavior when it is missing. If policy depends on a classification, define the vocabulary and who may assign it. If a workload requires a particular capability, express that as an eligibility condition. Avoid treating an unknown value as the least restrictive category.

Eligibility and selection

Evaluate hard constraints first. A route is ineligible when it cannot meet a required capability, violates an approved data rule, or is unavailable for the target environment. From the remaining candidates, apply selection preferences such as an approved default, workload fit, estimated resource use, or observed operational health. State the order so a reviewer can explain the outcome.

If two rules conflict, define which one wins. A missing or contradictory input should lead to a safe, visible outcome, such as a policy error that the caller can resolve. Do not quietly select a route that has not passed the same review as the intended route.

Fallback and failure behavior

Define which failures allow another route to be attempted. Provider unavailability may permit a fallback if the alternative meets the workload’s requirements. A policy rejection should not be bypassed by selecting a less restricted route. Set attempt and time limits, and return a normalized result that distinguishes successful fallback from the original route succeeding.

For actions that can change external state, consider whether retrying can duplicate an operation. Use idempotency keys or state checks when available, and reconcile uncertain outcomes before retry. If no eligible route remains, report the reason in an operator-readable way without exposing secret configuration.

Version and review changes

Assign an owner to each policy and store changes in a reviewable form. Record the policy version with the routing decision. Before changing a default, evaluate the candidate on representative examples and check the data and operational requirements. Use environment separation and a rollback path so a test configuration cannot silently replace production behavior.