# Model fallback decision tree

Use this decision tree when a model, provider, retrieval index, or tool dependency becomes slow, expensive, unavailable, or unsafe. Fallback should be planned before incidents; improvised fallback often creates worse user experiences and weaker audit trails.

## Decision points

- Is the failure isolated to one provider, model, region, workflow, customer segment, or data source?
- Can the system retry safely, or would retry duplicate a side effect or increase user risk?
- Is a lower-capability model acceptable for this task, or does quality risk require escalation?
- Can cached content, deterministic workflow, or read-only mode satisfy the user temporarily?
- Should the service enter degraded mode, pause autonomous action, or shut down the affected workflow?

## Required evidence

Record trigger metric, routing choice, user impact, owner, start time, end time, and post-incident action. Fallback without evidence is not operational control.