Build blueprint
Autonomous QA Scenario Selector
A test controller choosing the next action and deciding when a distinct failure has been found.
- Problem
- UI test suites run too many redundant paths while missing state-dependent risky scenarios.
- Why Jev
- Exploration requires hundreds of small action and novelty decisions per session.
- Architecture
- DOM/screenshot-derived state → next-action Choice + novelty/failure Scores → Playwright.
- Current alternative
- Scripted tests, random fuzzing, or full multimodal agents.
- Jev advantage
- Decision calls can sit inside a dense exploration loop.
- Unknowns
- Rich UI state representation and avoiding exploration loops.
Why this confidence: High-frequency decisions are central, but state encoding is challenging.
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
- Rich UI state representation and avoiding exploration loops.
- 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.
- jev-ultrafast ObservedA browser-automation runtime from Browser Use with a published performance report (docs/performance.md). The report documents a 7.07 s Google Flights run made with 17 Jev requests; that timing excludes browser setup and post-run verification, and the run finds flight results rather than booking anything.
- 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.
- Parallel decision matrix PlausibleOne state is evaluated against many named questions, replacing repeated prompt/parse cycles.