What JEV is (and is not)

An agent workflow often mixes two different jobs: creating something and deciding what happens next. Writing a useful draft requires language generation. Choosing which work queue should receive a request may only require selecting one label from a short list. Treating those as separate jobs gives you a practical way to think about JEV.

According to the defapi model description recorded in CJS's internal JEV integration plan on October 14, 2026, TypeSafe AI's JEV-1.13 is a non-generative decision model, described by the vendor as “System One.” It takes a supplied state and typed questions, then returns structured decisions. It cannot draft text, code, explanations, summaries, or rationales. Your writing agent still writes. JEV can help route, rank, or gate work around that agent.

Three ways to ask a bounded question

The source plan describes three primitives: Choice, Score, and Noul. A primitive is simply a supported question shape. Each needs a clear input and a useful definition of the answer.

Choice works when you can name the alternatives in advance. The labels need definitions: “research” might mean gathering or checking evidence, while “content” means drafting from evidence already supplied. Include an escape route such as “none fits / review.” Otherwise, an unfamiliar request can be forced into the least wrong tray.

Score works when the order matters. “Low relevance, medium relevance, high relevance” needs an audience and examples of each level. A score is not an objective measurement just because it has a number attached. If the scale is vague, the answer will be difficult to interpret or evaluate.

Noul evaluates a statement. Its output is a probability judgment, not a written justification and not proof. A grounding screen can flag a draft for review, but a favorable result does not establish that every claim is true. The supplied facts may themselves be incomplete or wrong.

These are conceptual examples, not a provider request specification. The exact defapi endpoint and accepted format remain unconfirmed in the supplied plan. You can design a useful question on paper before connecting any service.

Where the fit is strong

JEV is a candidate for repeated semantic decisions: choices that depend on the meaning of text rather than a simple count or exact rule. Consider a coordinator receiving short, sanitized descriptions of work. Some descriptions clearly request research; others ask for a draft based on supplied notes. Choosing a queue could be a useful Choice task.

Ranking candidate material is another fit. A content agent might have several items and a written audience definition. JEV could score relevance against that definition so the agent knows which items to inspect first. The agent must still read sources and write the resulting material.

Gates can also be useful. A proposed screen might ask whether an internal draft appears to introduce unsupported claims. A flag can send it back for checking. A gate must have a defined consequence: “needs review” is useful; “therefore safe to publish” exceeds what the screen establishes.

Tool choice can fit when the options are bounded and permitted. Selecting between an internal search tool and a local document reader differs from authorizing an email or deployment. The latter actions remain subject to hard stops even if both happen to appear in a tool list.

Where the fit breaks

“Write a customer reply,” “explain why this happened,” and “summarize these sources” require generated language. JEV cannot do them. Asking for a Choice answer whose label is an entire canned paragraph still does not turn the model into a writer; it only selects supplied material.

Exact arithmetic and deterministic checks also belong elsewhere. Code should determine whether a deadline has passed, whether a record already exists, or whether an account has a required role. Those checks have exact answers available from authoritative data. Adding a semantic model introduces another failure point without supplying missing judgment.

A useful sorting question is: Can we define the allowed answers, evaluate the choice, and recover safely from a wrong answer? If you cannot define the answers, the job may need research or generation first. If you cannot recover safely, keep the decision with the responsible reviewer.

A complete example: from candidate to draft

Imagine a team collecting possible educational articles. Each candidate has a short description and source references. The audience is beginners learning to supervise agents.

First, ordinary code checks required fields and detects duplicate records. Then a proposed JEV Score question rates relevance to that audience. An agent reviews the ranked candidates and chooses material to investigate. A researcher checks the evidence; a writer drafts the article. A later Noul screen may flag claims that appear unsupported by the supplied excerpts.

Notice what each step contributes. Ranking helps allocate attention. Research establishes evidence. Generation creates the prose. Review decides whether the result meets the team's standards. Publishing remains a separately authorized action.

Suppose JEV ranks an advanced systems article above a beginner tutorial. That is an evaluation example: perhaps the audience definition is weak, the scale is ambiguous, or the model made a mistake. Keep the input, proposed ranking, reviewer judgment, and eventual outcome available for comparison under your data policy. Do not ask the writing agent to invent a rationale and present it as JEV's explanation.

The never-JEV boundary

The integration plan puts these classes behind hard stops. JEV may suggest only; it never makes the final decision about:

• Money, including payments, prices, refunds, and plans.
• DNS, infrastructure, servers, firewalls, and deploys.
• Sending, including email, social posts, and messages.
• Publishing, including articles, lessons, and site copy.
• Deletion of data.
• Access, roles, permissions, and user accounts.

A high confidence value does not create permission. Neither does choosing an approved-looking label. “Send this reply” remains a sending decision even if it arrives disguised as routing. The policy needs to recognize the action's consequence and pass it to the responsible agent or owner under existing approval rules.

This boundary still allows useful suggestions. JEV might classify an infrastructure request for specialist review. It must not approve the change. Likewise, it may suggest that a draft needs editorial attention without deciding to publish it.

Start by observing

The plan names four modes: off | shadow | suggest | auto.

In off, the workflow uses its existing decision process without calling JEV. In shadow, JEV's result is recorded for comparison, while the existing process continues to decide. In suggest, a person or responsible agent sees the proposal and confirms or overrides it. In auto, only a specifically approved, low-stakes decision can affect the workflow automatically, within policy limits.

Shadow is the preferred starting point once the endpoint, data policy, and evaluation setup are ready. It lets you discover confusing inputs and confident errors before depending on the output. Shadow calls still send data and can incur charges; they are not a substitute for resolving provider questions. The exercises in these public parts need no API calls.

Claims, evidence, and unknowns

The vendor description recorded in the plan claims low latency, schema-conforming outputs, and calibrated confidence. Those are attributed vendor claims, not measurements from this course. Correct formatting does not guarantee a correct choice. Calibration means confidence should correspond to observed accuracy across comparable cases; it must be checked on your own reviewed examples.

The plan's execution log reports unsuccessful defapi endpoint discovery and no successful JEV evaluation call. The exact JEV endpoint on defapi is unknown. Rate-limit numbers are unknown / not published in the reviewed material. Retention periods and use of requests for training are unknown. Exact price coverage, including treatment of input, output, and possible request charges, is unknown. The Choice option limit is also unresolved in the cited material.

These gaps matter to implementation. Do not build a cost promise, throughput promise, or data policy from assumptions. This introduction deliberately gives no runnable provider call and makes no savings claim.

Quiz

Q1. Which task fits JEV, a non-generative decision model?

• Writing a reply to a customer.
• Summarizing a set of sources.
• Choosing which internal review queue should get a short, sanitized request.
• Explaining why a past decision was made.

Q2. JEV gives a very confident answer on a request to publish a lesson. What is JEV's role?

• It can publish, because confidence is high.
• It can publish only in auto mode.
• None. The request must not reach JEV at all.
• It can only suggest. Publishing is a hard stop, and the responsible owner makes the final decision.

Q3. According to the reviewed material, which of these is known about JEV on defapi?

• The exact endpoint and its rate limits.
• How long request data is retained.
• None of these. The endpoint, rate limits, retention and exact price coverage are all unknown.
• The full price per decision, including request charges.

Sources and next step

This part draws on CJS's internal JEV integration plan, dated October 14, 2026, including its later execution log. Its vendor references include the defapi JEV model page, pricing page, terms, and acceptable use policy. Statements attributed to those pages were re-checked against the live pages on October 15, 2026.

Part 2 places the decision model inside an agent stack: behind an internal service, beneath policy checks, and alongside the agents that continue to research, write, review, and act.