Supernode Module (cascade contract + linx)

The module that turns one giant node into a stack of smaller ones

The IAMCCS SuperNodes are the author's answer to LTX video spaghetti: instead of a hundred-frame graph with frame math scattered across half the canvas, you get a wrapper node that compresses a whole pipeline stage. But a single mega-node is its own problem - you can't peek inside, can't rearrange, and if one widget is wrong the whole thing collapses. This node splits the difference. It's the building block the SuperNodes system is assembled from: a module you declare, label, and slot into a chain, with a typed contract object carrying state forward.

Think of it as a named stage in a pipeline that knows exactly what role it plays. You tell it what kind of pipeline it belongs to, what job it does, and how it relates to the module before it. The contract wires do the rest.

The inputs that define a module

Three things actually matter:

• pipeline_kind - what you're building. The list is long: v2v, i2v_flf, au_img2vid, img2vid_pure, t2v_pure, t_audio2vid, loop_img2vid, loop_t2v, audio_concat, wan_flf, wan_continuity. Each selects the family of behaviors the module will plug into.
• module_role - the job: planner, backend, continuity, audio, concat, loop, second_stage, output, or custom.
• module_mode - how it treats what's upstream: consume (take the contract and use it), augment (extend it, the default), or branch (fork without disturbing the main chain).

node_label and module_key are your naming: one for what you see on the canvas, one for how the module is addressed in the contract. That's important in a graph with ten modules - a readable label is what keeps the "which stage is this again" moment from happening.

On the optional side you get parent_contract and linx (the contract types from upstream modules), a free-form payload string, and six wildcard module_01 through module_06 inputs for whatever data that stage needs - an image, a prompt, a latent, anything.

Outputs

Three: contract (the IAMCCS_SUPERNODE_CONTRACT that the next module consumes), linx (the IAMCCS_SUPERNODE_LINX threading object), and report (a string you can read to see what the module decided). The contract/linx pair is the whole trick: instead of state living in wires that ComfyUI re-validates, the pipeline state rides inside these typed objects.

Installing and using it

It ships with IAMCCS-nodes, so it's the pack install again - ComfyUI Manager (search "IAMCCS") or:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

Restart, then find it under IAMCCS/Supernodes.

Be honest about what this is: if you're not building or customizing an IAMCCS SuperNode workflow, this node is inert on its own - it produces contract objects, not video. It exists to be consumed by the sibling planner/backend/render stages and by the author's downloadable workflows. The practical path for most people is to grab one of those workflows and tweak a module here and there, not to construct a pipeline from scratch. When you do, the value is obvious: a stage you can reason about, name, and swap without rewriting the graph.