Why Jev Matters for Ecommerce: From Insight to Action

A merchant starts the day with falling conversion, rising advertising spend and a queue of operational alerts. Each dashboard explains part of the picture. The difficult decision is where to focus, what to investigate and which action deserves approval.

At Vortex IQ, that challenge shapes how we think about AI. Our Nerve Centre catalogue spans 7,000+ KPIs, and our Automation builder catalogue contains 14,000+ operation nodes. The opportunity is to connect those signals and capabilities so a merchant can move from "something changed" to a well-supported next step.

Jev gives us a new way to approach the decisions along that journey. We already use it in Ask Viq on our public website to classify requests and support navigation decisions. Here is why it matters, how it fits with a knowledge graph, and where we see practical value across ecommerce.

What is Jev?

TypeSafe AI introduced Jev on 15 September 2026 as its first System One model, available in early access. It is designed to return structured decisions that software can use directly. Read TypeSafe's introduction to Jev.

Think of a decision such as choosing which investigation to open when a merchant reports falling sales. The application supplies the evidence and the allowed outcomes. Jev evaluates that situation within the defined choices.

Its API provides three building blocks:

• Choice: select from options defined by the application.
• Score: assess something against a defined rubric.
• Noul: estimate how likely a statement is to be true, given the supplied context.

Independent questions can share a request and the same context. A question that needs the result of an earlier investigation belongs in a later step. See the System One API overview.

For ecommerce teams, this creates an interesting division of work: use a specialised model for bounded judgements, a language model to explain findings or draft content, and application code to calculate values and enforce business rules.

Why 7,000+ KPIs and 14,000+ nodes change the problem

Our 23 August 2026 catalogue snapshot contains 7,384 KPI definitions and 14,135 workflow-operation records. Those are platform catalogue totals. A merchant's available metrics and actions depend on connected services, data, permissions and supported operations.

That scale makes selection central to the experience. A growth manager looking at paid traffic needs a different view from an operations lead investigating failed orders. A suitable action also depends on which store is affected, which connector is available and what the user can authorise.

We see three connected decisions:

1. Attention: which signals matter for this merchant and goal?
2. Investigation: what evidence should we inspect next?
3. Action: which eligible workflow step addresses the finding?

These are useful places to evaluate Jev. Straightforward calculations, exact catalogue lookups and explicit policy checks can continue to run in code. AI becomes valuable where the merchant's language or the interpretation of evidence requires judgement.

The knowledge graph supplies context

A knowledge graph represents entities and the relationships between them. In ecommerce, a metric becomes more useful when it is connected to its store, reporting period, relevant finding and possible response.

Vortex IQ's source already contains services for retrieving profile context, integrations, audits, findings, fixes, reports and KPI snapshots. Our report graph updaters also connect daily briefings to cited KPI cards, paid-traffic findings to campaigns, and recovery opportunities to follow-up flows.

There is a complementary capability graph: a map of what the platform can observe, check and prepare. Our catalogue work connects connectors, entities, operations, KPIs, audits, recommended actions, workflows and merchant roles.

Together, these views can answer two different questions: "What is happening in this business?" and "What supported response is available?"

For example, an investigation might gather a campaign's performance, its destination page, relevant product availability and recent checkout findings. That is a useful evidence trail for deciding what to check next. A relationship in a graph does not establish that one event caused another; observations, hypotheses and confirmed outcomes need distinct treatment.

This is where we see Jev fitting: evaluating a focused decision using relevant graph context. The graph supplies the connections and evidence; the model helps choose an appropriate next step; the execution service validates that step.

Five merchant use cases

The following are proposed Jev applications built around capabilities and data structures in the Vortex IQ codebase. They show the merchant experience we want to evaluate.

1. A Nerve Centre that helps you prioritise the day

"What needs my attention this morning?"

The Nerve Centre can supply relevant KPI snapshots, threshold findings and reporting context. A daily briefing can connect its recommendations back to those sources.

Jev could help assess the urgency, relevance and readiness of candidate investigations against a merchant's role and goal. Application rules would preserve mandatory alerts and check data freshness before presenting the shortlist.

The intended experience is a short, supported priority list: what changed, why it deserves attention and which investigation to open. The merchant spends less effort sorting alerts and can inspect the evidence behind each recommendation.

2. Investigating paid traffic that is failing to convert

"Why are we spending more on ads without getting more orders?"

Our paid-traffic report graph already has structures linking campaign findings to proposed responses, including tracking checks and campaign review.

