CMK Result Process Forward -Pipe-

CMK Result Process Forward -Pipe- is a one-input, one-output node that copies a PROCESS and retypes it as CMK_RESULT_PROCESS. Nothing else. No lazy loading, no cache, no side channel. It exists because of a rule in CMK's architecture rather than because forwarding is hard.

Why a dedicated node for this

CMK's boundary cache nodes deliberately do not have PROCESS in their input or output contract. That's a design decision with a reason behind it: the boundary's job is to publish one authoritative image artefact and let downstream consumers read it, and the moment a process pipe is in that surface, someone wires the stale version. The pack's own design guidelines say the process pipe is carried in parallel through the forward node rather than through the boundary - "der parallele Process-Forward-Node" - so the two wires travel side by side and the boundary stays a single-purpose node.

The visible consequence is that in the reference workflow you'll see two wires running alongside each other out of the generation zone: the image result through the boundary, and the process through this. The image pipeline's cache and the process metadata are then cacheable independently, which is exactly the argument the pack makes for IMAGE being its own line rather than living inside PROCESS - pixels and process state change at different rates and shouldn't share a fingerprint.

The type gate is the other half. The socket accepts any type (*) and outputs CMK_RESULT_PROCESS. That means a family-specific process can pass through it during composition while consumers downstream see the neutral type, and ComfyUI won't let a CMK_PROCESS_SDXL socket be wired into something expecting a neutral result directly. Useful when you're assembling or repairing a subgraph and the boundary's process routing has been untangled by hand.

Also note there's a sibling, CMK Z-Image Process Forward -Pipe-, which is the family-typed version used in the ZIT chain - designed to be resolved before the expensive image path so a cold subgraph execution doesn't leave downstream output nodes blocked. This node is the neutral one.

Inputs and outputs

• PROCESS (*, required) → PROCESS (CMK_RESULT_PROCESS).

It's a shallow validation and copy: anything that isn't a dict raises a clear TypeError ("requires a PROCESS dictionary") rather than dribbling a None further down the graph. That's the whole behaviour, and yes, you could replace it with a reroute in most graphs - but a reroute doesn't retype the socket, which is the part the architecture is enforcing.

Installing

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

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

The helper prints CMK dependency check: OK when the environment is right - that's the line to look for, especially on ComfyUI Desktop where several Pythons coexist. Model weights ship separately; the resources script audits them against your install.

One more thing you'll want before you go hunting for it in the search box: this node is registered DEV_ONLY, so it does not appear in the normal node search. It lives in the Developer bucket and is visible inside saved CMK workflows and subgraphs, which is where you'll actually meet it.