WorkflowsOrchestration

Judgement Node

Ask yes/no, choice and score questions about a record and route on calibrated answers — three judges, confidence thresholds, and review paths.

Some decisions cannot be written as a rule. Whether a complaint is angry, which team owns a ticket, how severe a defect is: a Decision Table can route on those, but something has to answer them first. The Judgement node asks such questions about a record and returns an answer, a probability and a confidence for each one, in a shape the Decision Table and Choice nodes read directly.

Configure a Judgement on the canvas

Add the node and name it

Drag Judgement from the Logic group of the node palette onto the canvas and connect an edge from the node that produces the record — usually the Input node. Give it a short Name: later nodes read its outputs as $.<name>.output.decisions.<question>.

Choose the judge

Judge picks who answers. All three return the same outputs, so you can switch later without changing the nodes downstream.

JudgeHow it answersChoose it when
TypeSafe System OneAnswers every question in one call and returns calibrated probabilities from the model's own measurement.You want the numbers to mean something — thresholds, review gates, audit.
LLMAnswers against a JSON schema built from the questions.The judge needs world knowledge the questions cannot carry.
AgentThe same, but may use its tools first. The tool calls come back as evidence.The judge must look something up: an account, a policy, an earlier ticket.

All three nest a node inside this one. TypeSafe System One has no panel of its own, so its settings are edited from this one: the TypeSafe connection and Model here, and the System One timeout — seconds to wait for one answer, 30 when left empty — in the Error handling tab, beside the node's own Timeout, which bounds the whole run. jev-latest follows new releases, and pinning a version keeps tuned thresholds stable. LLM and Agent are picked or created, then Configure judge opens the node's own panel. Switching the judge drops the previous one, since its settings do not carry over.

The Judgement configuration panel with the Judge select set to TypeSafe System One, a connection, a model and three questions

screenshot: workflows-judgement-config-panel

Map the record

Under Inputs, add one input per part of the record the questions need — a ticket, a claim, a transcript — and map each from an upstream output. Leave the list empty to map a single value as the state instead, which is also how an agent passes one when it calls the node as a tool.

Send only what the questions need. System One accepts about 32,000 tokens of state per request and the node checks the size before it calls.

Write the questions

Under Questions, click Add question for each thing to decide. A question has an Answer type, a Name — the key the answer is published under, letters, digits and underscores — and Instructions saying what to judge.

Answer typeReturnsAlso configure
Yes or notrue or falseYes when and No when, the wording of each decision
One of several optionsthe option nameOptions: 2 to 255, each with a name and what belongs in it
A level on a scalethe level nameLevels, lowest first: 2 to 10, each with what belongs in it

Ask one specific thing per question and combine the answers downstream. Each row shows the answer type and a switch: an Off question stays in the list but is not asked.

A choice question open in the Judgement question editor with its name, instructions and three named options

screenshot: workflows-judgement-question-editor

Set the thresholds

Advanced configuration holds the settings that decide when an answer counts and when a person should look.

  • Yes threshold — the probability at or above which a yes/no answer is true. The default is 0.5. Raise it when a wrong yes is costly.
  • Minimum confidence — an answer below it is listed under low_confidence and sets needs_review. Leave it empty to never flag.
  • Probabilities — for an LLM or agent judge: The judge states its probabilities in one call, or Ask several times and count the answers, which costs one call per sample. Not available with System One, which already returns calibrated probabilities from one call.
  • Explain each answer — asks an LLM or agent judge what in the record decided each answer, returned under rationale.
  • The agent may ask its own questions — whether an agent using this node as a tool may add questions beyond the ones here.

The Advanced configuration section of the Judgement panel showing the yes threshold, minimum confidence and probabilities settings

screenshot: workflows-judgement-advanced

Route on the answers

Draw an edge to the node that acts on the judgement and map its inputs from this node's outputs. The variable picker lists a decision and a confidence per question alongside the node-level fields.

What the node returns

OutputTypeWhat it holds
decisionsobjectOne entry per question: true/false, an option name, or a level name. This is what you route on.
answersobjectThe full distribution per question, with probability, probabilities, score and confidence.
confidencenumberThe lowest confidence of any question.
needs_reviewbooleanTrue when any question fell below Minimum confidence.
low_confidencelistThe names of those questions.
contentstringThe answers as a short report, which is what an agent reads.
rationaleobjectPer question, when Explain each answer is on.
evidencelistThe tool calls an agent judge made before answering.
model, backend, confidence_source, usageWhich model answered, which judge, where the probabilities came from, and tokens with cost.

How confidence works

Confidence says how concentrated a distribution is, from 0 when every outcome is equally likely to 1 when one outcome takes everything. For n outcomes it is (n × max − 1) / (n − 1), and a yes/no answer is the two-outcome case, |2p − 1|. It is computed the same way whichever judge answered, so a threshold tuned on one judge still means something after you switch to another.

The node-level confidence is the lowest of the per-question confidences: one shaky answer pulls the whole judgement down, which is usually what you want before acting on it.

Sampling saturates with few samples. Three answers that agree give a confidence of 1.00 whether the question was easy or the judge was lucky, so use enough samples for the spread to mean something, or leave Probabilities on The judge states its probabilities.

Routing with a Choice node

A Choice node takes one condition per branch. A yes/no decision is a boolean, a choice and a level are strings, and confidence is a number, so each takes the matching operator.

BranchCondition
Needs a person$.needs_review is true
Angry billing$.decisions.angry is true and $.decisions.team equals billing
Critical$.decisions.severity equals critical
Unsure$.confidence is less than 0.9

Put the review branch first: under the default First matching branch hit policy the branches are evaluated in order and the rest are skipped once one matches, so a record that needs a person never falls into a routing branch below it.

Routing with a Decision Table

Once there are more than a handful of rules, a Decision Table reads better than a chain of branches. Map each decision to a typed input column and let the rows combine them:

#Rulereviewangryteamseverityqueuepriority
1Unsuretruehuman-reviewhigh
2Criticalcriticalescalationhigh
3Angry billingtruebillingbillinghigh
4Billingbillingbillingnormal
5Otherwisegenerallow

Map review from $.<name>.output.needs_review, and angry, team and severity from $.<name>.output.decisions.angry, .team and .severity — the same three decisions the Choice conditions above read.

As an agent tool

Give the node to an Agent as a tool and it reads content, the short report. Unless The agent may ask its own questions is off, the agent may add questions of its own at call time; they are merged with the configured ones by name. Use it to hold an agent to a fixed rubric instead of asking it to judge in prose.

Pitfalls

On this page