Jev Question Translator

Jev Question Translator

Jev is TypeSafe's first System One model. It receives a state (text or JSON) and a set of named questions, and returns one typed answer per question:

• Noul: the probability that a yes/no proposition is true. There is no separate confidence value.
• Choice: one option from a set of up to 255, with a probability for every option and a confidence value.
• Score: a position on an ordered scale of 2 to 10 described levels, with a probability for every level and a confidence value.

Jev does not generate text or explain its answers. All questions in a request see the same state and are answered independently; no question can see another question's answer. Adding questions to a request changes response time very little, because they run in parallel.

This skill takes what the user wants to know and produces questions Jev can answer reliably. Jev makes the individual judgments; code does the arithmetic, combines the judgments, and reaches the final conclusion. The procedure below designs the questions with that division in mind, but the skill delivers only the questions.

Why legal professionals would use this

A great deal of legal work consists of asking the same questions of many documents. A researcher coding fifty state statutes asks, for each statute, whether it covers a given activity, who enforces it, and what penalty it sets. A scholar studying appellate decisions asks, for each opinion, which test the court applied and whether it found each element satisfied. A lawyer reviewing a portfolio of leases asks, for each lease, whether it contains an assignment clause and whether that clause matches the client's preferred position. A professor grading eighty exams asks, for each answer, whether the student identified the controlling statute and applied each element. The questions are fixed; only the document changes.

Jev is built for that shape of work. It receives a document and a list of typed questions and returns, for each question, a probability that the answer is yes, a choice among options the user defines, or a position on a scale the user describes. It does not write prose or explain itself. TypeSafe designs it to be fast, inexpensive per question, and consistent, so that the same document and question produce the same answer on every run. For legal work these properties matter in concrete ways:

• The answers are data. Each answer is a number or a label that goes straight into a spreadsheet or a statistical package. A fifty-state survey or a coded set of opinions comes out as a table rather than as fifty paragraphs someone must read and re-code.
• The analysis is visible element by element. When a conclusion is built from separate answers about each element, a reviewer can see which element failed, not just the conclusion. That is the form in which lawyers already check one another's work.
• Uncertainty is reported. A probability near the middle marks a document a person should read. The lawyer can send those documents to human review and accept the clear ones, instead of reviewing everything or trusting everything.
• Consistency across documents. Every document is judged by the same questions in the same words. In grading and in empirical coding, that consistency is itself a requirement.

Jev answers narrow, literal questions well. It answers broad legal conclusions poorly, and it does not know the law of any jurisdiction. "Was the defendant negligent?" asks it to supply a body of doctrine and apply it in several steps, which it cannot do reliably. "Does the narrative state that the driver was looking at a phone while the car was moving?" is a question it can answer. Turning the first kind of question into the second is the familiar lawyer's task of breaking a doctrine into its elements, factors, and definitions, together with rules about wording that are specific to Jev. This skill performs that translation.

Legal uses

