Classifying Jev-Suitable Product Requirements

Welcome to the first lesson of your course on using Jev in real applications. This first week establishes the practical mental model you will need before writing SDK calls: Jev is not a general-purpose chat model with a different API. It is a component for making fast, typed judgments that software can act on.

The central engineering decision is therefore not, “Can an AI model answer this?” Many models can produce a plausible answer. The better question is: does this requirement need a bounded decision, or does it need language generation, computation, or multi-step reasoning? By the end of this lesson, you should be able to classify product requirements accordingly and identify cases where Jev is only one component of a hybrid workflow.

---

A model for decisions, not prose

Before working through a decision framework, watch this short orientation. It contrasts fast “System One” classification with slower reasoning-oriented models, then explains the shape of a Jev call.

A generative LLM is optimized to continue text. That is exactly what you want for requirements such as:

• “Draft a helpful response to this customer.”
• “Summarize this incident for the engineering channel.”
• “Explain why this build failed.”
• “Write TypeScript that transforms this API response.”
• “Suggest three ways to improve this onboarding flow.”

In each case, the valuable output is new language. Its wording, structure, length, and content are not fully known before the call.

Jev has a different contract. Your application supplies relevant state and a constrained question. Jev returns a typed judgment, such as:

• one category from a known list;
• a judgment on a predefined ordered scale;
• the probability that one precise proposition is true.

For example, a support workflow might ask:

• Which team owns this ticket: billing, technical, account, or other?
• Is the customer explicitly requesting a refund?
• How severe is the reported issue on a defined scale?

The application can immediately use those results in routing, authorization, escalation, feature gating, or analytics. It does not receive a customer-ready explanation of the answer.

The distinction resembles the difference between a UI event handler and a rich-text editor. An event handler needs a stable value such as "submit" or "cancel" so code can proceed. A rich-text editor exists to produce open-ended content. Both can consume text; they serve fundamentally different roles.

---

The bounded-decision test

The TypeSafe documentation is the authoritative baseline for this course. Read the two sections below before applying the framework.

Use the following five-part test when you encounter a proposed AI feature.

1. Is the valid output space known before the model call?

This is the first and most important question.

A Jev-friendly requirement has an output contract that product and engineering can define now:

• one of a finite set of queues;
• a yes/no proposition;
• a policy-defined severity level;
• a rating on an explicitly described scale.

A requirement is not Jev-friendly when the answer itself must be invented or discovered:

• “Tell the user what to do.”
• “Write a migration plan.”
• “Find the most useful feature we could add.”
• “Produce a concise incident summary.”

A known answer set is more than “we will parse the response as JSON.” For Jev, the allowed values are the decision itself, not merely a wrapper around generated prose.

2. Is the task a semantic judgment rather than an exact computation?

Jev can interpret language and evidence, but it is not a replacement for normal program logic.

Good semantic judgment:

Does this message indicate that the user cannot access their account?

Exact computation:

Has the account exceeded five failed login attempts in the last fifteen minutes?

The first depends on the meaning of varied natural language. The second is a database query and comparison. Use code for it: it is faster, correct by construction, testable, and does not consume model capacity.

3. Can the question be answered in one focused pass over relevant evidence?

Jev is intended for fast, focused judgments. It is not the right component for an open-ended investigation involving hidden assumptions, extended deduction, tool use, or a chain of dependent conclusions.

For example:

• “Does this customer message request a live agent?” is focused.
• “What is the root cause of this distributed-system outage and what should we deploy?” requires investigation, reasoning, and probably human review.
• “Which supported intent best matches this request?” is focused.
• “What new intent should our product support?” is discovery work, not classification.

4. Does a typed result enable a real application action?

The point of a bounded decision is that the surrounding application has a defined response.

Model judgment	Deterministic application action
billing queue owns the ticket	Create or route a billing ticket
The user requests a human	Stop automated handling and escalate
Message likely contains PII	Redact, block, or send for review
Severity is high	Page an on-call team or raise priority
Requested tool is searchOrders	Continue into validated parameter collection

If no action follows, ask whether a model judgment is really needed. A dashboard may still benefit from classification, but the product value and error tolerance must be explicit.

5. Does fast, repeated decision-making matter operationally?

A bounded judgment can be conceptually suitable for Jev even if it occurs rarely. But Jev becomes especially compelling when the requirement also has one or more of these properties:

• it runs at high request volume;
• it lies on an interactive latency path;
• it replaces a costly structured-output LLM call;
• it drives a repeated operational workflow;
• malformed or out-of-schema output would be expensive to handle.

This is an operational-fit question, not a definition of intelligence. A low-volume internal tool might remain on a structured LLM if latency and cost do not matter, even where the answer set is known. Conversely, a fast classification step in a customer-facing workflow can be an excellent Jev candidate.

The decision tree is useful because it distinguishes two decisions that are often blurred together:

1. Can this requirement be expressed as a bounded judgment?
2. Is it worthwhile to move this particular production step to Jev now?

If valid answers are not known in advance, stay with a generative model. If they are known but the workflow has low operational pressure, keeping structured output on an existing LLM may be a pragmatic choice. When the step is high-volume or latency-sensitive and a wrong answer blocks an action, a typed System One decision plus confidence-aware routing is a strong architecture.

