Call Jev Decision 🐑

What it is

CallJevDecision is the node that turns a decision model into something a workflow can act on. You give it a piece of state - a scene description, a dialogue line, a customer message, whatever text you're judging - and a JSON description of the questions you want answered about it. It returns the answers as JSON.

That's the whole trick, and it's why this is more interesting than "another LLM node." A chat model asked "is this urgent?" writes you a paragraph. A decision model answers with a probability. That's a different object: something you can threshold without a regex, and something whose confidence you can inspect when it's wrong.

Be honest about the state of the ecosystem here, though: this integration is young and the models behind it are the open replicas of a research-pointing decision architecture, not a decade-old API. There is no reddit thread corpus for it. It's a neat, cheap thing to try for routing and triage; don't architect a production pipeline around it on day one.

How it works

The node takes the connector, parses questions_json into a dict of question-name → spec, and calls the connector's ask(state, questions) method. Three question types exist:

• noul - yes/no, returned as a probability
• choice - a picked option plus the full probability distribution across your criteria
• score - a position on an ordered scale, plus per-level probabilities

The raw response comes back as {model, answers, usage}, and the node dumps all of it to the output as pretty-printed JSON. You then read answers.<name> for whatever you asked, and route on it.

The connector must be the decision one: wire anything else in and the node refuses with "CallJevDecision needs a Jev connector from the SetSiliconFlowJevLLMServiceConnector node (got a chat connector)." That's a better failure than a silent wrong answer, and it's deliberate.

Validation is strict, also deliberately: questions_json has to parse as JSON, and it has to be a non-empty object. Malformed JSON gets you an explicit error naming the parse problem; an empty object gets you an explicit error pointing at the expected shape. Neither silently passes empty questions to the model.

The inputs, and the shape of questions_json

Three inputs, no optional ones.

llm_service_connector - from SetSiliconFlowJevLLMServiceConnector-Mie.

state - the text being judged. A dialogue line, a scene summary, an email.

questions_json - the question spec, as a JSON object mapping names to specs:

{
  "urgency":  {"type": "noul",
               "instructions": "Does this message express urgency?"},
  "topic":    {"type": "choice",
               "instructions": "Classify the inquiry",
               "criteria": {"billing": "Refunds, payments",
                            "technical": "Defects, troubleshooting"}},
  "severity": {"type": "score",
               "instructions": "How severe is the issue?",
               "criteria": ["Low", "Medium", "High"]}
}

choice takes a criteria map of option → meaning; score takes an ordered criteria list. The instructions string is your question in plain language - write it like you'd say it out loud, not like a schema.

Output: decision_json, a STRING containing the whole response - model name, the answers object with probabilities, and token usage. Drop it into the pack's ShowAnythingMie node while you're developing a question set; being able to read a probability distribution is the entire reason to use this over a chat model, and you can't route on what you can't see. Then parse answers.<name> for the actual decision.

Installing it

It ships with the pack: no models, no GPU, nothing to download.

cd ComfyUI/custom_nodes
git clone https://github.com/MieMieeeee/ComfyUI-MieNodes
cd ComfyUI-MieNodes && python -m pip install -r requirements.txt

Restart ComfyUI, or search ComfyUI_MieNodes in Manager. Put your SiliconFlow key in mie_llm_keys.json under "siliconflow" - the Jev connector reuses it, so if you already use SiliconFlow's chat tier you're done. Remember that prefer_local_config defaults to True, so the file beats the node's api_token field.

Common issues

"questions_json is not valid JSON." Almost always a trailing comma or single quotes. Paste it into any JSON linter before blaming the node - the error message even tells you the parse position.

"…got a chat connector." You wired the SiliconFlow chat connector. This node needs the Jev one; they look nearly identical in the node menu and only the display name distinguishes them.

Answers that don't match your criteria. The node forwards your spec verbatim; if your choice criteria aren't mutually exclusive, the distribution will be split across them and the pick will be arbitrary. Good question text is the whole quality lever here - the same lesson as prompt engineering generally, just pointed at a classifier instead of a sampler.

Everything scores in the middle. A score question with no anchors gives you mush. Give the criteria labels that mean something concrete ("Low: cosmetic, cosmetic only" beats "Low").