CMK Result Pack -Pipe-

If you've poked inside a CMK Flow subgraph and found a node whose whole job is to take four inputs and spit out the same four things with new type names, you're not looking at a bug. CMK Result Pack -Pipe- is the public seam of the family-neutral result contract, and it exists because CMK's generation path is mechanically split into SDXL and Z-Image Turbo and has to merge back into one chain of post-processing modules.

Why it exists

CMK keeps two incompatible process types alive at once: CMK_PROCESS_SDXL and CMK_PROCESS_Z_IMAGE. The separation is deliberately nominal - ComfyUI should not let you wire an SDXL module's output into a Z-Image module even if the underlying Python dicts look similar. The only sanctioned crossing point is the PostProcess Boundary, which ends the family-dependent section and hands over CMK_RESULT_MODEL, CMK_RESULT_PROCESS, CMK_RESULT_IMAGE and CMK_RESULT_LOG. Those four neutral types are the only legal feed into the shared modules - FaceSwap and the upscale/save finish - when both families are built out in parallel.

So the pack is the other side of the same door: it takes an existing neutral result and re-presents it under the four neutral socket types, which is what you need when you're building or editing a subgraph and want its public interface to look right rather than to be a bundle of loose typed wires. It's the pattern the plumbing layer calls the context object - one wire instead of forty - applied at a module boundary rather than inside a workflow.

Inputs and outputs, precisely

Everything here is optional, which reads oddly until you see what's being validated:

• MODEL (opt) - the post-process working model. Optional; pass None and it flows through as None.
• PROCESS - required in practice. It must be a CMK process carrying the family-neutral result contract, or the node raises rather than guessing.
• IMAGE and LOG - both genuinely required. A missing image or a non-dict log is a hard error, because an incomplete result is exactly the state this node exists to prevent.

Outputs are MODEL, PROCESS, IMAGE, LOG as CMK_RESULT_MODEL / CMK_RESULT_PROCESS / CMK_RESULT_IMAGE / CMK_RESULT_LOG. The PROCESS copy is handed on under the same family-neutral framing, and source_model_family keeps the generation provenance intact - which matters downstream, because the save module reads it to decide whether your file lands under Text2Image, Inpaint or ImageProcessing.

If you're going the other way - neutral result back into loose wires - that's CMK Result Unpack -Pipe-, and the two are designed as a pair.

Installing

ComfyUI Manager: search CMK Flow, install the CMKFlow entry, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/CMKFlow/cmk_nodes.git cmk_nodes
python3 cmk_nodes/scripts/install_cmk_requirements.py

Then python3 cmk_nodes/scripts/check_cmk_resources.py --models-root "/path/to/shared/models" for the weights the shipped workflows want. Requirements are heavy (ultralytics, insightface, onnxruntime, nudenet, segment-anything) because CMK ships its own detection and face engines instead of depending on Impact Pack.

The thing that will confuse you first

Boundary and cache nodes are registered with DEV_ONLY = True. They stay fully functional inside saved workflows and subgraphs, but they don't show up in the normal node search - the pack's design guidelines say so explicitly, and they all display under the same runtime name so a status readout doesn't imply a processing step that didn't happen. Search for "CMK Result Pack" in an empty canvas and you may find nothing; open a shipped CMK workflow and there it is. That's expected, not a broken install.

Second gotcha: this node is strict on purpose. Feeding it a raw SDXL or Z-Image PROCESS that hasn't been through the boundary will throw a clear error instead of quietly working - which is the entire point, because the alternative is discovering three modules later that your post-processing ran on the inactive family's branch.