Build blueprint
Support Action Gate
A decision layer approving refunds, credits, escalations, and account changes within explicit limits.
- Problem
- Support automation either stops at drafting text or grants an agent dangerously broad authority.
- Why Jev
- The useful output is an action class and confidence, with deterministic dollar and permission caps.
- Architecture
- Ticket state → action Choice + fraud/urgency Scores → policy engine → execute or human queue.
- Current alternative
- Manual macros or an LLM agent with extensive prompt constraints.
- Jev advantage
- Separates judgment from execution and allows frequent re-evaluation as state changes.
- Unknowns
- Domain-specific calibration and access to representative support data.
Why this confidence: Explicitly aligned with workflow decisions, but production action requires conservative policy.
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
- Domain-specific calibration and access to representative support data.
- This is a research hypothesis, not evidence of product demand or Jev performance in this workflow.
Supporting research
- Confidence gate PlausibleAutomation proceeds above a threshold; ambiguous cases go to another check or a person.
- Axon Work integration ObservedThe author states that Axon Work uses Jev-style model decisions with a skill/action harness.
- Routing, classification, verification, and workflow control are the dominant early mental models. PlausibleThose categories recur in the collected launch discussion and align with the documented output primitives.
- Probabilistic predicate + deterministic action PlausibleJev supplies fuzzy predicates while TypeScript, policies, and workflows execute constrained actions.