← Back to blog

Inside Ask Viq: Jev, 758 Questions and Better Decisions

Translucent blue and purple geometric forms illustrating information moving through a neural network.

Illustration by Rose Pilkington / Google DeepMind, via Unsplash

"What are the prices?" "Does this work with BigCommerce?" "Take me to the right workflow."

These questions sound straightforward. A useful website assistant has to determine what each visitor wants, find the right source and choose an appropriate next step. Sometimes that means answering. Sometimes it means opening a page, asking a clarifying question or explaining that private store information requires a signed-in workspace.

Ask Viq is already live on the Vortex IQ website, using Jev as its first model-based classification layer and Gemini to write explanations from relevant public evidence. The aim is to make the journey from a visitor's question to a useful answer easier to understand and evaluate.

This article explains the design and the lessons behind it. For the wider platform opportunity across our Nerve Centre, Automation builder and knowledge graph, read Why Jev Matters for Ecommerce: From Insight to Action.

Begin with the visitor's intended outcome

Questions about the same subject can require different behaviour:

  • "What does a store health check do?" Explain the published capability.
  • "Show me the health-check page." Navigate to a validated destination.
  • "Show my store's health-check results." Direct the visitor towards authenticated access.
  • "Run it on my store." Require the correct account, store, permissions and supported execution path.

Those distinctions shape the classification contract. A good answer depends on both the topic and the visitor's intended outcome.

The public website assistant handles public information and navigation. It does not access private merchant records or execute authenticated merchant MCP operations. Those capabilities belong to a separately verified workspace journey.

What Jev decides, and what Gemini writes

Jev's Choice primitive evaluates a supplied situation against options defined by the application. It returns a selected option, a probability distribution and confidence. We use that interface to express routing questions the application can validate. Read TypeSafe's Choice documentation.

Our adapter asks seven questions against the same visitor context:

  1. Which eligible public destination fits the request?
  2. Which response mode is appropriate, such as answer, navigate or clarify?
  3. Has the visitor explicitly requested a platform filter?
  4. Has the visitor specified a merchant role?
  5. Which business outcome, if any, should filter the workflows?
  6. Has the visitor specified a type of work?
  7. Does the request identify one connector from the supplied options?

The application supplies a relevant shortlist, recent conversation context and descriptions of the allowed outcomes. Jev selects within that contract. The server validates its output before resolving an approved URL, section or filter.

An unresolved low-confidence decision, or a Jev provider failure, can receive one Gemini classification check using the same eligible options. This gives clear Jev decisions a short path while preserving a second opinion for harder requests. Logs distinguish Jev-only routing from the Jev-plus-Gemini path, including the reason for escalation.

When an explanation is helpful, Gemini receives relevant public source content and prepares a readable answer. The application supplies the source link and navigation button. Pricing uses canonical plan data so amounts, billing periods and currency do not depend on generated prose.

Some requests need no model call. An explicit click on a known suggestion, a simple introduction or a standalone cancellation can follow a direct code path. Keeping those cases direct avoids unnecessary work and makes their behaviour predictable.

How 758 synthetic examples shaped the design

We built two complementary question catalogues:

  • 464 examples across 116 families explore public questions, merchant onboarding and proposed authenticated workspace/tool decisions.
  • 294 examples across 86 families focus on website destinations, response modes, filters and conversational references.

Together they contain 758 synthetic examples, with no normalised duplicates in the recorded catalogue check. We grouped paraphrases into families so a small wording change would not be treated as a wholly independent scenario.

These examples help specify expected behaviour and drive evaluation. They are not 758 questions asked internally on every chat turn, and they were not used to fine-tune Jev. The live decision request contains the visitor's relevant context, eligible choices and the seven routing questions above.

We also keep the scope of each catalogue clear. A proposed onboarding or merchant-tool question does not establish that the public website can execute that operation. The expected result may be a request to sign in, clarification of the store, or an explanation that the capability is unavailable.

The website had to become easier to navigate reliably

The assistant needs destinations that software can identify consistently. We added stable section identifiers, canonical destination records, URL-driven filters and shared schemas for the website's public tools.

The foundation release verified 153 destinations and 19 shared-schema public tools. That gives navigation an explicit contract: a pricing section, a connector directory filter or a particular workflow can be addressed and validated.

WebMCP and the website bridge share those public tool definitions. Jev's classification remains a separate layer: selecting an intent does not execute an MCP tool or grant access. The application decides which public operation is permitted and how its arguments are checked.

