Jev Can Make Decisions. But How Do You Work With It?

Hello, I'm Rijul, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product.

---

In the previous article, we explored the basic concepts behind Jev and its three decision types: Choice, Score, and Noul.

Now, let's look at how to work with Jev more effectively. We'll cover the kind of input it accepts, how to structure a request, how multiple questions are evaluated, and how to design Choice questions that avoid forced or misleading answers.

1. Understanding State

In Jev, state is the information the model uses to evaluate your questions.

A state can be provided in three formats:

• String: Plain text, such as a customer message or incident report.
• JSON object: Structured information containing fields such as an order ID, customer status, or error message.
• Array: A collection of context items that provide information for a decision.

For example, a customer support application might provide this state:

{
  "customer_message": "My payment failed, but I was charged twice.",
  "account_status": "active",
  "previous_contact": "No previous complaints"
}

Jev can use this information to answer questions about the customer's issue, account, or next steps.

However, Jev is a text-based model. It does not directly accept images, audio, video, or other binary inputs as state. If your application receives these formats, you need to extract relevant information into text or structured data before sending it to Jev.

2. Understanding Request Anatomy

A Jev request consists of three main components:

• model: The Jev model you want to use.
• state: The information the model should evaluate.
• questions: A map of named questions you want answered.

Each question has its own identifier and definition. The identifier helps your application locate the corresponding answer in the response.

Here's an example:

{
  "model": "jev-latest",
  "state": {
    "customer_message": "My payment failed, but I was charged twice."
  },
  "questions": {
    "issue_type": {
      "type": "choice",
      "instructions": "What is the primary issue?",
      "criteria": {
        "billing": "Payment failures, duplicate charges, or refunds",
        "technical": "Application errors or technical failures",
        "account": "Account access or account management issues",
        "other": "The issue does not fit any of the other categories"
      }
    },
    "needs_follow_up": {
      "type": "noul",
      "instructions": "Does this customer need a follow-up from support?"
    }
  }
}

In this example, the request contains two questions about the same customer message.

The first uses Choice to classify the issue. The second uses Noul to evaluate whether follow-up is needed.

Notice that each question has its own type and instructions. Choice uses a criteria field to define the available options. Score uses criteria to define an ordered scale, while Noul can evaluate a yes-or-no question without requiring criteria.

This structure lets you define multiple decisions in one request rather than making a separate request for every question.

3. Parallel, Independent Evaluation

Jev can evaluate multiple questions in the same request. However, each question is evaluated independently against the shared state.

This means one question does not receive another question's answer as additional context.

Consider an AI agent that needs to process a customer support ticket. You might want it to:

1. Identify the issue type.
2. Determine its severity.
3. Decide whether it needs human intervention.

You can ask all three questions in one request. But the severity question cannot use the answer from the issue classification question, and the escalation question cannot inspect the severity answer.

Each question evaluates the original state independently.

Why does this matter?

Suppose your application should escalate a ticket when its severity reaches the high-severity threshold.

You cannot assume that asking Jev to classify the issue and score its severity will automatically connect those answers. Instead, your application needs to combine the returned values and apply the escalation rule.

For example, if your Score scale defines 2 as the severe level:

# Example scale: 0 = minor, 1 = moderate, 2 = severe
if severity >= 2:
    escalate_to_human()

Here, the application makes the final decision using the returned score. If the scale allows values between defined levels, establish and test the threshold against representative examples before using it in production.

If a later question genuinely depends on an earlier answer, use a second request with the relevant result included in its state. Alternatively, combine independent answers in your application code when a second model evaluation is unnecessary.

The key principle is to separate evaluating individual questions from combining their answers into a workflow.

4. Designing Better Choice Questions

Choice is useful when you need to select one answer from a predefined set of options.

However, the quality of the result depends partly on how you define those options.

Consider this example:

{
  "type": "choice",
  "instructions": "What is the primary issue?",
  "criteria": {
    "billing": "Payment failures or duplicate charges",
    "technical": "Software bugs or application errors",
    "account": "Login or account access problems"
  }
}

What happens if a customer asks about a shipping delay?

None of these options fits the issue. Without a suitable fallback, the model may still select one of the available options, producing a misleading classification.

Include an "other" or "none" option

When your predefined choices might not cover every possible input, include a fallback option.

For example:

{
  "type": "choice",
  "instructions": "What is the primary issue?",
  "criteria": {
    "billing": "Payment failures or duplicate charges",
    "technical": "Software bugs or application errors",
    "account": "Login or account access problems",
    "other": "The issue does not fit any of the categories above"
  }
}

Now, the application has an option for issues that fall outside the expected categories.

This is especially useful when processing real-world data, where customer messages and other inputs may not always fit neatly into predefined classifications.

Make the options distinct

A fallback option is only one part of good question design. The other options should also be clearly distinguishable.

For example, if both billing and account include subscription problems, Jev may have difficulty distinguishing between them.

Define each option in terms of what it covers, and avoid unnecessary overlap. If two options represent different outcomes, their descriptions should make that difference clear.

Remember that Choice selects from the options you provide. It does not automatically expand the list when an unexpected case appears.

Wrapping Up

Working with Jev involves more than choosing between Choice, Score, and Noul. You also need to structure the state, define each question clearly, and understand how the answers relate to one another.

Keep these principles in mind:

• Provide the relevant context through a string, JSON object, or array of context items.
• Give every question clear instructions and the appropriate criteria.
• Treat questions in the same request as independent evaluations.
• Combine their answers in your application when a workflow requires multiple decisions.
• Include an other or none option when your Choice categories may not cover every case.

With these basics in place, you can build more controlled decision workflows around Jev while keeping the application logic under your control. Clear instructions and well-defined options can help, but they do not guarantee correct decisions. Evaluate your workflow against labelled examples before deployment, and continue monitoring its performance as real-world inputs change.

---

Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production reliable and secure without slowing you down.

I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.

Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.

Spend code review effort where business risk is highest — not spread evenly across every diff.

⭐ Star it on GitHub:

HexmosTech / LiveReview

Blast-Radius Aware AI Code Review for Business-Critical Systems

     

LiveReview: Risk-Aware AI Code Review for Business-Critical Systems

LiveReview is an AI code reviewer that scores every hunk of a diff by blast radius: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.

blast-radius-demo.mp4

LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.

The exact math, not a black box	Visualize blast radius at a glance	Every factor that feeds the score

How does Blast Radius scoring work? (a more technical explanation)

Here's the goal:

• A 3-line fix in a function used by 40 other files, that also writes to a database, should score high.
• A 300-line UI change in one file, fully covered by tests…

View on GitHub

Click below to try LiveReview with your codebase:

Comments

[DEV SUPPORTS]

You need to verify your account.

tr.ee/dev-to