The same router, tuned by editing two text files.

1. Request arrives
2. Code and complexity detected
3. Prose is kept off the coding agent
4. Coding agent answers the real code
5. Cost and alternatives on the trace

rules:
  - name: real-code-to-the-coding-agent
    when:
      domains: [coding]
      min_complexity: 0.45
    prefer: [coding-agent]
    weight: 0.7

  - name: prose-never-pays-coding-prices
    when:
      domains: [general_chat, marketing, hr]
    avoid: [coding-agent]
    weight: 0.6

Example: Illustrative configuration or synthetic data, not a customer's.A reference configuration to start from - the rules the router enforces, not a description of how a named customer runs it.

Complexity is a signal, so a one-line regex question never wakes the coding agent.

1. Account data detected
2. Cloud models removed from the candidates
3. On-prem model answers
4. Decision hash-chained in the audit trail

rules:
  - name: account-data-stays-onprem
    when:
      domains: [finance]
      contains_pii: true
    prefer: [llm-onprem]
    pin: true

  - name: statements-are-extraction
    when:
      domains: [finance]
      actions: [extract]
    prefer: [llm-mid]
    weight: 0.6

Example: Illustrative configuration or synthetic data, not a customer's.A reference configuration to start from - the rules the router enforces, not a description of how a named customer runs it.

pin restricts the candidates instead of nudging them; the hash-chained audit records why.

1. PHI detected on the way in
2. External models removed
3. On-prem model selected
4. Complex clinical questions to a clinician
5. Decision logged

rules:
  - name: phi-stays-onprem
    when:
      contains_pii: true
    prefer: [llm-onprem]
    avoid: [llm-frontier, llm-mid]
    weight: 1.0

  - name: clinical-review
    when:
      domains: [medical]
      min_complexity: 0.6
    prefer: [clinician-review]
    pin: true

Example: Illustrative configuration or synthetic data, not a customer's.A reference configuration to start from - the rules the router enforces, not a description of how a named customer runs it.

Policies run before scoring, so no objective weight can trade the boundary away.

1. Contract arrives
2. Length and complexity measured
3. Large-context model answers
4. Confidence below the floor: counsel reviews
5. Decision logged

rules:
  - name: contracts-need-context
    when:
      domains: [legal]
      min_complexity: 0.5
    prefer: [llm-frontier]
    weight: 0.8

  - name: anything-doubtful-to-counsel
    when:
      domains: [legal]
      actions: [escalate]
    prefer: [counsel-review]
    pin: true

# router settings:
#   min_confidence: 0.55
#   fallback_target: counsel-review

Example: Illustrative configuration or synthetic data, not a customer's.A reference configuration to start from - the rules the router enforces, not a description of how a named customer runs it.

The floor is one router setting: below min_confidence the request goes to fallback_target instead.

1. Copy request arrives
2. Brand-critical flag read from the context
3. Bulk copy to the cheap models within budget
4. Brand work to the frontier model
5. Spend per tenant on the ledger

rules:
  - name: bulk-copy-on-cheap-models
    when:
      domains: [marketing]
      actions: [generation]
      max_complexity: 0.5
    prefer: [llm-small, llm-mid]
    weight: 0.8

  - name: brand-critical-gets-the-best
    when:
      domains: [marketing]
      context: { brand_critical: true }
    prefer: [llm-frontier]
    pin: true

Example: Illustrative configuration or synthetic data, not a customer's.A reference configuration to start from - the rules the router enforces, not a description of how a named customer runs it.

Budgets are declared per target in the catalogue; context keys let the caller flag what matters.