Workflow branches and joins

Branching, Parallelism & Joins

Use this skill when designing or implementing decision nodes, multi-branch conditions, parallel fan-out/fan-in (AND/OR), dead-path elimination, and branch data merging in workflows.

Explicit Split Semantics (Van der Aalst Control-Flow Patterns)

Never leave branching behavior implicit. Every split node must declare its exact evaluation mode:

1. Exclusive Choice (XOR-Split / Switch / If-Else):
   • Evaluates ordered conditions deterministically (e.g., top-to-bottom priority) and activates exactly one outgoing branch.
   • Always require or explicitly define a default / else branch so an unmatched condition never leaves a run silently stuck with zero active tokens.
2. Parallel Split (AND-Split / Fork):
   • Activates all outgoing branches concurrently, giving each branch an isolated execution context.
3. Multi-Choice (OR-Split / Inclusive Split):
   • Evaluates predicates for each outgoing port and activates the non-empty subset of branches whose predicates evaluate to true (falling back to a declared default branch if none match).

Explicit Join Synchronization & Dead-Path Elimination (DPE)

A downstream join node must never guess how many incoming branches it should wait for:

• Simple Merge (XOR-Join): Expects exactly one incoming branch from a mutually exclusive split; mark unchosen sibling branches as skipped.
• Synchronizing AND-Join (Wait All): Waits until every incoming branch reaches succeeded (or aborts/fails according to the declared failure policy: fail_fast vs. wait_all_then_report).
• Synchronizing OR-Join + Dead-Path Elimination:
  • When an upstream XOR-Split or OR-Split does not choose branch $B$, propagate a skipped (dead-path) status down $B$ so downstream OR-Join nodes wait only for the branches that were actually activated, preventing permanent deadlocks.
• First-Completed / Discriminator (Wait Any / N-of-M):
  • Advances as soon as $K$ branches succeed, and explicitly cancels or marks the remaining in-flight sibling branches according to configuration.

Branch Output Scoping & Conflict-Free Merging

• Namespace step outputs by nodeId (steps[nodeId].output) or require an explicit merge mapping at the join node so parallel branches never overwrite shared mutable variables through race conditions.

Checklist

• Does every conditional split define deterministic evaluation order and an explicit default/else path?
• Does every join node explicitly specify XOR (one), AND (all active), or N-of-M synchronization plus failure behavior?
• Does Dead-Path Elimination mark unchosen branches skipped so downstream joins never deadlock waiting for them?
• Are parallel branch outputs isolated by nodeId or merged deterministically without shared-variable races?