With the appropriate connected evidence, Jev could choose the next investigation: measurement quality, landing-page friction, product availability or campaign performance. If the evidence is incomplete, it should ask for the missing connection or return an insufficient-evidence outcome.

This could help the merchant investigate wasted spend with a clearer sequence of checks. A recommendation to review a campaign remains separate from changing its budget or pausing it, which requires the relevant authority and execution checks.

3. Building a workflow from a business goal

"When an advertised product runs low on stock, alert my team and prepare the campaign changes for review."

The Automation builder's operation catalogue gives us the vocabulary for assembling that workflow: reading inventory, identifying related activity, preparing an action and notifying an authorised reviewer, where those capabilities are supported.

The application would first filter operations by the merchant's connectors, permissions, required inputs and compatible outputs. Jev could then help select among the eligible steps or identify a missing input. The builder would validate the resulting sequence and present its trigger, conditions and proposed changes before activation.

The benefit is a more accessible way to build an automation while retaining a reviewable workflow. Catalogue size provides breadth; careful selection and validation make that breadth useful.

4. Choosing an appropriate customer-recovery path

"Which recovery opportunities should my team work on first?"

Vortex IQ's recovery graph structures connect opportunity reports with customers and recovery flows. Relevant commercial evidence can inform whether the next step is an investigation, a service follow-up or a suitable recovery workflow.

Jev could help classify the opportunity and assess it against an explicit priority rubric. The application would check communication eligibility, existing actions and duplication before preparing a task or draft.

The intended benefit is more appropriate follow-up with a visible reason for the recommendation. Sending a message, offering an incentive or changing an account would remain subject to the merchant's policies and permissions.

5. Reviewing store performance after a deployment

"Checkout performance dropped after our release. What should we check?"

Our deployment-impact graph code connects before-and-after reports, findings and rollback recommendations. That gives an investigation a place to collect the evidence surrounding a release.

Jev could help select the next supported diagnostic step or route a sufficiently supported concern to a rollback review. The application would calculate the metric differences, account for available evidence and check the affected environment.

The merchant gets a clearer path through a stressful incident. Timing alone is insufficient to establish cause, and an AI recommendation does not authorise a rollback.

How this fits into the platform

Our proposed design follows a consistent flow across the Nerve Centre, Automation builder and Ask Viq:

1. Establish scope. Identify the merchant, store, user permissions, goal and connected services.
2. Collect relevant evidence. Retrieve the needed KPI snapshots, findings and graph relationships, with their sources and freshness.
3. Find eligible options. Use catalogue search and application rules to assemble a small set of valid next steps, including clarification or insufficient evidence.
4. Evaluate the decision. Ask Jev bounded questions about the eligible options and evidence.
5. Validate and explain. Check the result in code, then use a language model where a readable explanation or draft is helpful.
6. Execute under policy and review the outcome. Apply required approvals, record what happened and use the result to improve evaluation.

There is a practical scale constraint here. Jev's current Choice documentation specifies a maximum of 255 options per question. A 14,000+ operation catalogue therefore needs retrieval, filtering and, where useful, decisions in stages. Model confidence also needs testing against our task data before it can justify a routing threshold. Read the Choice documentation.

This design gives each component a defined responsibility. The knowledge graph provides context; Jev can contribute judgement; a language model communicates; application code controls calculations, permissions and execution.

The potential efficiency gains come from focused decision requests, reuse of still-valid evidence and evaluating independent questions together. Connector calls, data retrieval and explanation generation will still contribute to response time. We will measure the complete path a merchant experiences before claiming that a faster decision model makes the platform faster or cheaper to use.

Ask Viq is the front door to that experience

On the website, Ask Viq helps visitors understand Vortex IQ, find pricing and explore relevant capabilities. In authenticated onboarding, the proposed journey extends to identifying a merchant's goal, presenting the appropriate connection step and guiding them towards available workflows.

The distinction between "explain this", "show my results" and "make this change" matters throughout that journey. An intent decision can select a route. Access to private data or an MCP tool still requires the application's account, store and permission checks.

We developed 758 synthetic examples across two complementary catalogues to examine public questions, navigation, onboarding and proposed workspace decisions. The examples guide design and evaluation; each live request uses relevant context and a bounded set of routing choices. Our companion article, Inside Ask Viq: Jev, 758 Questions and Better Decisions, explains the classification flow, the questions that exposed gaps and what complete-response testing taught us.