• Legal epidemiology and policy surveillance. Code the same features across statutes or regulations from many jurisdictions. Each feature becomes a question, with a "not addressed" option because many statutes are silent on a given point. The coded results can be compared across jurisdictions and over time.
• Empirical legal research. Code judicial opinions, dockets, or case files: the procedural posture, the test applied, whether each element was found, the outcome. Hand-code a sample to measure Jev's agreement with human coders before relying on the rest.
• Contract and document review against a checklist. Each checklist item becomes a question; a playbook position can be written into the question so that Jev compares the clause with it. Portfolios of leases, NDAs, or vendor agreements can be screened for missing or non-standard provisions, with uncertain documents routed to a lawyer.
• Intake and triage. Legal aid organizations and clinics can flag the issues an intake narrative raises and the eligibility facts it states, so that a person reviews the narratives the classifier cannot place.
• Legal education. Turn a grading rubric into questions, with the rule the student must apply written into each one, and apply it identically to every exam, with borderline answers flagged for the professor. The decomposition itself is also a teaching exercise: students who must break a doctrine into questions a literal reader can answer learn its elements.
• Classifiers for fact patterns. Build a fixed battery that diagnoses whether a doctrine applies to a hypothetical or a case summary (for example, the elements of felony murder under a particular state's statute, or the parts of federal standing doctrine) and run it over many variations of a fact pattern to see which facts change the result.

How a legal professional uses it

1. Bring the question and the material that governs it: the statute, the test from the leading cases, the rubric, the checklist. Say what documents the questions will be asked of, such as case summaries, complaints, statutes, or student answers.
2. The skill returns the questions. Each question names the part of the document it reads and carries any rule it depends on. Rules the skill writes from its own knowledge are marked as paraphrases so they can be checked against the sources.
3. Run the questions on a dozen or so documents whose correct answers are already known, using TypeSafe's playground, its API, or a tool built on them. Compare Jev's answers with the known ones, and revise wording where Jev misreads a question.
4. Run the questions on the full set of documents. Combine the answers according to the legal test, in a spreadsheet or a short program: every element present, any one of several grounds present, factors weighed. Send documents with answers near the middle to a person.
5. Keep the element-level answers. They are the record of how each document was classified.

Known weaknesses

TypeSafe documents the following for jev-1.13 (as of September 2026). If web access is available, check the current list at https://docs.typesafe.ai/model-jaggedness/jev-1.13.md (or the page for a newer version) before relying on it.

• It reads instructions literally and answers the words written, not the intent behind them.
• It does not count, calculate, or compare numbers reliably.
• It does not compare dates or compute intervals reliably.
• Questions that require several steps of inference, or that contain double negatives, are less accurate.
• Irrelevant material in the state reduces accuracy. The context window is bounded (32,000 tokens for jev-1.13).
• Text in the state that argues for a particular answer can shift the answer.
• Instructions and criteria that point in different directions confuse it.
• A question and its negation, or a Noul and a two-option Choice on the same proposition, need not produce complementary numbers.
• It cannot write out a value; it can only choose among the options it is given.
• It is trained mainly on English; other languages are less accurate.

Jev cannot be assumed to know specialized rules: a jurisdiction's law, a grading rubric, a coding manual, a company policy. Any rule a judgment depends on must be supplied in the question.

Inputs

The user may bring any of these:

1. One broad question ("Was the driver negligent?", "Should this study be included in the review?", "How good is this memo?").
2. A list of questions already drafted. Some will work as written; others need splitting, rewording, or moving into code.
3. Material that implies questions without stating them: a rubric, statute, checklist, policy, coding manual, or set of inclusion criteria. Each requirement, element, factor, or rubric line is a candidate question.

Also establish what the state will be (the document or record the questions are asked about) and whether the same questions will be asked of one document or of many. If this is unclear and the answer would change the questions, ask.

Procedure

1. Find the structure of the conclusion

Write down the conclusion the user ultimately wants. Jev will not be asked it directly. Identify how the conclusion depends on simpler judgments; that structure determines how to take it apart.

Most real conclusions combine several of these structures. Apply the table again to each piece: an element of a claim may itself be a weighing test, and a factor may depend on a value that must first be extracted.

The unit of analysis. Identify what the rule is applied to: each plaintiff, each defendant, each claim, each form of relief, each rubric line, each statutory provision, each paragraph. A single document often contains several such units: a complaint with three plaintiffs and three forms of relief, a vignette with two defendants, an essay with ten paragraphs. A question asked about several units at once has no single correct answer, and Jev returns a middling value that reflects the mixture rather than uncertainty about any one unit. When a document can contain more than one of a unit, do one of the following:

• Make the unit its own state field, with a name that says the questions are asked about one unit at a time (plaintiff, defendant, paragraph), so that the user runs the questions once per unit.
• Write one question per unit, naming the unit in the question ("If plaintiff asks for an injunction, would that injunction...").

Do not write a question about "the relief," "the plaintiffs," or "the claims" when the rule applies to each separately.

2. Split until each question meets these conditions

• It asks about one proposition or one dimension. "Was the defendant speeding and distracted?" is two questions. A Score whose levels mix punctuality and skill is two Scores.
• It can be answered from the state plus whatever the question itself supplies. If a knowledgeable person would need a rule or definition the request does not contain, add it (step 4).
• A person who knows the field could answer it almost immediately after reading the relevant part of the state. If answering requires first working out an intermediate result, that result is a separate question or a computation in code.
• It does not depend on another question's answer (step 3).
• It contains no counting, arithmetic, or comparison of dates or amounts.
• Its possible answers can be listed in advance. If they cannot, the task needs a generative model.

Stop splitting once a question meets these conditions. A relational question such as "Does source.passage support the proposition in brief.sentence?" is one judgment. Splitting it into "Does the passage mention X?" and "Does the brief mention X?" discards the relation that was being judged. Each question should contain one judgment, and a single judgment may require reading two parts of the state together.

Conclusion words. Terms such as negligent, reasonable, material, adequate, valid, compliant, or well-organized stand for a body of rules. Either replace the term with the observable conditions it stands for, or keep it and supply its definition in the question.

Persuasive text in the state. When the state is a brief, a complaint, a sales pitch, or anything else written to persuade, ask what the document asserts or what support it offers ("Does complaint allege that the defendant was using a phone?"), not whether its conclusions are correct. Persuasive text can move Jev's answer toward the writer's position.

3. Handle dependencies between questions

A question cannot say "if the answer to the previous question was yes." Use one of these instead, in this order of preference:

1. Put the premise in the question. "If the customer is asking to return an item, what reason do they give?" Code uses the answer only when the premise holds. Answers that go unused cost little.
2. Ask once for each possible value of the earlier answer. If the applicable standard could be any of three, ask whether the conduct met each standard, each defined in its own question, and let code use the one that matches the answer to the question about which standard applies.
3. Plan a second set of questions only when the later question cannot be written until the earlier answer is known: the earlier answer decides what goes into the state, which document to retrieve, or which options to offer.