BASE CONFIG Lab: Fast Groups Bypasser as the graph control plane
The second lab moves routing logic up to the level of whole groups. The goal is to experience the difference between topology, the selected route and centralized enable/bypass control before adding SDXL, FLUX or any other heavy model.
What changes after LAB 01
LAB 01 taught route selection inside the data flow. LAB 02 moves one level higher: now we control the state of complete functional groups rather than an individual selector.
This is the first real control plane. BASE CONFIG does not carry IMAGE or MASK data; it changes the state of the modules through which that data may flow.
What Fast Groups Bypasser actually does
Fast Groups Bypasser is a frontend/control node with no ordinary data input. It scans workflow groups and creates an Enable <group title> row for every matching group.
When ON, nodes in the group return to normal execution mode. When OFF, Bypasser uses mode 4 — Comfy bypass. This differs from Fast Groups Muter, where OFF maps to NEVER/MUTE.
Important restriction limitation
max one / always one is enforced when toggling through Fast Groups itself. Manually changing node modes inside a group can diverge from that policy.
| Property / Action | Purpose |
|---|---|
| matchTitle | Filter groups by title; supports string/regex matching |
| matchColors | Filter by group color |
| sort | position / alphanumeric / custom alphabet |
| showNav | Show a quick-navigation arrow to the group |
| toggleRestriction | default / max one / always one |
| Bypass all | Put managed groups into bypass subject to the restriction |
| Enable all | Enable managed groups subject to the restriction |
| Toggle all | Invert managed toggles subject to the restriction |
Build a control plane on top of the Routing Sandbox
Use LAB 01 as the starting point. Keep the nodes simple: two text branches → selector → output. Now add groups and a centralized control panel.
- Create groups ROUTE_A, ROUTE_B, SELECTOR and OUTPUT.
- Place Fast Groups Bypasser separately, outside the groups it manages.
- In Fast Groups Bypasser Properties set matchTitle = ^ROUTE_.
- The panel should show only Enable ROUTE_A and Enable ROUTE_B.
- Keep toggleRestriction = default for the first experiment.
- Initial selector value: index = 0.
Bypass the unselected branch
What this proves
Group enabled state and selector state are independent. You can change the availability of an unselected branch without changing the selected route.
| State | Action | Expected meaning |
|---|---|---|
| index = 0; A ON; B ON | Queue Prompt | Output depends on ROUTE_A |
| index = 0; A ON; B OFF | Queue Prompt | ROUTE_B is bypassed, but the current selected route remains A |
| index = 0; A ON; B ON | Enable ROUTE_B | Topology is unchanged; only group availability changes |
Availability first, selection second
Return both groups to ON. Switch the selector to index = 1 and verify ROUTE_B, then return to index = 0. Train yourself to read the system with two consecutive questions: first “which modules are available?”, then “which available route is selected?”
max one and always one are policies, not data routing
Set toggleRestriction = max one. Toggle ROUTE_A and ROUTE_B through Fast Groups Bypasser itself and observe how the panel keeps at most one group enabled. Then try always one: the panel should attempt to keep at least one group active.
Do not confuse this with the selector. The restriction defines valid control-plane states; it does not by itself decide which input a downstream selector chooses.
Not an absolute lock
rgthree explicitly notes that restrictions apply to actions performed through Fast Groups. Manually changing modes inside groups can violate the expected max-one/always-one state.
Group filters are the foundation of a professional BASE CONFIG
Create a second Fast Groups Bypasser. Keep matchTitle = ^ROUTE_ on the first. On the second, use matchTitle = ^PROCESS_ after creating two empty training PROCESS groups.
This demonstrates that one large workflow can expose several control panels — for example PPL CONFIG, PROCESS CONFIG and OUTPUT CONFIG. This is an architectural technique, not a model-specific trick.
Now read Hansen BASE CONFIG as a map of systems
After this lab, the large yellow Hansen panel should no longer look like a list of mysterious yes/no switches. It is a catalog of functional subsystems in a production workflow.
- MODEL LOADERS — availability of resource-heavy loaders.
- INPUTS — input layer.
- CONTROL / SAMPLER CONFIGURATION — shared control layer.
- ControlNet PREPROCESSORS + EXTRAS — preprocessing subsystem.
- MASKS — mask subsystem.
- PPL FLUX Generate / SEGMENTATION / Composite / 3D Inpaint — independent PEOPLE stages.
- Process SEGMENTATION / SDXL / FLUX / UPSCALE / ADD LOGO — processing stages.
- OUTPUT — terminal stage.
The next level is runtime profiles
Named profiles such as MASK DEBUG, PEOPLE ONLY or FINAL FULL RUN are our architectural layer, not a built-in Fast Groups Bypasser feature. Their purpose is to predefine the minimum set of enabled modules for a specific task.
| Profile | Idea |
|---|---|
| INPUT CHECK | INPUTS + OUTPUT/preview; heavy process branches disabled |
| MASK DEBUG | INPUTS + preprocessors + masks + diagnostic output |
| PEOPLE LAB | Only the required PPL stages and return checkpoint |
| BASE GENERATION | Main SDXL/ControlNet route without optional upscale/logo |
| FINAL FULL RUN | Production route with final optional stages as required |
LAB 02 is complete when BASE CONFIG stops feeling like magic
- You can explain why Fast Groups Bypasser does not need an ordinary data cable.
- You distinguish group ENABLE/BYPASS state from SELECTing a route.
- You understand matchTitle and can restrict the panel to a target family of groups.
- You know the difference between default, max one and always one.
- You can look at Hansen BASE CONFIG and name the subsystems rather than merely list switches.
- You can propose a minimal runtime profile for a specific test.
Next step
After LAB 02, move to LAB 03: Module Contract — INPUT → PROCESS → CHECKPOINT → RETURN. This is where we first build a small production-style module with a clear responsibility boundary.