The outcome

Catch unsupported claims, policy violations and injected instructions before an LLM response reaches a user or a tool.

Step by step

A workflow you can repeat.

  1. 01

    Decide the exact conditions that should block a response and write each one as a single literal yes/no statement — "The reply promises a refund the policy does not allow" — never a bundle of several judgments in one question.

  2. 02

    Build the state from the pieces the check needs and nothing else: the user's message, the LLM's draft reply, and the relevant policy excerpt, each under its own key so the question can name it.

  3. 03

    Ask every guardrail as a separate Noul in one request, add a Score for severity where a violation has degrees, and set the criteria true and false descriptions so the model knows precisely what a yes means.

  4. 04

    Pick a probability threshold per check in code — a refund-promise check might block at 0.6, a sensitive-data check at 0.3 — and route blocked responses to regeneration, a template fallback, or a human, logging the noul value each time.

  5. 05

    Test with a set of adversarial inputs, including prompt-injection attempts that argue for their own classification, because Jev treats state as data and can be steered by text written to move the answer.

Working standard

What good use looks like.

  • One condition per Noul.
  • Thresholds live in code, tuned per risk.
  • Keep an adversarial test set and rerun it on every model change.

Official references

Check the current product documentation.