This foundation also makes the experience easier to inspect. We can compare the requested destination with the actual URL and section, and check whether filters survive navigation and browser history.

What ordinary questions revealed

Two short questions exposed a gap in the early experience: "who are u" and "what is the time now". The assistant suggested unrelated pages because retrieval found words that resembled the request.

A relevant-looking search result was being treated as sufficient reason to recommend a page. We added explicit conversational outcomes and stopped restoring retrieved suggestions after a classification had rejected them.

Ask Viq now introduces itself for a straightforward identity question. An off-topic clock question receives an appropriate scope response. A mixed request such as a greeting followed by a pricing question can still reach pricing.

This lesson applies to structured decision models too: an output can match its schema and still be the wrong decision. The application needs relevant choices, an insufficient-evidence outcome and tests that inspect what the visitor actually receives.

What live Jev testing taught us

Our first full Jev run flagged 72 of 402 synthetic cases. The most useful lesson was about the decision contract: asking what a visitor wants must be separate from deciding what the website can do. "Inspect my results" is a private-data request even when this public chat cannot fulfil it.

We also found that a root-page alias and a canonical section could compete for the same intent, splitting the probability between equivalent choices. Removing redundant alternatives made the contract clearer. We retained specific FAQ and comparison sections because they represent different destinations.

Confidence did not remove the need for application judgement. We kept the threshold, added the bounded second-opinion path and clarified how commands to show filtered catalogues should navigate. A disagreement between reading private results and starting a private workflow can safely lead to an authenticated-workspace boundary; it never grants permission or executes a tool.

Follow-up context matters as much as the first answer

Testing also exposed a pricing journey where a visitor asked for monthly GBP prices and then asked, "And annually?" The follow-up could lose the selected currency.

We added explicit handling for currency, billing period and conversational references. A new instruction can override earlier context, while a short follow-up retains the information needed to answer correctly.

We also changed explicit page-opening requests to go directly to the validated destination after selection. They no longer depend on retrieving page text and generating an explanation before navigation can succeed.

A completion question such as "Have you connected it?" exposed another distinction. This website chat cannot connect stores, so the application can state that fact directly. We added a narrow, deterministic reply for those status questions, without asking a model to guess whether an action happened.

Other failures exposed content problems. Product pages needed dependable source content, and some timing questions could not be answered from the published information. In those cases, an honest limitation is more useful than an invented duration. Evaluation can reveal a website content gap as well as a model or routing problem.

What our tests actually established

The earlier full-response evaluation used Gemini classification, real public evidence retrieval and answer generation where required. It saved 402 responses, with 33 cases flagged by automated checks.

After changes to routing, context and source handling, a second 402-case run had five flagged cases. A final targeted run checked eight responses covering the remaining issues and a four-turn journey. The combined review record retains two editorial flags for timing questions where the source does not confirm the requested duration.

These are automated checks, with saved questions and answers available for manual assessment. They are not a claim that every answer is factually correct or that 758 live conversations passed. The evaluation also predates Jev activation, so those results cannot be attributed to Jev.

On 19 September 2026, our final Jev-first evaluation saved 402 complete server responses. 397 met the automated checks and 5 retained flags for manual review. Of those requests, 314 completed classification through Jev alone, 60 used the Gemini classification fallback and 28 followed direct application logic.

Across 374 Jev attempts, classifier latency was 256 ms at the median and 524 ms at the 95th percentile, with one recorded provider/contract error. Complete server responses had a median of 302 ms and a 95th percentile of 3,902 ms. These are different measurements: an explanation may require source retrieval and Gemini generation after Jev decides the route. Direct replies are excluded from Jev timing; failed attempts remain included.

This was a repeated synthetic regression evaluation from a local server environment, not browser latency, an untouched held-out benchmark or a controlled speed comparison. All saved responses remain available for human review. The figures establish the observed behaviour of this release; they do not prove that all answers are correct or that every merchant journey is faster.

We then fixed the completion-status follow-up and reran its four-turn journey successfully. The combined latest-observation record has 398 automatic passes and four flags: onboarding duration, backup restoration duration and two workflow-detail answers. Those flags stay visible for content and answer-quality review. This combined record is not an additional full evaluation run.

Review is part of operating the assistant

The website uses request limits and browser verification to bound model usage. Server credentials stay outside the browser bundle. The chat notice explains that accepted exchanges may be stored for quality review.

