Model resilience and safe recovery
Route qualified model work through explicit fallback, circuit recovery, non-publishing shadow evaluation, and immutable checkpoints.
Hyperoru keeps model availability separate from evidence authority. A fallback route can keep a bounded analysis activity available, but it cannot expand what the activity may read, move data to an unapproved region, exceed its budget, or publish an unqualified result.
Policy-ordered routes
Owners and Admins configure an ordered route set for each activity. Before execution, Hyperoru checks every route against:
- operator qualification and active endpoint state;
- workspace data residency policy;
- the activity's required model and tool capabilities;
- circuit health and recovery-probe state;
- the remaining reasoning and cost budget.
The worker uses the first eligible route. It advances to the next route only after a retryable provider or transport failure. Cancellation, invalid structured output, policy denial, and budget exhaustion stop the activity instead of sending the same evidence somewhere else.
Retry, fallback, and recovery are different
| Behavior | Meaning | Provider changes? |
|---|---|---|
| Retry | Repeat a transient request against the same approved endpoint | No |
| Fallback | Continue through the next eligible route in workspace policy | Yes |
| Recovery probe | Test whether an open circuit may safely receive work again | No |
Every decision records a sanitized route identity, disposition, phase, prompt version, latency, token usage, cost, and bounded reason. Prompts, evidence bodies, credentials, and raw provider errors are not returned by the customer API.
Shadow evaluation cannot become truth
Shadow evaluation compares a separately qualified model on explicitly eligible workloads. Hyperoru stores support agreement, omissions, contradictions, latency, and cost in a dedicated shadow ledger. Shadow invocations are marked before execution and cannot publish architecture truth, findings, reports, decisions, or remediations.
An operator may qualify or reject a shadow configuration after review. Qualification makes the route eligible for later production policy; it never promotes an old shadow answer into customer truth.
Compatible checkpoints
Expensive analysis can checkpoint at a measured activity boundary. A checkpoint includes the input and output checksums, contract version, route and model identity, prompt version, policy version, and publication status. Hyperoru resumes only when all compatibility inputs still match.
If a result was already committed, recovery returns that committed result rather than publishing it again. If policy, prompt, contract, model, or evidence changed, the activity restarts. Temporal remains the only system that schedules or retries workflow work.
What customers can inspect
The workspace Settings → Resilience view shows route health, redacted routing decisions, fallback state, circuit status, checkpoint recovery, and shadow-review state. Provider-internal errors and sensitive inputs remain hidden. Operators use a separate authenticated console for recovery probes, circuit actions, shadow decisions, and checkpoint invalidation; every action requires a reason and is audited.