Decision Rules

 Client Request (model="auto")
             │
             ▼
   Decision Rules Engine
 ┌───────────────────────────┐
 │ Match: Business Hours?    ├─────► Route to "high-throughput-cluster"
 └─────────────┬─────────────┘
               │ (Outside schedule / no match)
 ┌─────────────▼─────────────┐
 │ Policy: Deny Models       ├─────► Exclude "expensive-models"
 └─────────────┬─────────────┘
               │ (Next rule in pipeline)
 ┌─────────────▼─────────────┐
 │ Match: VIP Enterprise     ├─────► Route to "dedicated-cluster"
 └─────────────┬─────────────┘
               │ (No route rule matched)
 ┌─────────────▼─────────────┐
 │ Fallback Action           ├─────► Route to Default Deployment
 └───────────────────────────┘

Decision Rules allow Infralo workspaces to dynamically evaluate incoming API requests and route them to the optimal deployment or model without requiring client applications to hardcode model names.

Instead of targeting a specific model or deployment name, your application sets model="auto" in the OpenAI-compatible gateway request. Infralo inspects the request context—including request body payloads, HTTP headers, day of week, and time of day—and evaluates your configured decision rules in priority order.

Setting Up model="auto"

To enable Decision Rules, send requests to the Infralo gateway with model="auto":

from openai import OpenAI

client = OpenAI(
    base_url="https://api.infralo.com/v1",
    api_key="inf_live_...",
)

response = client.chat.completions.create(
    model="auto",  # Enables Decision Rules Evaluation
    messages=[{"role": "user", "content": "Analyze this transaction for fraud."}],
    user="user_enterprise_99",
    extra_headers={
        "x-infralo-team": "finance-ai",
        "x-infralo-meta-tier": "premium",
        "x-infralo-meta-country": "US",
    },
)

Evaluation Context & Condition Types

Infralo evaluates rules against two categories of condition clauses:

1. Header Context Conditions (Built-in fields and custom x-infralo-meta-* headers)
2. Schedule Conditions (Day-of-week, time-of-day windows, timezones, and 24-hour nonstop schedules)

1. Built-In Fields (x-infralo-<field>)

Infralo supports 5 standard built-in context fields passed via x-infralo- HTTP headers:

2. Custom Metadata Fields (x-infralo-meta-<key>)

You can pass arbitrary custom metadata into your decision rules by sending HTTP request headers with the x-infralo-meta- prefix.

When Infralo processes the request, the x-infralo-meta- prefix is stripped to create the condition field name:

3. Schedule Conditions (type: "schedule")

Schedule conditions allow you to route traffic or apply policy filters based on the time and day of the incoming request in any IANA timezone.

{
  "type": "schedule",
  "days": "weekdays",
  "start_time": "09:00",
  "end_time": "18:00",
  "timezone": "Asia/Jakarta"
}

Supported Day Modes (days)

• any_day: Matches all 7 days of the week (Monday through Sunday).
• weekdays: Matches Monday through Friday.
• weekends: Matches Saturday and Sunday.
• specific_days: Matches an explicit list of days, e.g. ["monday", "wednesday", "friday"].

Time Windows & All Day (24 Hours)

• Time Windows (start_time & end_time): Formatted as 24-hour HH:MM strings (e.g., "09:00" to "17:00").
• All Day (24 Hours): When start_time and end_time are omitted or null, the rule evaluates to true for all 24 hours of matching days without restricting time boundaries.
• Cross-Midnight Windows: If start_time is later than end_time (e.g., "22:00" to "06:00"), Infralo automatically evaluates the window as crossing midnight (matching from 22:00 to 23:59:59 and 00:00 to 06:00).
• Timezone Awareness: Evaluated against the configured IANA timezone (e.g. "Asia/Tokyo", "America/New_York", "UTC"), correctly handling international day rollovers.

Condition Structure & Logical Combinators

Rule conditions can combine single field comparisons, schedules, or complex multi-clause trees using and / or logical combinators:

{
  "operator": "and",
  "conditions": [
    {
      "field": "tenant",
      "op": "eq",
      "value": "enterprise-corp"
    },
    {
      "field": "monthly_spend",
      "op": "gte",
      "value": 1000
    },
    {
      "type": "schedule",
      "days": "weekdays",
      "start_time": "09:00",
      "end_time": "20:00",
      "timezone": "Asia/Tokyo"
    }
  ]
}

Supported Comparison Operators

Pipeline Order & Rule Evaluation

Rules in your workspace are evaluated sequentially from top to bottom:

Rule 1: [Deny Models] Exclude experimental models
Rule 2: [Route Deployment] Route to Tokyo Cluster (Matches & routes request!)
Rule 3: [Route Deployment] (Skipped — route already decided by Rule 2)

1. Route Selection

The first matching Route to Deployment rule in the pipeline is selected. Once a route rule matches, subsequent route rules are skipped.

2. Deny Models Accumulation

All matching Deny Models rules evaluated before or alongside the winning route rule contribute to the denied candidate model pool for that request.

Clean Fallback Execution (Catch-All)

If a request specifies model="auto" and no route_deployment rule matches across the entire pipeline:

1. Clean Workspace Fallback: The gateway discards any intermediate filter state and executes a pure fallback directly to your workspace's configured default action.
2. Default Action Configured: The request is routed to your workspace default deployment without denied model filters from unmatched rules.
3. No Default Action Configured: If no fallback action is set, the gateway cleanly rejects the request with an HTTP 422 Unprocessable Entity error:

   {
     "error": {
       "message": "No decision rule matched this request and no default action is configured.",
       "type": "invalid_request_error"
     }
   }

Observability & Telemetry

Every request evaluated via model="auto" records full decision rules telemetry in ClickHouse traces:

• Trace Metadata: Inspect which rules matched, which route was selected, and any denied models in the Log Detail and Full Trace timeline viewers.
• Schedule Badges: Formats schedule conditions clearly (e.g., 🕒 Schedule: Weekdays 09:00 - 18:00 (Asia/Jakarta) or 🕒 Schedule: Weekends (All Day)).
• Clean Fallback Indicator: When routed via workspace default fallback, the trace clearly displays Routed via workspace default fallback action without phantom rule cards.