How Jev Requests Work: State, Questions, and Probabilities

The API boundary is the product

Jev accepts evidence in a state field and a map of questions whose answer shapes are declared in advance. Instead of asking for a narrative and extracting a decision from it, the application receives structured results directly. That makes the call resemble a typed dependency: the caller knows the permitted categories or score levels, can validate the response without parsing prose, and can decide exactly which values are allowed to influence a branch.

This boundary also limits what Jev should be asked to do. It evaluates the state; it does not own the state, fetch missing records, decide which permissions apply, or execute a side effect. A clean integration gathers and normalizes evidence first, asks bounded questions second, and applies business rules last. That separation gives security reviewers and product owners visible places to inspect data access, model judgment, and policy.

Choose an answer shape your code already understands

The official documentation defines three primitives. Choice selects among a finite set and returns a distribution plus confidence. Score places evidence along an ordered rubric and returns a position with supporting probabilities and confidence. Noul estimates the probability that a statement is true. They are not cosmetic wrappers around the same hidden answer. Each creates a different output space and should map to a different kind of code path.

Work backward from the consuming function. A queue router naturally wants a Choice because its next step is an enum branch. A severity gate may want a Score if the application already uses ordered levels. A feature detector may want a Noul because the probability itself can become a model input or thresholded signal. If a team cannot describe what the returned number will do, it is not ready to choose the primitive or ship the call.

• Choice: a relative selection among declared alternatives.
• Score: an ordered judgment against levels you define.
• Noul: a probability for one true-or-false proposition.

Atomic questions keep policy inspectable

The documentation recommends questions that each ask one specific thing. “Should we approve this claim?” hides coverage, evidence quality, fraud risk, and exceptions in a single opaque judgment. Ask those dimensions separately and the model output becomes a feature vector. Code can then combine the features using rules or coefficients that are versioned, tested, and reviewable. A changed business priority becomes a code change rather than an attempt to rebalance a paragraph.

Atomic does not mean context-free. A question can point to named fields, define criteria, and distinguish important boundary cases. It should simply avoid asking the model to perform several independent judgments and silently choose how to weight them. If two teams would argue about the weighting rather than the evidence, the weighting belongs outside the model. This practice also improves debugging: when the final route is wrong, the team can see which component judgment moved it.

Parallel evaluation changes request design

TypeSafe says questions in one request are evaluated independently against the same state and produced in parallel. The architectural implication is to assemble related judgments around one stable evidence snapshot. A support request might request topic, urgency, sentiment, refund intent, and safety risk together, then let code use only the answers needed for the current branch. This avoids repeated transmission of the same state and reduces the chance that separate requests observe different versions of a record.

Independence is also a warning. One answer does not automatically condition another. If the application needs a second judgment based on the first, either encode the required evidence directly or run a later explicit stage. Do not assume question order creates reasoning. Likewise, asking both a proposition and its negation does not create a guaranteed invariant unless the API primitive itself enforces one. The surrounding program remains responsible for consistency checks.

Probabilities require a local operating policy

A probability is not a universal automation threshold. The cost of a false positive, the base rate of the event, and the availability of review all affect where a system should branch. A 0.8 refund-intent signal might be sufficient to prioritize a ticket but far too weak to issue money automatically. Start with labelled examples from the actual domain, divide them into development and evaluation sets, and measure outcomes across probability bands.

Calibration can also move with the model version or input distribution. Log the versioned model ID, retain the probability rather than only the winning label, and monitor segments separately. New languages, customer cohorts, or document templates can behave differently even when aggregate accuracy looks stable. Define a middle band for escalation, and make the fallback explicit enough to test without the model service available.

Migrate one decision seam at a time

A practical migration starts with an existing fuzzy rule or generative classifier that already has historical outcomes. Preserve the current route as a control. Build state from the same records, define the smallest questions that explain the decision, and run Jev in shadow mode. Compare its distributions with actual outcomes and with the incumbent system before letting it influence ordering or routing. Shadow data also exposes missing fields and ambiguous criteria without changing user-visible behavior.

When the evidence is good enough, enable a low-consequence branch for a small slice of traffic. Keep the deterministic rule for cases where it is truly sufficient. Jev is most useful where text or messy records defeat hand-written logic, not where a database comparison already produces the answer. The disciplined outcome is a hybrid system whose probabilistic seams are deliberate, observable, and replaceable.