DOGMAGenerativeCategoryPromptV54
DOGMAGenerativeCategoryPromptV54
- kind
- prompt
- info
This node has three outputs and only one of them is the prompt. The other one is kind, and in any v54-or-later DOGMA workflow, kind is the wire that decides how big the mask grows, how the crops get grouped, and how hard the detail pass is allowed to push. Miss it and half the graph reads as mysterious.
Feed it a category and a bit of project context; get back a preserve-first instruction and a classification. It's the least glamorous node in the pack and the one that silently governs everything downstream.
What it is
Earlier in DOGMA's life, category prompts were presets - one hand-written paragraph per family, selected by a dropdown (DOGMAFixedCategoryPromptV37 is that generation). That breaks the moment your scene contains something the author didn't anticipate. This node replaces the dropdown with a category string, which arrives from a planner that read your image, and builds the prompt from the category's family at runtime.
It's the same idea as grounding a mask from a VLM: qwen3-vl names the thing, and the segmenter finds it. Here the VLM names the thing and this node decides how to touch it.
How it works
Internally it maps the category string to a family - vehicles, people, architecture, road, vegetation, street objects, water, sky, animals, furniture, clothing, machinery, food, or none - and reads a hard-coded, very long preservation paragraph for that family. Vehicles: preserve count, identity, body type, silhouette, colour, windows, wheels, trim, lettering, position, perspective, spacing and occlusion; "never invent, replace, recolor or modernize a vehicle." Buildings get style-locked ("glass curtain-wall remains glass curtain-wall; modernist remains modernist") and are explicitly forbidden from having floors or windows added. Sky is forbidden from turning haze into buildings, poles or aircraft - a nice tell of whose failure modes this was written against.
Then it derives kind from the same family: architecture becomes STRUCTURE, road/vegetation/water/sky become SURFACE, and everything else is OBJECT. That three-way split is what DOGMAInpaintMaskV543 reads to size its morphological closing, and what the instance-chunk crop nodes read to decide how aggressively objects may be grouped. STRUCTURE gets a bigger close and a smaller per-chunk object budget; SURFACE gets a wider grouping gap still, because you do not want to cut a building or a lawn in half to satisfy a crop size.
project_context is added only for the families where it can do something useful - vehicles, people, clothing, street objects - and with a fence around it: context constrains the appearance of already-visible details, and it is never permission to add an object. That sentence is doing real work. The single most common way a "restore this 1950s street" workflow ruins an image is by hallucinating period-appropriate content into it.
Inputs and outputs
Two inputs. category is a STRING and it's a forced input - you wire it, you don't type it, usually from a planner's category_i. project_context is a multiline STRING in the same shape: it comes off a VLM barrier or a text node carrying your period/setting description.
Three outputs. kind (STRING, one of OBJECT / STRUCTURE / SURFACE) goes to the mask and crop nodes. prompt (STRING) goes to your Klein conditioning. info (STRING) is the receipt - the category, the family it resolved to, and the kind, which is genuinely useful when a category you invented lands in the generic branch.
Unknown categories don't error; they fall through to a generic preserve-first paragraph. That's usually right, and it's worth knowing so you don't hunt for a bug that isn't there.
Install
ComfyUI Manager → search DOGMA Nodes (publisher axior), install, restart. Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/axior/ComfyUI-DOGMA-Nodes
# restart ComfyUI
Nothing to pip install - the pack is pure torch and ComfyUI built-ins - and the repo carries no weights. This node in particular needs nothing beyond ComfyUI: it's a string builder. Whatever wants a VLM to supply the category is a different node, and that's where the Qwen3-VL download lands.
Common issues
The trap is dropping this into a v39 workflow. Nodes with a kind input exist across several generations of this pipeline (DOGMAInpaintMaskV543 is v54.4.1, the instance-chunk crops run v54.1/54.2/54.5) and they do not care where kind came from - but a v39-era graph was built around adaptive settings derived from category/kind elsewhere, and mixing generations produces a workflow where the mask and the crops disagree about what they're protecting. Keep one version family per graph where you can.
Second: category strings are matched loosely, so old cars and car may land in different families. When a result looks like it ignored your instruction, read the info output first and check which family it actually resolved to - that's what the generic fallback paragraph is and it is much less specific than the vehicle one.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| category | STRING | — | |
| project_context | STRING | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| kind | STRING | — |
| prompt | STRING | — |
| info | STRING | — |