Provider failover
What you'll find here
The explicit routing policy that controls when Craik falls back from one provider to another — rules, stop conditions, denied paths, and the receipt shape.
No implicit fallback.
Craik only falls back when a ProviderFailoverPolicy
contains a matching rule. Failover decisions preserve the active
policy envelope id so routing changes tie back to the same governance
boundary.
Rules
ProviderFailoverRule defines:
Failed provider id
Fallback provider id
Audit reason
Receipt required?
If no rule matches the failed provider, failover is denied.
Stop conditions
Checked before fallback rules.
Policies can name failure reasons that stop failover entirely. This keeps routing from crossing policy, trust, or capability boundaries after a failure reason that requires operator review.
Stopped decisions do not name a fallback provider.
Denied fallback paths
Policies can deny specific fallback provider ids — even when a rule points to that provider. This lets an operator disable a provider for budget, trust, capability, incident, or compliance reasons without removing every rule that references it.
Receipts
ProviderFailoverDecision records whether failover was allowed,
denied, or stopped. Decisions include:
Failed provider id
Fallback provider id
When one was evaluated.
Policy envelope id
Decision reason
Receipt requirement
Metadata only.
Provider failover does not contact providers, load secrets, or grant execution authority by itself. It supplies routing metadata for the caller to enforce alongside provider switching, budgets, quotas, and policy envelopes.