Organising a Pony-compatible ComfyUI graph without hidden dependencies
A readable graph makes it possible to identify which checkpoint, conditioning and latent reach the sampler. For a Pony-compatible workflow, begin with the model author's working example and organise its dependencies before adding routing conveniences or changing sampling behaviour.
Map the data rather than the canvas
Create a small inventory of the graph's inputs and outputs: model, text-conditioning branches, initial latent, decoded image and saved file. Label where each is produced and where it is consumed. A tidy canvas with an incorrect connection remains an incorrect workflow; visual compactness is not evidence of lower memory use.
Record the actual model family from its model card. Do not infer compatibility from a filename containing Pony or XL alone. Keep the working baseline intact while organising a duplicate so that a changed connection can be traced back to a known result.
Expose a useful module boundary
ComfyUI subgraphs provide a documented way to group a workflow behind an input/output interface. Choose a boundary such as conditioning preparation or final image processing, rather than hiding every node in one large container. Expose the values a reader must adjust and name them for their actual role.
Keep model identity and important sampling parameters discoverable. If a module contains a default that changes the output, document it alongside the exposed controls. Reopen the internal graph during review; the wrapper should simplify navigation, not prevent inspection.
Use switches deliberately
The rgthree repository documents Any Switch as choosing the first nonempty input. That is not a semantic quality selector and does not automatically identify the intended model. Arrange inputs explicitly and test each branch with a distinguishable result so the selected route is observable.
Avoid treating an optional extension as a native ComfyUI feature. Record its repository and revision, and preserve a simpler fallback graph if portability matters. Wireless-looking routing or shorter connection lines do not by themselves establish different execution costs.
Verify the reorganised graph
Compare the baseline and reorganised version with unchanged inputs and environment. Inspect both successful outputs and the graph's selected components. If results differ, reduce the comparison to one module boundary and inspect the values that cross it. Keep a written explanation of intentional differences.
This revision does not endorse an undocumented sigma trick or a universal guidance value. Use the model's maintained sampling example, then test any departure as a separate experiment. A useful architecture is one another person can inspect and reproduce, not one that conceals unsupported optimisation claims behind elaborate node names.