Notice one important implication: a typed output prevents the model from inventing an unsupported category or returning malformed prose in place of a decision. It does not make the selected category automatically correct. The model can still make a wrong judgment, which is why confidence, thresholds, review paths, and evaluation matter later in this course.

---

False fits: requirements that sound like classification but are not

Some requirements initially appear to fit Jev because they can be phrased as yes/no or multiple-choice questions. That phrasing alone is not enough.

Read the selected parts of the Jev “jaggedness” documentation, which describe where the model should not be used as a substitute for code or generation.

Here are common product requirements and their proper classification.

Product requirement	Classification	Appropriate design
“Write a polite reply explaining our refund policy.”	Unsuitable for Jev	Use a generative model or a maintained template system.
“Which of our four support teams should own this message?”	Suitable for Jev	Ask a bounded Choice question; route the result in code.
“Determine whether this account is eligible for a refund under policy limits.”	Usually hybrid	Code checks dates, amounts, and transaction facts; Jev may judge ambiguous language such as whether the customer is requesting a refund.
“Count how many prohibited words appear in the message.”	Unsuitable for Jev	Use string matching, a parser, or regular expressions.
“Does this message contain a credible threat?”	Suitable, with safety controls	Use a precise bounded judgment, then apply an explicit escalation policy.
“Compare a user-supplied date with a cancellation deadline.”	Unsuitable as stated	Extract missing date components if necessary, then parse and compare in code.
“Produce a release-note summary from these commits.”	Unsuitable for Jev	Use a generative LLM; this requires synthesized text.
“Choose which allowlisted workflow should handle this natural-language request.”	Suitable for the selection step	Jev selects from known workflows. Parameter extraction and validation are separate concerns.
“Diagnose why a production deployment is intermittently failing.”	Usually unsuitable	Use observability data, deterministic checks, a reasoning model, and potentially human investigation.

The hybrid cases are the most valuable in real applications. “Not pure Jev” does not mean “no Jev.” It means the architecture should give each component the work it is best suited to perform.

Consider a refund-support feature:

• A user message may be ambiguous, so detecting whether it asks for a refund is a semantic judgment.
• Transaction totals, prior refunds, deadlines, and policy thresholds are exact facts.
• The final customer response is generated language.

A robust product design can use all three kinds of capability without confusing them:

Concern	Best owner
Detect whether the user is requesting a refund	Jev
Calculate refundable amount	Application code
Verify transaction and policy constraints	Application code
Decide whether low-confidence cases require review	Application code using model output
Write the response to the customer	Generative model or approved templates

This separation reduces the temptation to ask one model to do everything. It also makes each part easier to test: exact rules get unit tests, model judgments get labeled evaluations, and generated content gets its own quality and safety review.

---

Turning vague feature ideas into decision contracts

Most product requests arrive in an unhelpful form:

“Automatically handle incoming support messages.”

That is not yet a Jev requirement. It bundles several different jobs with incompatible output types.

A decision-ready decomposition might identify:

1. Route ownership: choose billing, technical, account, or other.
2. Refund request detection: estimate whether the message explicitly requests a refund.
3. Urgency assessment: assess urgency against a defined operational scale.
4. Eligibility: verify account and transaction rules in code.
5. Reply composition: generate or select the user-facing response.
6. Escalation: apply deterministic policy using the returned decision and confidence.

Only the first three are natural candidates for Jev. The fourth is ordinary software logic. The fifth is generation. The sixth belongs in your application because it encodes product risk tolerance.

For early feature discussions, phrase prospective Jev steps in this compact form:

Given this evidence, select one known operational outcome, or estimate one precise proposition, so the application can take a defined action.

Compare that with this non-Jev form:

Read all available information, figure out what is happening, calculate any necessary facts, decide the best policy, and explain it to the user.

The second may still be a useful AI feature, but it asks for open-ended reasoning and text generation. It should not be disguised as a single classifier call.

A final caution: “fast” should not lead to careless automation. A high-confidence label may be sufficient to route a ticket, but insufficient to delete data, deny a refund, ban an account, or take another irreversible action. Later lessons will cover confidence values, thresholds, fallback behavior, and evaluation. For now, include the consequence of error in the requirement itself.

---

Key takeaways

Jev is a fit when a feature needs a fast semantic judgment with a predefined typed output, such as choosing a queue, assessing a defined severity scale, or estimating whether a precise condition holds.

Use this classification rule:

• Choose Jev for bounded, actionable judgments over relevant evidence.
• Choose code for arithmetic, counting, date comparison, parsing, and any other exactly computable rule.
• Choose a generative LLM when the required output is prose, code, a summary, an explanation, or an unbounded discovery task.
• Choose a hybrid workflow whenever a real feature combines semantic interpretation, exact rules, and generated communication.

In the next lesson, you will take this one step further: partition an AI-assisted workflow into deterministic application logic and small, atomic model judgments. That is the design discipline that turns a promising classification idea into a system that can be implemented, tested, and operated safely.