Nodes/Qwen2.5-VL GGUF Nodes/✅ JSON Result Validator
ComfyUI Node

✅ JSON Result Validator

Stop trusting VLM JSON with your life — check it instead

By walke2019·Created 11 months ago·Updated about a month ago· 32
✅ JSON Result Validator
    • valid
    • normalized_json
    • error
    json_text{}
    required_fieldssubject,tags

    Vision models are getting better at JSON output, but "better" is doing a lot of work. Every structured-output workflow eventually hits the model that wraps its JSON in a Markdown code block, omits a field it was told was mandatory, or returns prose when you asked for a parseable object. JSON Result Validator is the pack's reality check: it takes whatever text your VLM produced, tries to parse it as JSON, and tells you exactly what's wrong.

    It's a pure validation node - no model, no network. You feed it the results_json or result output of a VLM task and a list of required top-level fields, and it returns three things: a valid BOOLEAN, a pretty-printed normalized_json STRING, and an error STRING. That BOOLEAN is the useful part: wire it into a conditional/switch node and you can automatically retry, fall back to a different model, or route the batch row to a human-review pile when the VLM mangles its output.

    The two inputs

    • json_text - the raw VLM output. Comes straight off Remote VLM Business Task's results_json, or a JSON task's output.
    • required_fields - a comma-separated list of top-level keys you expect, e.g. subject,tags. The validator checks that each one exists at the top level of the parsed object.

    Under the hood (utils/json_schema_tools.py) it parses with the standard json library, collects any missing fields, and reports them. Invalid JSON gives you a clear "Invalid JSON: …" error; missing keys give "Missing fields: subject". Normalized JSON comes back indented, so you can eyeball it in a text node or pipe it downstream cleanly.

    Where this earns its keep

    In a batch workflow, one malformed row can poison the whole run - especially if you're feeding VLM output into another step that assumes valid JSON. This validator lets you detect rather than discover. Batch Remote VLM Task already per-item isolates failures, but it can't tell you the JSON is semantically wrong, only that a request failed. This node catches the "valid request, garbage structure" case.

    The honest limitation: it checks top-level field presence, not types or values. A model that emits "tags": "oops not an array" passes if tags exists. If you need strict schema validation, you'll want a dedicated JSON tool downstream - this node is the cheap gate, not the full inspection.

    Install

    Same as every node in this pack:

    cd ComfyUI/custom_nodes
    git clone https://github.com/walke2019/ComfyUI-GGUF-VLM.git
    cd ComfyUI-GGUF-VLM
    pip install -r requirements.txt
    

    Restart ComfyUI. It's under GGUF-VLM → 🚀 Business. No model downloads needed for this one.

    Troubleshooting

    The most common confusion is feeding it the wrong thing: the VLM's task runners output pretty-printed JSON from a "JSON" task, but if you chose "Custom" and your prompt didn't actually demand JSON, you'll feed it prose and get a perpetual valid: false. That's the validator doing its job - your prompt is the problem, not the node. And remember the builder nodes exist: the JSON prompt template in this pack explicitly forbids Markdown code blocks, which is the single most common way VLM "JSON" comes back unparseable.

    Category🤖 GGUF-VLM/🚀 Business

    Inputs (2)

    NameTypeDefaultDescription
    json_textSTRING{}
    required_fieldsSTRINGsubject,tags

    Outputs (3)

    NameTypeDescription
    validBOOLEAN
    normalized_jsonSTRING
    errorSTRING