Reliability
Failure-aware routing with a unified readiness model and reliability-weighted scoring.
Reliability strategies keep traffic away from failing recipients. They read a rich set of reliability facts — circuit state, error rate, latency p95, retry-after backoff, error-budget burn, saturation, brownout, staleness — and use them to penalize or exclude targets that are degrading, so failures drain instead of cascade.
Two layers are involved: the reliability readiness plane projects operational
health, and the reliability_weighted built-in strategy consumes those facts.
The strategy reads only the reliability.* feature keys on
SelectRequest.Features.
| Strategy | Output | Status |
|---|---|---|
| Reliability readiness | policy | Available |
| Reliability-weighted | single-winner | Built in |
Reliability facts
The readiness signal is computed from circuit state, error-rate EWMA, consecutive failures, latency p95, timeout rate, retry-after-until, retry-budget remaining, error-budget burn, saturation ratio, brownout flag, and freshness — all available as typed feature keys, so any scorer can consult them.
Reliability readiness
Output: policy
The readiness projection: a routing-safe signal plane that composes circuit breakers, webhooks, adaptive flow control, credential health, availability, quota, usage budgets, and entitlement policy into one queryable set of states — ready, degraded, brownout, blocked, probing, unknown, stale — scoped by tenant, environment, and target.
Why it matters. Every subsystem has its own health signal; without a common model each strategy would re-derive "is this target OK?" differently. Readiness collapses those signals into one answer, with provenance, so a blocked route can explain why — circuit-open recipient, stale availability, quota backoff, budget pressure, entitlement denial, or brownout.
Distinguish the two layers. The readiness projection is the deeper plane: it
ingests observations, upserts current facts, and exposes API/MCP operations
(reliability_readiness_get, reliability_decision_explain, and more). A routing
strategy never touches that plane directly — it reads the bounded reliability.*
numeric keys the projection lands in the feature snapshot.
Stale facts can't project as ready; unknown facts fail closed unless policy
allows fail-open.
Where it fits. The input other strategies read — chiefly reliability-weighted below.
Reliability-weighted
Output: single-winner · Built in
A recipe: take any base score and apply readiness penalties — blocked targets are excluded, degraded and brownout targets are penalized — so traffic drains away from failing recipients before they cascade.
Why use it. It layers failure-awareness onto whatever selection you already use. Your base strategy proposes a distribution; reliability-weighting removes the targets that shouldn't get traffic and dampens the ones that are struggling, without you hand-coding circuit logic into each strategy.
How it works. It wraps a base strategy (default
smooth_weighted_round_robin) and adjusts scores using the readiness facts:
blocked → out, degraded/brownout → penalized. It consumes the
readiness projection through the reliability.* feature
keys. It records the reliability keys it considered in the explain feature trace.
Where it fits. The Select stage, as a reliability-aware wrapper over a base
distribution strategy.
Related
Eligibility
Recipient eligibility traits — a governed qualification contract evaluated before strategy selection, with hard/preferred/disallowed requirements, redaction, and fail-closed expiry.
Work
The work-assignment bridge — routing human and AI work into the shared strategy substrate, with work.* recipes, a case-management assignment registry, and human_loop workflow steps.