How to use the Jev playground

The fastest way to understand Jev is to test one bounded decision. TypeSafe's console is the official starting point for account access and interactive exploration. The exact console screens and access terms may change while Jev is new, so use this guide for the decision design and follow the live interface for current controls.

1. Start with a decision, not a prompt

Choose a task with a known answer space. Support-ticket routing works well because the legal outcomes can be named in advance:

• billing;
• technical;
• account;
• other.

Avoid starting with “analyze this message” or “tell me what to do.” Those are open-ended requests. Jev is designed to answer typed questions that application code can use.

2. Supply realistic state

The state is the information Jev evaluates. Begin with a short example that resembles the real input:

I was charged twice for order A-104. Please refund the duplicate charge.

Later, test structured state containing separate fields such as the customer message, order record, and refund policy. Naming the fields makes it easier for a question to say exactly what evidence it should judge.

3. Pick the right question type

TypeSafe documents three primitives:

• Choice for one answer from a set, such as the destination queue.
• Score for ordered levels, such as urgency or severity.
• Noul for the probability that a yes-or-no statement is true.

For the sample ticket, begin with a Choice question: “Which queue should receive this case?” Define every option clearly and include other when the list may not cover every input.

Then add a Noul question such as “Is the customer explicitly requesting a refund?” See the Noul guide for threshold design.

4. Read the whole result

Do not look only at the selected label. For a Choice answer, inspect the probability assigned to every option and the returned confidence. A narrow win between billing and account should not be treated like an obvious billing case.

For Noul, the single number is the yes probability. A value near 0.5 is uncertain; it is not a medium-strength yes.

Ask three questions after each run:

1. Is the selected answer reasonable?
2. Is the probability distribution consistent with how ambiguous the input is?
3. What should the application do when the result is not clear enough?

5. Try adversarial and ambiguous examples

A successful demo proves very little if every example is easy. Change the state and test cases such as:

• “What payment methods do you accept?” — a pricing question, not a billing dispute.
• “The app is broken and I cannot see my invoice.” — contains technical and billing signals.
• “Help.” — insufficient context.
• A message that fits none of the named queues.

If the answer space is incomplete, fix the Choice options. If the boundary is vague, improve the criteria. If a case is genuinely uncertain, keep that uncertainty in the workflow rather than prompting it away.

6. Turn the experiment into an evaluation set

Save a small set of representative inputs with the answer a knowledgeable reviewer expects. Include clear positives, clear negatives, edge cases, and inputs where reviewers disagree.

Run the same set after changing instructions, criteria, model version, or provider. Measure both correctness and coverage: the share of cases that clear your automation threshold. A threshold that looks accurate because it sends nearly everything to review is not necessarily useful.

7. Move to code only after the contract is clear

Once the question and decision policy behave sensibly, implement them using the current TypeSafe quickstart or a verified provider route from the Jev API access guide.

Keep the same state, question IDs, option definitions, and review thresholds you evaluated. Pin the model and endpoint used by the test. Then run a shadow period in which Jev records a proposed decision without changing the live action.

Common playground mistakes

• Testing only one happy-path input.
• Asking a broad reasoning task instead of one snap judgment.
• Omitting other from a Choice that is not exhaustive.
• Treating the top option as safe without checking its margin.
• Using Noul as a severity scale.
• Copying a playground result into production without a labeled evaluation set.

The playground is not the product. Its job is to help you define a stable typed contract and discover where uncertainty belongs before the model is allowed to affect a real workflow.