Workflows (Policy Engine).
Versioned per-request policy bundles that govern how every API call is routed, cached, budgeted, and audited.
What Are Workflows
A workflow is a versioned collection of policies applied to every request that matches its scope fields. Each workflow acts as an independent policy document — you can iterate on one workflow without affecting others. When a request arrives, the gateway evaluates all matching workflows and merges their configurations to determine the final behaviour for that request.
workflow:
id: "my-workflow"
version: 3
scope:
provider_name: "openai"
model: "<model id>"
user_path: "/org/eng"Scope Fields
Each workflow carries three scope fields that determine which requests it applies to:
provider_name
Matches the target provider (e.g. openai, anthropic). Can be a comma-separated list or * for all.
model
Matches the target model ID returned by the gateway model list. Supports glob patterns.
user_path
A hierarchical path derived from the API key or OIDC identity. Supports prefix matching for inheritance.
Feature Flags
Every workflow can enable or disable the following features independently:
cache
Enable L1 / L2 caching for matched requests. When disabled, requests bypass all cache layers.
budget
Enforce spending limits and quota checks. Tracks token and dollar usage against configured budgets.
audit
Log every request and response to the audit log store for compliance and replay.
usage
Record usage analytics — token counts, latency, model, and user metadata for dashboards.
guardrails
Apply configured guardrail pipelines to all matching requests.
fallback
On provider failure, automatically retry with the next available provider or model.
Matching & Precedence
When multiple workflows match a request, the gateway resolves conflicts by choosing the workflow with the deepest (most specific) user_path. If user paths tie, the most specific model wins, followed by the most specificprovider_name. This lets you define broad defaults at the organisation level and override specific behaviour per team or user.
Auto-Created Default-Global Workflow
On first boot, Aurora creates a default-global workflow with all scope fields set to *. This ensures every request has a baseline policy even before you define custom workflows. You can edit or delete this workflow, but a replacement catch-all is recommended to avoid ungoverned requests.
Guardrail Attachments
Workflows reference guardrails by ID. Multiple guardrails can be attached to a single workflow and they execute in the order defined by the workflow's guardrail pipeline configuration. This allows different teams or models to have entirely different safety and transformation policies while sharing the same guardrail definitions.
Provider-Name Scoping
By setting provider_name to a specific value (e.g.anthropic), you can create provider-specific workflows that only apply when routing to that provider. This is useful when different providers require different caching or guardrail policies. Combine with user_path for fine-grained per-provider, per-team policies.