CMK SDXL Result Bridge -Pipe-

CMK's generation path is split into two incompatible process types on purpose - SDXL and Z-Image Turbo - and the merge back into shared modules is supposed to happen at one place only. CMK SDXL Result Bridge -Pipe- is the SDXL half of that merge: it declares an SDXL-only section finished and re-exposes the process as a family-neutral result that model-independent consumers can accept.

What it does, exactly

Input is PROCESS typed CMK_PROCESS_SDXL. The node checks three things - the value is a dict, model_family is sdxl, and nothing else - then copies the dict and stamps two keys onto the copy: result_contract: "family_neutral" and source_model_family: "sdxl". Output is that copy on a PROCESS socket typed CMK_PIPE.

The docstring is unusually direct about its role: "intentionally internal to the family-neutral finish module. Its input preserves editor-level family safety; its output is consumed only by model-independent result handling such as Save." That's the whole idea. The input type keeps you from wiring a Z-Image process in, which is the mistake worth preventing; the output type lets a save node - which genuinely doesn't care which model made the picture - receive the process without being taught about families.

Keeping source_model_family is what makes the rest work. The save module reads it (plus the inpaint flags) to decide the folder: a generated image lands under Text2Image or Inpaint, a pixel-based path under ImageProcessing. Strip the provenance and you get a save node that can't route anything.

This is one of a small family of adapters. The SDXL result bridge handles a raw SDXL process; CMK Result Bridge -Pipe- does the same job for a process that's already family-neutral, and CMK Result Process Forward -Pipe- just carries one along a parallel wire. If you're debugging a CMK workflow where something downstream says it can't accept the process, the first question is which of these three the graph put in front of it.

Inputs and outputs

• PROCESS (CMK_PROCESS_SDXL, required) → PROCESS (CMK_PIPE).

Wrong family gives you "CMK SDXL Result Bridge accepts only PROCESS SDXL", and a non-dict gives you a TypeError. Both are clear on purpose; there's no silent fallback.

Installing

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

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

CMK's Python requirements are heavier than a pure-plumbing pack's - ultralytics, insightface, onnxruntime, nudenet, segment-anything - because detection, face processing and the FaceSwap ContentGuard run on its own engines rather than borrowing Impact Pack. That's also why the pack claims it installs clean on a fresh ComfyUI without a chain of other custom-node packages. Weights are separate: python3 cmk_nodes/scripts/check_cmk_resources.py --models-root "/path/to/shared".

Two practical notes. It's a DEV_ONLY boundary node, so it won't turn up in the ordinary node search - it's meant to live inside saved workflows and subgraphs, displayed under the shared boundary runtime name. And it requires the Vue Nodes / Nodes 2.0 setting that CMK expects; on the legacy canvas the dynamic node behaviour degrades, which shows up first as dropdowns and shapes not rendering the way the shipped workflows assume.