Graph Organization · Groups & Naming Standard — making a large workflow readable
A large production workflow should be readable at three scales: the full canvas, a functional module, and an individual node chain. Groups and a naming standard turn visual layout into navigation, a control API, and documentation at the same time.
A group is not a colored frame — it is part of the workflow architecture
If a group is used only as visual decoration, it does not help anyone read or maintain the graph. In a production workflow, a group name should answer two questions immediately: what responsibility does this area have, and where does it sit in the overall route?
Good group architecture reduces cognitive load. Instead of hundreds of nodes, the user first sees 10–15 systems, then opens the relevant module, and only then reads the local chain.
A consistent order for the main production groups
Why use numeric prefixes
A prefix fixes the intended reading order and keeps group sorting predictable even on a large canvas.
| Prefix | Group | Responsibility |
|---|---|---|
| 00 | BASE CONFIG | Global availability / bypass logic and run modes |
| 01 | MODEL LOADERS | Models, CLIP, VAE and heavy shared resources |
| 02 | INPUTS | Base render, maps, references, logo and external data |
| 03 | CONTROL | Shared values, selectors, seed, size and mode controls |
| 04 | PREPROCESS | Depth, Canny, resize and detection preparation |
| 05 | BASE GENERATION | SDXL / FLUX base generation or img2img stage |
| 06 | MASKS | Segmentation, protection masks and local edit regions |
| 07 | PEOPLE / PPL | Generation / replacement / compositing of people |
| 08 | LOCAL REFINE | Detail transfer, inpaint and local polish |
| 09 | UPSCALE | High-resolution / final polish path |
| 10 | OUTPUT | Preview, save and delivery outputs |
Inside a module, use the same principle: stage number + responsibility
A name should describe function, not editing history. Labels such as FINAL2, TEST_NEW and COPY3 are not architectural names; they quickly turn the canvas into an archive of accidental states.
Group names participate in control through Fast Groups Bypasser
Fast Groups Bypasser discovers groups automatically and builds toggle rows from their titles. Its properties can filter groups with matchTitle, limit them by color, and sort them by position, alphanumeric order or a custom alphabet.
That makes the group title part of the control plane. Renaming a group can change whether it is included by a BASE CONFIG filter, while unstable names make workflow control fragile.
rgthree behavior
Fast Groups Bypasser uses the group title as the widget label and supports matchTitle, sorting and a custom alphabet.
Production rule
When BASE CONFIG relies on title matching, production group names should be treated as interface identifiers and changed deliberately.
Group boundaries should match responsibility boundaries
- Do not stretch one group across half the canvas merely for visual coverage.
- Do not place a shared loader inside a local module when several branches depend on it.
- Do not hide a return point inside a neighboring group.
- Avoid overlapping production groups without a clear reason: one node should not accidentally belong to multiple control regions.
- Place the checkpoint inside the module before RETURN, not far away in OUTPUT.
Overlap risk
rgthree explicitly warns that overlapping groups can create states that violate max-one / always-one constraints.
Color helps orientation, but it does not replace a name
Color is useful as a secondary visual code: loaders, controls, masks, generation and output can use different palette families. But the meaning of a group should remain clear from its text title even without color.
This matters when a workflow is handed to someone else, when the UI theme changes, and when BASE CONFIG uses matchTitle.
Names we do not allow in the production master
| Anti-pattern | Why it fails | Use instead |
|---|---|---|
| final / final2 / final_final | Does not describe function and becomes obsolete quickly | 09 · UPSCALE / 10 · OUTPUT |
| test / new / copy | Does not say what is being tested | LAB · CANNY STRENGTH TEST |
| group 17 | No semantic responsibility | 06 · MASKS · FOLIAGE |
| PPL stuff | Combines several stages under one vague label | PPL · 02 DETECT / PPL · 03 SEGMENT |
| one giant group | Hides module boundaries | Split by contracts and return points |
A naming formula that scales to any future module
Practice: read the Hansen workflow using groups only
- Work on a copy of the workflow; keep the Hansen Original as an immutable reference.
- Hide the details first and list only the names of the major groups.
- Describe the responsibility of each group in one line.
- Mark the INPUT and RETURN of every module.
- Check which group titles are visible to BASE CONFIG / Fast Groups Bypasser.
- Only then inspect the internal nodes.
This block is complete when the canvas reads like a system map
- A group’s purpose is clear from its title alone.
- The order of major groups is readable without searching the canvas.
- Every local module has an explicit INPUT / CHECKPOINT / RETURN.
- BASE CONFIG can address the required groups by stable names.
- The production master contains no temporary names such as final2 / test / copy.
- A new person can read modules first and nodes second.