Which features are System One tasks?

The first support ticket that arrives after a product launch has to go somewhere. Billing, technical, account, sales, or the queue for things nobody planned for. A person reads it and picks. A language model can read it and pick, and write a paragraph about why. A decision model reads it and returns a probability for each queue, and that is the whole answer. Whether that answer is enough is the question this page exists to sort.

The four tests

A feature is a System One task when all four of the following hold. Test each one separately and write down which fails, because the failing test tells you which other tool to use.

The answers are known in advance. You can write the list of possible outcomes before any input arrives, and the list is short. TypeSafe's Choice question takes up to 255 options, a Score takes 2 to 10 levels described in words, and a Noul is one yes-or-no statement [1]. If the answer to your feature's question is "it depends on what the text says", you have a generation task.

The decision repeats at volume. Hundreds or thousands of times a day, each one alike in shape. The cost arithmetic in the cost of a decision shows why: at ten decisions a day no tool choice matters, and at ten thousand the choice decides whether the feature can afford to check anything at all.

Nobody needs a written reason from the model. Jev "is not trained to generate text" [2]. The output is a probability, and any explanation a user or an auditor sees has to come from somewhere else. If the person receiving the decision will ask why, and the honest answer has to come from the thing that decided, this test fails.

The input is text. The state is "a string, a JSON object, or an array of text values", and images and audio are not accepted [1]. A moderation feature for photos fails here. A moderation feature for the captions passes.

Examples by product type

Customer support. Routing a ticket to a queue passes all four tests. So does tagging it with a topic from a fixed list, deciding whether it needs a human at all, and scoring urgency on a described scale. Drafting the reply fails the first test. Deciding whether a reply the language model drafted is on-topic, polite, and free of a promise the company cannot keep passes, and that is where a decision model sits next to a language model rather than instead of it.

Trust and safety. Moderating a text post against a written policy passes. TypeSafe's own guardrail cookbook screens a message with named questions such as jailbreak, harmful request, medical advice and self-harm in one request, with a 0 to 3 severity score, and shows two example policies: a review threshold of 0.35 and an action threshold of 0.70 for the strict version or 0.85 for the permissive one, with route precedence of support, then block, then review, then pass [3]. That is a complete System One feature drawn by the vendor. Writing the notice to the user about why the post was removed fails the first test and goes to a template or a language model.

Document handling. Checking whether a submitted document contains each required section passes: one Noul per section, asked together. Checking whether a contract clause matches a standard passes. Extracting a date from the document and deciding whether it is before a deadline fails, because Jev "reads dates as text, not as ordered quantities" [2]. Extract the date with a language model or a parser, compare it in code.

Fraud and risk. Producing a signal that feeds a score passes: does this message match a known pattern, does this account description contradict itself, is this listing text consistent with its category. Combining the signals into a decision belongs in code, which is where TypeSafe says the arithmetic should live [4]. Deciding whether two transaction amounts are near each other fails, because the model cannot reliably judge numeric closeness [2].

Search and recommendation. Re-ranking a shortlist by a stated criterion passes: for each result, how well does it answer the query, on a described scale. Generating the query understanding, the synonyms and the rewrite, fails the first test.

Forms and onboarding. Validating a free-text field against a rule passes: is this a business description, is this address plausible for the stated country, is this a real job title. Counting whether a list has at least three items fails, because Jev "does not count reliably" and the error grows with size [2]. Count in code.

Agents. Deciding which tool an agent should call next, whether a tool call is safe to execute, whether the agent's plan is still on track, and whether the final output met the goal all pass. LangChain built middleware on Jev that blocks risky tool calls before they run [5], and Openlayer's jevals library ships checks named ToolChoice, StayedInScope, LoopDetection and GoalCompletion [6]. Writing the agent's next message fails. TypeSafe's own page on coding agents says Jev cannot replace the language model that runs the agent; it sits inside the application for routing, rubric scoring and statement verification [7]. AI agents in production covers where those decision points sit in an agent.

The counter-examples that look like a fit

Summarising. It has a fixed shape, it repeats at volume, and nobody asks why. It fails the first test all the same, because a summary is new text. Scoring an existing summary for faithfulness to its source passes.

Negotiation and pricing replies. The answer set looks small: accept, counter, decline. The third test fails, because the other party will ask why, and the reason is the product.

Code. Deciding whether a code change matches its acceptance criterion passes. Deciding whether a diff stayed in scope passes. Writing the code fails, and reviewing the code in prose fails. This is exactly the split we use at Reveneau: our eval suite keeps every deterministic check deterministic, sends the rubric-graded checks to Jev as Noul or Score questions with the rubric written into the criteria, and routes anything in the uncertain band to a person whose label we keep. The suite runs ten times faster than it did when a language model graded it, on our own suite. Evals with Jev is the engineering detail.

Anything with a hidden dependency on world knowledge. TypeSafe names "hidden context", relying on what the model knows instead of what the state contains, as an anti-pattern [4]. A question like "is this company a competitor of ours" fails unless the state includes the list of competitors. Put the facts in the state and the question passes.

What TypeSafe's own use-case map says

TypeSafe's guidance for building with the model is short and worth reading before sorting any feature. Keep control flow, deterministic rules and side effects in code. Break a broad judgment into atomic questions asked in parallel, then combine them in code with weighted arithmetic. Avoid broad questions such as "Is this spam?", avoid relying on hidden context, and avoid agent loops where deterministic code would do [4]. The patterns page names four shapes: speculative fan-out, confidence-gated routing, composite scoring and intent routing [8].

The practical effect of that guidance is that many features which fail the first test as written pass it once split. "Is this ticket a good ticket" is not a listed answer. "Does it state the product, does it state the version, does it describe a step to reproduce, is the tone abusive" is four Nouls, asked together, with the response time barely changed by the extra three [9]. The combination rule, in code, is yours to write and yours to audit.

The tasks that stay out

Three families never pass, on the model's own documentation for jev-1.13 [2]. Counting anything: items, words, occurrences. Comparing numbers: is this amount within ten percent of that one, is this larger. Ordering dates: is this before that, how long between them. All three were cheap in code before any model existed and remain cheap. The mistake is sending them to a model because the model was already reading the text; extract the value with whatever reads text, then count, compare or order in code.

Two more stay out for other reasons. Anything where the input is an image or a recording, until the vendor says otherwise. And anything where a regulation requires a written reason for a decision about a person, which is a question for your sector's counsel; auditability when the model gives no written reason covers the hand-off, and the regulated industry software guide covers how to find the rule.

How to run the sort on your own roadmap

Take the list of features that use, or are planned to use, a language model. For each, write the question in one sentence and the answer set as a list. If the list cannot be written, mark it generation. If it can, check the volume, then ask whether the person who receives the decision will ask why. What survives is your System One candidate list. Pick the one with the highest volume and the lowest consequence of a wrong answer, and take it into the two-week pilot. The pillar guide has the whole sequence, and how to decide if a feature needs a human in the loop is the older version of the third test, written before decision models existed.

The rule is simple to state and it holds. A decision model answers questions whose answers you already listed. Everything else is somebody else's job.