What we are building towards

Ask Viq is live on our website with Jev as its first model-based classification layer. Clear decisions follow the fast path; uncertain or unavailable Jev decisions can receive one Gemini classification check. Gemini also writes source-backed explanations, while application code handles canonical values and execution rules. The five broader platform use cases above describe our integration direction.

We will evaluate decision quality, useful abstentions, latency and cost per successful task against the same evidence and eligible options. Merchant outcomes, such as time to resolve an issue or completion of a connection journey, need their own measurement.

Our view is that the next phase of ecommerce AI will depend on how well intelligence connects to the business: its signals, relationships, available operations and operating rules. Jev is interesting because it offers a specialised way to handle decisions inside that system.

For Vortex IQ, the ambition is concrete: help merchants turn the breadth of the Nerve Centre and Automation builder into focused, explainable action. Stop revenue leaks. Accelerate growth.

Explore Vortex IQ and ask Ask Viq which capabilities fit your store, or compare the available plans.

Frequently asked questions

What is Jev, and why does it matter for ecommerce?

Jev is TypeSafe AI's System One model for structured decisions. An application supplies context and defined choices, and Jev evaluates the decision within that scope. In ecommerce, this could help select a relevant investigation, prioritise an operational finding or choose an eligible workflow step. Application code still validates the result and controls execution.

How is Vortex IQ already using Jev?

Vortex IQ uses Jev as the first model-based classification layer in Ask Viq on its public website. It helps interpret visitors' requests and select public information or navigation destinations. The release described here uses Jev 1.13.0, with a bounded Gemini classification fallback for unresolved decisions. The five broader merchant use cases in this article describe proposed platform applications.

How do Jev and a generative language model work together?

Jev contributes structured judgements, such as selecting a response mode or an eligible next step. A language model such as Gemini can explain retrieved evidence or prepare readable content. In Vortex IQ's design, application code handles exact calculations, canonical values, permissions and action validation. Each component has a defined responsibility.

What do the 7,000+ KPIs and 14,000+ automation nodes represent?

They describe the breadth of Vortex IQ's platform catalogues. The 23 August 2026 snapshot contains 7,384 KPI definitions and 14,135 workflow-operation records. A merchant's available metrics and operations depend on connected services, permissions, data and supported capabilities. The proposed Jev integration would help select relevant options from that eligible set.

How can Jev work with a catalogue of more than 14,000 operations?

The application first retrieves and filters operations by the merchant's goal, connected services, permissions and compatible inputs and outputs. Jev then evaluates a bounded set of eligible choices, with additional decision stages where needed. TypeSafe's current Choice documentation allows up to 255 options per question, so the full operation catalogue does not belong in one Choice question.

What does the knowledge graph contribute to ecommerce AI decisions?

The knowledge graph connects merchant context such as stores, KPI snapshots, campaigns, findings and reports. The capability graph connects available connectors, operations and workflows. Together they can supply evidence and eligible responses for a focused decision. A graph relationship alone does not prove cause; findings still need source, freshness and execution checks.

Which merchant use cases is Vortex IQ exploring for Jev?

The five proposed uses are prioritising daily Nerve Centre investigations, investigating paid traffic that fails to convert, assembling workflows from business goals, selecting customer-recovery tasks and reviewing performance after a deployment. Each would combine relevant evidence with eligible options and application validation. These examples are an integration direction, not a claim that every workflow is already using Jev.

Can a Jev decision automatically change a store or run an MCP tool?

A model decision does not grant permission to act. Store changes and authenticated merchant MCP operations require a verified account, the correct store, supported tools and the relevant permissions and approvals. The public Ask Viq website chat handles public information and navigation; it does not execute authenticated merchant operations.

Does a faster Jev decision mean the whole merchant workflow is faster or cheaper?

A classifier is one part of a workflow. Retrieving data, calling connectors, generating an explanation and validating an action also contribute to latency and cost. Vortex IQ reports measured Jev routing results for Ask Viq, but broader platform speed, cost and merchant outcomes need end-to-end evaluation before making a comparative claim.

How can merchants explore Vortex IQ's Jev integration today?

Merchants can try Ask Viq on the Vortex IQ website to ask about public capabilities, pricing and integrations or find a relevant page. The companion article, Inside Ask Viq: Jev, 758 Questions and Better Decisions, explains the live routing design and evaluation. Authenticated connections and private store workflows follow the application's separate access and approval process.