Should I use Jev to extract data from emails?
Verdict for the sample idea
Run it on
a reasoning LLM
Every case needs generated text, planning or multi-step reasoning.
Sample idea
Read each incoming order email and extract the customer name, the order number and the refund amount into our database. About 800 emails a day, written by customers in free text.
Explanation
This is the grey zone. For the sample idea the tool answers "a reasoning LLM", because the idea asks for open strings such as a customer name. For your own case the honest answer is "it depends on details the idea does not contain", and the right design is usually a split.
The core problem is the output. Jev never writes text. It returns an option, a level or a probability. "Customer name" is an open string, so Jev cannot return it. An LLM can, and for fully free text an LLM with a schema is the normal tool.
A cheaper design works for many cases, and one of TypeSafe's cookbooks describes it. Code finds the candidates, and Jev picks one. A regular expression finds every string that looks like an order number. When it finds one, you are done, and the verdict for that field is plain code. When it finds three, because the customer quoted an old order, a Choice over the three candidates is a good Jev question: which of these is the order the customer wants refunded? The same works for amounts and for names from a header and a signature.
So shape it field by field. Order numbers with a fixed format need code. Amounts need code to find candidates and Jev to choose. Names with no pattern at all need an LLM, or a named-entity library.
Validate in code after every step. An order number must exist in your database. An amount must not exceed the order total. These checks catch model errors of every kind.
The common trap is adversarial and messy input. Emails contain signatures, quoted threads and forwarded content, and a refund amount that a customer typed is a claim, not a fact. Never pay out on an extracted number. Look the amount up from the order.
The second trap is to describe the task in one line and to expect one verdict. Split it into fields, and check each field.
Related tasks
Verdict produced by Jev on 2026-09-19, rubric version 2. Text written by a person. How the tool works: the report.