Branching and Conditional Logic in AI Workflows

In the Floniks /editor, every node has output ports and input ports. A branch is created the moment you connect a single output port to two or more downstream input ports simultaneously. The workflow engine treats this as a fork: when the upstream node completes, its output is forwarded to every connected downstream node at the same time, and all of those downstream nodes begin executing in parallel.

This is categorically different from running multiple sequential prompts or manually submitting the same image to different models. Branching is structural: the fork is defined in the graph topology before you trigger the workflow, and the engine handles parallelism automatically. You do not need to wait for one branch to finish before the other begins. Both branches receive identical upstream output, process it independently, and produce independent results that you can compare, select from, or merge downstream.

The practical implication is enormous for creative exploration. Instead of generating one image, downloading it, submitting it to model A, downloading that result, then re-uploading to model B — you wire a fork in /editor once and get both variants delivered simultaneously from a single trigger.

Style variant branching is the most common pattern: generate one base image and fork it into two or more style-enhancement nodes, each applying a different aesthetic treatment. One branch might apply a cinematic color grade, another a high-contrast editorial look, a third a pastel illustration style. All three run concurrently and deliver results together, letting you select the best variant without sequential waiting.

Model comparison branching uses the same prompt and input image but routes them to different AI models for the same operation — for example, sending the same portrait through two different face-enhancement models to evaluate which produces better results on your specific content type. This is more systematic than manually swapping models on the /ai-image page, because both models receive identical inputs and you can compare results directly without regeneration variance.

Quality gate branching forks the pipeline into a primary path and a fallback path. The primary path runs a higher-quality (and slower or more expensive) model; the fallback path runs a faster, lighter model. A downstream selector node evaluates both outputs and routes the final delivery to the best-quality result. This pattern is useful for production runs where you want the best possible quality but need a reliable fallback when the primary model produces artifacts.

Fan-out for batch coverage forks a shared reference or character definition into many scene-generation nodes simultaneously. This is the backbone of the character-consistency workflow pattern: one character reference fans out to ten scene nodes, all executing in parallel, producing a complete scene set in the time it takes to run a single scene generation sequentially.

Pure branching executes all downstream paths unconditionally. Conditional logic goes further: it evaluates the result of an upstream node and routes execution to one downstream path or another based on that evaluation. In the Floniks /editor, conditional routing is implemented through condition nodes that inspect the metadata or quality signals emitted by upstream nodes.

A practical example: an image-generation node produces an output with an attached quality-confidence score. A condition node downstream of the generation node checks whether the confidence score exceeds a defined threshold. If it does, the workflow routes to a delivery output node. If it does not, the workflow routes to a regeneration branch that re-runs the generation with a modified prompt. This pattern implements automatic retry logic within the workflow graph — low-confidence outputs are never delivered; they are automatically regenerated until quality requirements are met.

Another common conditional pattern is resolution-based routing: if the input image exceeds a certain resolution, skip the upscaling node (it is unnecessary); if the input is below the threshold, route through upscaling before proceeding. Conditional routing makes workflows adaptive to variable input quality, reducing wasted compute on inputs that do not need processing while ensuring that borderline inputs receive the treatment they require.

Every fork eventually needs a merge — a point where the outputs from parallel branches are collected, compared, or combined before final delivery. The Floniks /editor supports several merge patterns depending on what you want to do with parallel results.

Collect and deliver all: the simplest merge, where an output collection node waits for all branches to complete and delivers all results together. Use this for style-variant workflows where you want to present all options to a human for selection. Select best: a selector node evaluates all branch outputs using defined quality metrics and routes only the highest-scoring output to delivery. Use this for model-comparison and quality-gate workflows where automatic selection is preferable to manual review. Composite: a composition node takes outputs from multiple branches and combines them into a single output — for example, merging a character generated in one branch with a background generated in another branch into a single composed image. This is the pattern used for multi-layer scene composition workflows.

When designing a branching workflow, plan the merge strategy before building the branches. The merge pattern determines what data needs to flow through each branch (all branches must produce compatible output formats for a collect merge; branches that feed a compositor must produce correctly masked and sized outputs for compositing).

A concrete example illustrates branching mechanics clearly. Suppose you are producing a series of product images for a brand and need to decide between two visual styles: a clean minimalist treatment and a warm lifestyle treatment. Instead of running two separate workflow sessions, build an A/B branching workflow in /editor.

The workflow starts with a single image input node accepting the raw product photo. The image feeds a background-removal node that produces a masked product. The masked product's output port is then wired to two background-composition nodes: Node A composites the product onto a clean white seamless background (minimalist style); Node B composites onto a warm-toned wooden surface with natural props (lifestyle style). Both composition nodes run in parallel. Each feeds its own lighting-enhancement node calibrated to its style. Both lighting nodes feed a shared output collection node that delivers all variants together.

A single workflow trigger produces two fully styled variants simultaneously. You evaluate both, select the brand-appropriate style, and that selection informs the style configuration for the full production run. The A/B test takes exactly as long as one branch — not twice as long — because both branches execute concurrently.

The most common branching mistake is creating branches that are not truly independent — branches where a downstream node in one path depends on an output from the other path before the merge. This creates a hidden dependency that breaks the parallel execution model and causes one branch to stall waiting for the other. Always verify that each branch can execute fully without any input from sibling branches.

A second common mistake is not planning for branch failure. If one parallel branch fails — due to a model error, a timeout, or an invalid input — the behavior at the merge node matters greatly. Configure your merge node with explicit handling for partial completion: either wait for all branches (and fail the merge if any branch fails) or deliver available results (and mark failed branches). The choice depends on your use case: for style-variant workflows, delivering available results is usually acceptable; for compositing workflows where all branches contribute to a single combined output, you need all branches to succeed.

Third, do not over-branch. Workflows with 10+ parallel branches per fork become difficult to reason about and debug. For large fan-out scenarios (generating 50 scene variations), use the batch processing mechanism rather than building 50 parallel nodes in a single graph. Batching handles fan-out more efficiently and provides better execution monitoring than an extremely wide node graph.