Skip to main content
Jev reads; NSR applies policy and produces the decision evidence. Jev supplies typed, probabilistic readings of text. NSR combines those readings with facts, evidence requirements, and explicit rules to return approved, denied, or refused. A model reading does not by itself authorize a business action.
This guide reflects the latest local implementation in stateset-nsr and nsr-app, including work not yet committed in those repositories when reviewed. Availability depends on the deployed console and engine. Check capabilities before relying on a new surface; example fixtures are not evidence of a successful live Jev call.

​
Choose your starting point

Try a public scenario

Inspect a fixed industry policy, use your Jev key for one explicit run, and read the outcome.

Connect your organization

Save a Jev connection, work in the Playground, and preserve policy tests and results.

​
How a decision is built

READTyped judgments

Jev answers narrow questions about the supplied message or context.

EVALUATEEvidence and policy

NSR checks admitted evidence, rule premises, thresholds, and the authorization goal.

INSPECTDecision and proof

Your application reads the outcome, review requirements, and returned evidence before acting.

For a refund example, Jev can assess whether a complaint describes plausible transit damage. The policy still checks authoritative order values, the refund cap, and other required premises. A plausible complaint can therefore be refused or denied under the policy. Keep numeric limits and authorization conditions in explicit rules rather than asking the model to authorize a refund.

​
Typed readings become policy premises

A reading becomes a predicate such as complaint_plausible(order_id, p). A rule can then require geq(p, 0.8). The threshold is a policy condition, not an unconditional claim about model accuracy. A low fraud probability can be a confident “no”; it must not be interpreted as a low-confidence approval merely because its numeric value is small. Inspect evidence admission as well as the reading. Source labels and model provenance do not prove that every claim was accepted or that a real-world source is truthful. A derivation establishes a result relative to the supplied policy and admitted premises.

​
Explicit questions and recursive questions

The decision request can include: With recursive questions, NSR evaluates known premises, identifies missing declared judgments, asks those questions, and evaluates again. It also checks unanswered guards in deny/review rules and negated conditions. An apparent approval must not bypass an unanswered blocking guard; if the bound is reached with unresolved guards, inspect the refusal and human-review requirement. Judgments can include paraphrases and, for noul, a complement question. The implementation aggregates readings and caps confidence by their agreement. This is an additional consistency check, not a guarantee against adversarial inputs. Organization judgment templates can live with the policy. Request-level templates can override the corresponding organization entry; review this behavior when designing trusted callers.

​
Read the result before taking action

Inspect the returned fields that are available for your request:
  • decision: the engine verdict, not a model suggestion.
  • judgments: resolved model, readings, generated facts, agreement, rounds, and usage evidence.
  • evidence: admitted or rejected evidence and any human-review requirement.
  • proof: cited rules, derivation, and policy identifiers or pins when returned.
  • routing: the suggested operating band, including escalation.
  • refusal: missing premises or reasons the engine could not establish permission.
Treat routing.band: "escalate", evidence.requires_human_review, or refusal.requires_human_review as review signals. A successful HTTP response can contain a refusal. Do not rewrite a message, weaken a threshold, or invent a fact to force approval. The public Jev demo executes no business action. Production execution is a separate integration: use the agent gate and bind the authorized operation to its execution and outcome evidence. Approval alone is not proof that a refund or another provider action occurred.

​
Compare, verify, and learn carefully

A fresh Jev call can produce a different reading. Distinguish: A matching test verdict is not proof verification. Re-running inputs is not reproduction of an original model reading. Evidence-aware runs need their supported engine derivation/verification bundle; the console’s basic browser proof replay does not validate those runs. The engine also has judgment calibration, outcome analysis, and reviewed policy-threshold adoption surfaces. Keep observed outcomes separate from model confidence and require review of proposed policy changes. These mechanisms do not train a new Jev model on your data. Related: Verified Decisions, NSR console, and first symbolic decision. Source basis: stateset-nsr/docs/JEV_INTEGRATION.md, recursive decision handlers, src/api/jev_credentials.rs, and the Jev/Playground implementation in nsr-app, reviewed 2026-09-20. No new live-provider accuracy or latency measurements were performed for this guide.
Last modified on September 20, 2026