Jev versus traditional routing
Traditional routing is deterministic: keyword lists, ticket forms, round-robin queues, Drools-style rules. Jev routing is a typed Choice (and optional Score) on messy text, then the same queues and rules fire on structured answers.
Unofficial comparison. Official pattern: intent routing. Live how-to: /usecases/intent-routing. Not affiliated; no keys.
Criteria
| Criterion | Rules / queues | Jev + code |
|---|---|---|
| Unstructured email | Brittle keywords | Choice over intents you listed |
| Known order-id regex | Wins — keep in code | Do not ask Jev to parse ids |
| Confidence / abstain | Implicit (no match) | Explicit confidence / Noul band |
| Changing taxonomy | Ticket-form release | Edit criteria (pin model if floors exist) |
| Cost | Your CPU | Vendor input-token price |
TypeSafe “how to build”: keep control flow and deterministic work in code. Jev appears where you need common sense over language.
When traditional routing still wins
- The user already picked a queue in a form
- Routing is a pure SKU or HTTP path
- You cannot send ticket text off-box
When to put Jev in front
- Free-text that should skip the expensive LLM (order status → SQL)
- Complaints that need a complexity Score before a human
- Model routing (cheap vs careful LLM) — model routing
Do not replace the queue manager. Replace the guess that used to live in a 400-line if "refund" in text.
FAQ
Is this a message bus? No. Jev does not enqueue. Your worker does.
Can I keep regex and Jev? Yes — regex first, Jev on the remainder.
Hub: Comparisons. Sibling: intent routing. Official: docs.typesafe.ai.
Sources
Public TypeSafe or adjacent documentation only. No private claims.