Provider Routing in Editorial/AI Workflows

1) The problem: a router is not a cheapest-model switch

Summarization, source-faithfulness verification, and image interpretation do not have identical requirements. A cheapest-available cascade can send sensitive context to the wrong provider, select a model without the required modality, keep a retired model in the table, or invoke an unevaluated fallback. This lesson builds Editorial Provider Routing Matrix v1 from replayable evidence rather than convenience.

2) COM-007 scope: routing, not the whole editorial cell

COM-007 owns provider/model routing for bounded editorial stages. COM-006 owns the multi-model editorial cell and COM-008 owns the claim/source registry. This lesson does not mutate live traffic, billing, credentials, or production infrastructure, and vendor documentation does not grant MAKNOW architecture authority.

3) Mental model: Task Contract → Eligibility → Eval Floor → Budgets → Route → Approval

Record the task and policy requirements first. Remove ineligible provider/model candidates. After capability and lifecycle pass, apply the task-specific quality floor. Check latency and cost budgets only after hard gates. If the primary route fails, a fallback needs its own evidence and never inherits approval automatically.

4) FACT: vendors expose multiple model variants

Current OpenAI and Gemini documentation list multiple model variants with different specifications and trade-offs. The bounded conclusion is that provider and model_id are explicit routing inputs. A vendor catalog is not a universal cross-provider ranking and does not prove quality on your task.

5) FACT: lifecycle is operational evidence

Anthropic documents lifecycle states such as Active, Legacy, Deprecated, and Retired, and states that requests to retired models fail. A route that worked yesterday can therefore become invalid because lifecycle changed. Exact lifecycle behavior must be checked per provider.

6) The 22-field routing contract

Each row records rule/stage/task identity, required modality/context/tooling, data policy, provider/model, lifecycle, capability match, eval suite, quality floor, latency/cost budgets, primary/fallback routes, fallback trigger, degraded state, approval requirement, route decision, and evidence reference.

7) Apply hard gates before optimization

If data policy is incompatible or required capability is missing, the route is blocked immediately. Lower cost or latency cannot compensate for a hard constraint. Build the eligible set first; optimize only within that set.

8) Capability match must be task-specific

A generic “multimodal” or “reasoning” label is not enough. State the modality, context, and tooling required by the editorial stage, then compare those requirements with visible capability evidence. A successful API call proves transport compatibility, not task suitability.

9) Version the lifecycle gate

Record model_lifecycle_state with the observed evidence. A retired or unavailable primary route cannot silently continue through a new alias. If lifecycle is unknown, use HOLD_LIFECYCLE_UNKNOWN until current evidence exists.

10) Enforce a task-specific quality floor

A candidate can meet latency and cost budgets and still fail source-faithfulness. Do not lower the quality floor just to preserve throughput. Missing task-specific evaluation is HOLD_EVAL_MISSING, not success.

11) Treat latency and cost as budgets, not a magic score

After policy, capability, lifecycle, and evaluation gates pass, latency and cost budgets support the operational choice. Do not collapse quality, risk, cost, and latency into an undefined weighted number. Record the trade-off rationale and stop/pivot trigger.

12) A fallback is a new decision

Matching response schemas do not make a fallback equivalent to the primary model. The fallback must independently pass capability, policy, lifecycle, and evaluation gates. Using a valid fallback sets DEGRADED_FALLBACK_REVIEW and requires REVIEW_BEFORE_RELEASE; prior approval does not carry over.

13) Preserve typed non-success states

• capability mismatch → BLOCKED_CAPABILITY
• data-policy mismatch → BLOCKED_DATA_POLICY
• retired lifecycle with no validated fallback → BLOCKED_LIFECYCLE
• evaluation below quality floor → BLOCKED_QUALITY_FLOOR
• missing evaluation → HOLD_EVAL_MISSING
• unknown lifecycle → HOLD_LIFECYCLE_UNKNOWN
• missing decisive evidence → HOLD_EVIDENCE_MISSING

14) Negative example: replacement is fast and cheap but fails the eval

The tempting shortcut is to promote the nominal replacement to keep throughput green. Keep the quality floor unchanged. If another fallback has independently passed every gate, use it only as DEGRADED_FALLBACK_REVIEW; otherwise release remains HOLD/BLOCKED.

15) Lab and transfer: the baseline answer is never the oracle

The lab contains eight offline fixtures and 48 deterministic assertions. In transfer, the primary model is retired and the nominal replacement meets cost/latency budgets but fails source-faithfulness. Recompute from changed evidence: reject the nominal replacement, use only an independently evaluated fallback, and require renewed approval for any degraded route.