Block and re-review calls with Judge and Jury

Add a Judge pre-check that stops an unsafe request before the model is called, and a Jury post-review that can approve, block, or regenerate the response before it returns.

This guide adds a Judge to a surface’s request path, so a clearly unsafe request never reaches the main model, and a Jury to its response path, so a problem visible only in the model’s own output is caught before the caller sees it. For how these two layers fit alongside Prompt Guard and Expert Witnesses, see Guardrails →.

Prompt Guard and Expert Witnesses catch known patterns and purpose-trained categories, but neither reasons about a request or a response as a whole. Without a Judge, a request that is unsafe only in context, rather than by pattern, reaches the model and incurs its cost. Without a Jury, a response that only becomes a problem once the model has answered, such as an unsafe recommendation the request itself did not signal, reaches the caller unreviewed.

Use this guide when:

  • You need a general reasoning check on a request before the cost of a model call is incurred, not just a purpose-trained classifier.
  • Some responses need a second opinion after the model answers, with the option to regenerate rather than only approve or block.
  • You are deploying a customer-facing surface where a single layer of content safety is not enough assurance.

You do not need Judge and Jury if Prompt Guard and Expert Witnesses already cover your risk profile; both add an extra model call’s worth of latency and cost to every request they run on.

Prerequisites

  • An active LLM Surface.
  • A provider, model, and endpoint the Judge and each juror can call. This can be the same model the surface already calls, or a separate, typically smaller and faster, model dedicated to review.
  • A secret storing the review model’s API key, if it is a different provider than the surface’s main upstream.

Steps

Add a Judge element to the request path

Under SURFACES in the dashboard sidebar, select LLM, open your surface, and add a Judge element to the canvas. The Judge runs in parallel with routing, so it adds no extra round-trip beyond the review call itself.

Choose the Judge’s moderation mode

The Judge element's Moderation Mode toggle, set to User-Defined LLM Judge

In the Moderation Mode toggle, choose Builtin Content Moderation to use the OpenAI Moderations API for a fixed set of content categories, or User-Defined LLM Judge to run a Chat Completions LLM against a custom system prompt.

For User-Defined LLM Judge, set the Judge LLM Provider target: Provider, Endpoint, Model, and API Key Secret.

Tune the Judge’s decision criteria

For an LLM-mode Judge, set Strictness Level (Strict, Balanced, or Lenient), any Focus Areas to emphasise, and a Confidence Threshold below which a reject decision is treated as an approval. Add Custom Instructions for domain-specific rules the generated system prompt should enforce.

For a builtin-mode Judge, select which Moderation Categories should trigger a rejection.

Set the Judge’s rejection response

Under Custom Rejection Response, set the Status Code (default 403), Response Body, and Content-Type returned when the Judge blocks a request. The provider is never called for a request the Judge rejects.

Add a Jury element to the response path

Add a Jury element to the canvas, on the response side. Set Execution mode: parallel (all jurors must approve), serial (stops on the first rejection), or majority (more than half must approve).

Add one or more jurors

The Jury element's Execution mode set to Parallel, alongside its Jurors roster with one juror added

Under Jurors, select Add juror for each reviewer. For each juror, set its LLM Configuration (Provider, Endpoint, Model, API Key Secret), its Decision Evaluation mode (json, the default, checks a named field against an expected value; regex checks the response text against a pattern), and the same Strictness Level / Focus Areas / Confidence Threshold / Custom Instructions controls as the Judge.

Configure a redrive policy

The Jury element's Redrive policy dropdown, open to show Return verdict immediately and the Redrive once/twice/three times with jury feedback options

In Redrive policy, choose how many times the Jury can send the model back to try again with the Jury’s feedback appended to the conversation, instead of rejecting outright on the first negative verdict: Return verdict immediately, or Redrive once/twice/three times with jury feedback.

Set the Jury’s final rejection response

Under Final negative-verdict response, set the HTTP status code (default 403), Response body, and Content-Type returned once every retry is exhausted and the Jury still rejects the response.

Save the surface

Select the save icon in the toolbar. The change applies immediately; no restart is required.

Confirm

Replace <YOUR_APPLIANCE_HOST> and <YOUR_SURFACE_ROUTE> with your surface’s values.

Test 1: a request that trips the Judge’s rules returns 403 (or your configured code), never the provider’s response

curl -k -X POST "https://<YOUR_APPLIANCE_HOST><YOUR_SURFACE_ROUTE>/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [
      { "role": "user", "content": "<a prompt that matches your configured Judge rule or moderation category>" }
    ]
  }'

The -k flag disables TLS certificate verification. Use this for local testing only. Remove it in production.

Expected: the status code and body configured under Custom Rejection Response on the Judge. Open the surface’s Monitoring tab and confirm no corresponding cost entry appears for the main model, since the Judge blocked the request before the provider was called.

Test 2: a request the Judge approves still returns 200 only after the Jury also approves it

Send an ordinary request that does not trip the Judge. Expected: 200 OK with the model’s response, after it has cleared every juror’s review. If a redrive policy is configured and a juror initially rejects, the response only returns after the configured number of retries or an approval, whichever comes first.

Troubleshooting

SymptomLikely causeFix
Every request is blocked by the Judge, even benign ones.Strictness Level is set too high for your use case, or Confidence Threshold is set too low.Re-open the Judge and lower strictness, or raise the confidence threshold so only high-confidence rejections trigger.
A reasoning model’s Judge or juror call runs out of tokens without producing a decision.The model is spending its token budget on chain-of-thought instead of the decision itself.Enable Disable Thinking (Judge) or Disable Thinking (juror) to suppress chain-of-thought for that call.
The Jury rejects a response, but the same answer returns unchanged after redrive.The Redrive Prompt Template does not clearly surface the Jury’s rejection reason to the model.Confirm the template includes the {reason} placeholder, or use the built-in default template.
A juror never seems to run.The juror’s Enabled switch is off.A disabled juror keeps its configuration but is skipped at runtime; re-enable it in the Jury’s roster.

Next steps

  • Guardrails reference: Every Judge and Jury field, including rule condition types and decision-evaluation modes.
  • OPA policies: Access-control decisions that run alongside these content guardrails.
  • Cost and usage governance: How Judge and Jury spend is metered separately from the main LLM call.