fallback-requiredlisted

# Fallback Required ## The Law ``` LLM CALLS WITHOUT FALLBACKS ARE TICKING FAILURES. Every model times out. Every model returns garbage sometimes. "The model is reliable" is a claim about averages — users experience tails. A defined, tested fallback path for each failure mode IS reliability. ``` ## When to Use Trigger on every PR that: - Adds a new LLM API call - Changes existing error handling on a model call - Adds streaming or async generation - Introduces tool use or agentic function calls ## When NOT to Use - Offline batch jobs where failures can be retried with human review and no user is waiting - Exploratory prototypes not going to production ## The Four Failure Modes Every LLM call must handle all four: | Failure Mode | What Happens | Required Response | |---|---|---| | Timeout / API error | Network down, provider outage, slow response | Retry with exponential backoff (max 3), then graceful degradation | | Malformed output | Wrong format, truncated JSON, schema violation | Schema validation → fallback to rule-based default | | Low confidence | Model expresses uncertainty, output score below threshold | Route to fallback model, simpler rule, or human review | | Refusal | Model declines to answer, content filter triggered | Detect refusal pattern → user-friendly error, do not surface raw refusal | ## The Process ### Step 1 — Define the Fallback Before Writing the Call Before writing the LLM call, answer: *what does this feature return when the model fails?*