What Comes Next? Using Jev in Leina for Ecommerce, Market Research, and Browser Tasks
Call Jev directly from Leina chat. Explore five workflows for product listings, customer feedback, stocks, futures, gold research, and browser tasks, with prompts to try.

Conceptual illustration: turning product information, market news, and page states into choices you can check.
You open your laptop to dozens of customer comments, a backlog of overnight market news, and a product draft still waiting in a browser tab.
The small decisions between tasks often take the most attention. Does this complaint deserve an early review? Does that gold analysis contain new information, or repeat an old opinion under a new headline? Will “Submit” save a draft or publish it?
Leina can now connect directly to the Jev API. Supply the material, describe your criteria, and explicitly ask Leina to call Jev in chat. Leina organizes the task and presents the results; Jev answers focused judgment questions.
The five scenarios below are workflow ideas and example requests, not measured results or preinstalled templates. Business data, market sources, and browser actions require the corresponding tools and authorization in Leina.
Break a Large Task Into Small Judgments
Developed by TypeSafe, Jev accepts text or structured text and returns constrained choices, scores, or true/false judgments. A question such as “Which category best fits this complaint?” suits it well. More complex tasks need to be broken down. See the official question-type documentation.
| Judgment | A useful question | How the result helps |
|---|---|---|
| Choice | Is this an assembly, shipping, or other issue? | Route it to an appropriate review list |
| Score | How specific is this material on defined levels? | Compare where more detail is needed |
| Noul | Does the customer explicitly request a refund? | Return a probability of “yes” for downstream rules |
Keep source material, judgments, and actions separately inspectable. Jev returns structured judgments. Leina can arrange those results alongside excerpts and explanations drawn from the material. Programs handle explicit calculations, and the appropriate tools carry out actions.
01 / Product Listings: Give the Data an Entry Check
Suppose you are preparing a batch of storage cabinets for listing. Some supplier records include dimensions, some omit materials, and a few titles say “solid wood” while the specifications say “MDF.”
Checking for empty cells will not catch that contradiction. A program can first validate prices, inventory, required fields, and duplicate SKUs. Jev can then assess whether individual claims about materials, capacity, or intended use have support in the supplied records.
Try this request in Leina:
Check these storage-cabinet listing records. Validate required fields, prices, inventory, and duplicate SKUs first. Then call Jev to assess whether the title, selling points, and specifications agree, claim by claim. Organize the records into “sufficient material for human preview,” “more information needed,” and “conflicting descriptions.” Preserve the original fields and highlight what I should inspect. Do not infer missing specifications.
The solid-wood/MDF conflict deserves a closer look. Missing dimensions can simply be marked missing. The useful output is a work list with source text, helping you decide which records to complete and which to preview first.
For product selection, you can also supply candidate descriptions alongside explicit sourcing requirements and check whether each matches the intended use or lacks necessary information. Sales, margins, and inventory turnover still need real data and calculations; they cannot be inferred from a product description alone.
02 / Customer Feedback: Find the Same Problem in Different Words
“The door won’t fit,” “the screw holes in step three don’t line up,” and “there’s a bracket left over” may look like separate complaints. They may also point toward assembly issues worth investigating together.
Support needs individual records to act on. The product team wants to know whether the same issue keeps appearing.
Try this request in Leina:
Review these storage-cabinet comments from the last two weeks. Call Jev to judge the main issue category and, separately, whether each comment explicitly describes tipping, injury from breakage, or another situation needing prompt human review. Use “shipping,” “assembly difficulty,” “structure or parts,” “appearance expectations,” and “other or insufficient information.” Preserve each original comment and order identifier, then use a program to count categories and summarize recurring issues.
Two Review Lists From Customer Feedback
flowchart TB
accTitle: Two Review Lists From Customer Feedback
accDescr: Jev classifies customer feedback. Leina preserves the source text and uses a program to aggregate issues into lists for support and product teams.
A(Original feedback):::channel --> B(Jev classifies and judges):::agent
B --> C(Leina pairs sources with results):::gateway
C --> D(Support review list):::resource
C --> E(Program counts related issues):::resource
E --> F(Product investigation list):::resourceWhen several customers mention the same assembly step, the team can inspect the instructions, parts, and batch. Classification brings clues together; confirming the cause still requires product and order evidence.
03 / Stocks, Futures, and Gold: Sort the News Before Analyzing It
One central-bank speech may produce ten headlines. An article about gold may mix published data, the author’s interpretation, and predictions about what happens next.
Start by sorting information: group reports by source and event, then use Jev to classify passages and judge their relevance to an existing research question.
Try this request in Leina:
Use the news and research plan I provide. Call Jev to classify each passage as “a statement about an event or published data,” “market opinion,” “forecast or speculation,” or “insufficient information.” Separately judge whether it relates to the instruments and conditions in my plan. Split mixed passages first. Preserve sources, publication times, and excerpts; group duplicate coverage of the same event and list what needs verification.
| Material | A focused judgment | Evidence to check next |
|---|---|---|
| A stock’s quarterly earnings announcement | Does it address an operating change tracked in the plan? | Original filing, disclosure time, and financial figures |
| A futures inventory report | Does it concern supply or demand for the target commodity? | Commodity, units, methodology, and historical data |
| Policy news relevant to gold | Does it describe a policy change, commentary, or prediction? | Official source, publication time, and exact wording |
Consider: “The data has been released, and an analyst expects gold to strengthen.” The first clause states an event; the second makes a prediction. Separating them makes it easier to distinguish what needs fact-checking from what is a view.
Classifying a passage as an event statement does not verify that the event happened. Verification requires checking the source. A probability assigned to a classification option is also not a probability that a stock, futures contract, or gold price will rise.
The deliverable can be modest: a reading list organized by topic, with its sources intact, ready for further analysis.
04 / Trading Plans: Check the Conditions You Wrote Down
Trading plans often contain two kinds of conditions. Some concern prices, position sizes, and time windows. Others ask whether an announcement addresses a previous concern, or whether new information conflicts with the original thesis.
Programs can calculate the first kind. The second can be split into focused questions for Jev to help check.
Try this request in Leina:
Check this candidate action against my existing trading plan. Use a program to verify numerical conditions such as price, position size, time, and risk amount. Call Jev to assess each textual condition against the available material, choosing “supported,” “not supported,” or “insufficient information.” Preserve the relevant excerpts and list unmet conditions and items needing review. Limit this task to checking the plan.
Stocks, futures, and gold can use a similar review structure, but their calculation rules need to be explicit. Futures contract multipliers, margin requirements, and trading hours cannot simply inherit stock-trading assumptions.
The output is a checklist of plan conditions. The user decides whether to trade after verifying the information. Matching the conditions does not imply a profitable trade.
Writing criteria before taking action also makes later reviews more useful: did the plan need improvement, or did the action depart from it?
05 / Browser Tasks: Read the Page Before Choosing the Next Step
Return to the listing task. Leina is entering product data through an available browser tool when the page displays a message. A required field may be missing, a request may have timed out, or the draft may already be saved without a redirect.
Reading the current page state before deciding what to do makes the workflow easier to inspect.
Try this request in Leina:
Use the available browser tool to enter these product records and save them as drafts. At validation messages, errors, or submission steps, read the page text and form state first. Then call Jev to choose among “continue filling,” “request missing information,” “check whether saved,” and “stop and report.” Stop for login verification, insufficient information, or a page offering only direct publication. Verify that the draft exists before reporting completion.
Read the Page, Then Choose an Action
flowchart TB
accTitle: Read the Page, Then Choose an Action
accDescr: A browser tool reads page text, Jev judges the state, and program rules check action boundaries. Allowed actions are executed and verified; insufficient information or out-of-scope actions lead to a stop.
A(Browser reads page text):::channel --> B(Jev judges page state):::agent
B --> C(Rules check action scope):::gateway
C --> D(Execute an allowed action):::resource
C --> E(Stop and report):::restricted
D --> F(Verify the saved state):::resourceJev currently accepts text. Another tool must first turn screenshots into text or structured information. Browser tools handle clicking, typing, and saving. Page content is data to inspect; it should not change the user’s agreed task boundaries.
If a submission produces no clear response, check whether it was saved before deciding what to do next. That avoids entering the same product twice. A newly saved draft or another explicit completion state provides evidence for reporting success.
Start With Twenty Real Examples in Leina
Open Leina, choose your agent, and confirm that its available tools include Jev access. For a first attempt, supply a small batch of text directly and check the judgments. When the task needs external data, verify the corresponding connection and operations; see business-app connections.
Use this request as a starting point:
Actually call Jev to process the twenty items below. The context is…; the separate questions for each item are…; the available answers are…, including “other or insufficient information.” Apply these criteria…. Preserve input identifiers, each returned judgment, and source text for my review. If you cannot call Jev, explain what is missing. For this task, return a review list first.
Check clear, ambiguous, and contradictory examples before adjusting the criteria. According to TypeSafe’s language documentation, Jev currently performs best in English. Validate Chinese and other languages against your own real material.
Once the workflow works, capture its inputs, criteria, calling steps, and exception handling in a Skill. Reuse the same method with the next batch of products, news, or browser tasks.
Start with one small judgment, and give the next step evidence and criteria you can check.