Build blueprint
Smart Retry Policy
A library choosing retry, backoff class, fallback, or dead-letter from structured failure context.
- Problem
- Distributed systems retry uniformly even when errors indicate permanent failure or overload.
- Why Jev
- Each failure needs a bounded control decision, often many times per request chain.
- Architecture
- Error + operation metadata → control Choice and recoverability Score → capped policy executor.
- Current alternative
- Status-code tables and exponential backoff everywhere.
- Jev advantage
- Semantic retry behavior can adapt while hard caps guarantee safety.
- Unknowns
- Novel failure generalization and added latency on already-failing paths.
Why this confidence: Strong primitive fit but system-level failure behavior needs rigorous testing.
This is an authored hypothesis derived from the research corpus. Nothing here demonstrates product demand, or that Jev performs well on this particular workload. Run the validation experiment before building past the MVP.
Sources
Limitations
- Novel failure generalization and added latency on already-failing paths.
- This is a research hypothesis, not evidence of product demand or Jev performance in this workflow.
Supporting research
- Probabilistic predicate + deterministic action PlausibleJev supplies fuzzy predicates while TypeScript, policies, and workflows execute constrained actions.
- HA-Jev ObservedA Home Assistant custom integration exposing Jev evaluations as sensors and automation actions.
- Cheap decision calls could make tens or hundreds of semantic judgments per event economical. SpeculativeThe product design follows from published pricing and parallel question primitives, not independent production evidence.
- Cascade router PlausibleA cheap decision chooses whether to use rules, a small model, a premium model, a specialist, or a human.