Review records are held in private storage with redacted text, model and deployment information, and a 30-day retention policy. Staff can inspect questions, answers, sources and routing outcomes together. That supports finding patterns and turning them into better content or regression cases; it does not automatically train a model.

The operating question is practical: did the visitor get a relevant, supported answer and a useful next step?

From a public question to a merchant journey

Jev is in use on the public website. We verified the deployed chat through the browser and confirmed Jev routing in the corresponding server review records. We pinned the release to jev-1.13.0 so a changing model alias cannot silently alter the tested behaviour.

The next platform step is authenticated onboarding: understanding a merchant's goal, showing the right connection step and making supported workflows easier to discover. Connection state, account access and tool permissions will remain server-verified facts.

Ask Viq gives us a focused place to develop and measure that approach. The same discipline can support broader decisions across thousands of KPIs and available operations: relevant evidence, clear choices, validated actions and a record of the outcome.

Try Ask Viq on the Vortex IQ website, or explore how Jev could support decisions across the whole platform.

Frequently asked questions

What is Ask Viq, and which AI models does it use?

Ask Viq is Vortex IQ's public website assistant for product information and navigation. In the release described here, Jev 1.13.0 performs the first model-based classification. Gemini writes explanations from relevant public sources and can provide one classification fallback for unresolved Jev decisions or provider failure. Simple conversation and known application facts can be answered directly in code.

What does Jev classify on each Ask Viq request?

The adapter asks seven routing questions about the same visitor context: destination, response mode, platform, merchant role, business outcome, work type and connector. The server supplies relevant eligible options, validates the result and resolves an approved destination or response. These routing choices do not grant access to a merchant account or authorise an action.

Does Ask Viq run 758 questions for every visitor message?

No. The 758 synthetic examples are a design and evaluation corpus: 464 public, onboarding and proposed workspace examples, plus 294 navigation examples. They are not sent with every chat message and were not used to fine-tune Jev. A live classification request uses relevant conversation context, eligible choices and the seven routing questions.

How does Ask Viq answer pricing and navigation questions?

Pricing answers use canonical plan data, including currency and billing period. Navigation resolves validated page destinations, section identifiers and supported filters. The application retains relevant context for follow-ups such as a change from monthly to annual billing. Generated prose does not determine the price or invent a destination URL.

What happened when visitors asked who are u or what is the time now?

The early assistant returned unrelated page suggestions because it treated loosely matching retrieval results as useful destinations. We added explicit conversational outcomes and stopped restoring suggestions after classification rejected them. Straightforward identity questions now receive an introduction, and off-topic clock questions receive a scope response. A greeting combined with a pricing request can still reach pricing.

What did the Jev-first evaluation establish?

On 19 September 2026, a full synthetic run saved 402 complete server responses: 397 passed automated checks and five were flagged. After one fix and a four-turn retest, the combined latest-observation record contains 398 passes and four flags. That combined record is not another full run. Human review remains pending, and automatic passes do not establish factual accuracy.

How fast was Jev routing in the Ask Viq evaluation?

Across 374 Jev attempts, classifier latency was 256 ms at the median and 524 ms at the 95th percentile, including one recorded provider or contract error. Complete server responses measured 302 ms and 3,902 ms respectively. These are local synthetic evaluation results, not browser latency or a controlled speed comparison; explanations can also require retrieval and Gemini generation.

Can public Ask Viq connect a store, read private results or execute merchant MCP tools?

No. The website assistant provides public information and navigation. Private results, store connections and authenticated merchant MCP operations require the separate workspace journey with verified account, store and permission checks. If asked whether it has connected a store, public Ask Viq states that it has not performed that action.

What happens when Jev is uncertain or the website lacks an answer?

An unresolved low-confidence Jev decision or provider failure can receive one Gemini classification check against the same eligible options. The assistant can ask for clarification or explain the limitation when evidence is missing. It should not invent a capability or duration. Four source-detail cases remain flagged in the recorded review, making those gaps visible for follow-up.

How are Ask Viq conversations reviewed and protected from misuse?

The website uses request limits and browser verification to bound usage, and model credentials stay on the server. Accepted exchanges may be stored as redacted text in private quality-review records with routing, model and deployment information under a 30-day retention policy. Reviewing these records helps identify content gaps and regression cases; it does not automatically train a model.

Connect directly to the commerce platforms you run