van-der-aalst-2003-workflow-patterns

license	Apache-2.0
name	van-der-aalst-2003-workflow-patterns
description	Apply the foundational taxonomy of workflow control patterns to evaluate, design, and debug complex coordination systems. Based on the seminal "Workflow Patterns" research establishing pattern-based expressiveness evaluation.
category	Research & Academic
tags	["workflow","patterns","process-modeling","orchestration","bpm"]

SKILL: Workflow Patterns - Systematic Coordination Design

When to Use This Skill

Activate when encountering coordination complexity beyond simple sequential task execution: multi-agent orchestration, parallel processing with synchronization, conditional routing, iterative refinement, or system evaluation for workflow capability.

Decision Points

Pattern Selection Tree

See diagrams/01_flowchart_control_flow_pattern_taxonomy_.md for a visual rendering of this decision tree. The full pattern semantics are documented in references/control-flow-pattern-taxonomy.md.

IF designing coordination structure:

1. Sequential dependency only?

   • Yes → Pattern 1: Sequence
   • No → Continue to branching analysis

2. Multiple parallel branches needed?

   • All branches required → Pattern 2: AND-split/join
   • Conditional subset → Pattern 6: OR-split (need runtime branch determination)
   • Exactly one branch → Pattern 4: XOR-split/join

3. Synchronization requirements?

   • Wait for all branches → AND-join or OR-join
   • First completion wins → Pattern 9: Discriminator
   • N out of M completions → Pattern 8: N-out-of-M-join

4. Decision timing?

   • Process determines → XOR-split (internal condition)
   • External event determines → Pattern 16: Deferred choice
   • Runtime data determines → OR-split

5. Iteration needed?

   • Fixed structure loop → Use sequence + XOR back-edge
   • Dynamic/arbitrary cycles → Pattern 10: Arbitrary cycles
   • Multiple concurrent instances → Pattern 12: Multiple instances

System Evaluation Decision Tree

IF evaluating orchestration systems (see references/pattern-based-expressiveness-evaluation.md for the evaluation framework; diagrams/03_quadrantChart_system_expressiveness_vs._patt.md for an expressiveness-vs-cost comparison chart):

1. Map required patterns → List all coordination structures your domain needs
2. Test basic patterns → Sequence, AND-split/join, XOR-split/join (if these fail, stop)
3. Test advanced branching → OR-split, discriminator, N-out-of-M (most systems fail here)
4. Test structural patterns → Cycles, multiple instances, implicit termination
5. Test interactions → Combine patterns your workflow uses together
6. Measure complexity → >10x workaround complexity = unsupported

Decision criteria:

• Natural implementation = supported
• Workaround required = capability gap (see references/implementation-gaps-as-design-information.md)
• External code needed = wrong architecture
• Race conditions appear = semantic mismatch

Failure Modes

See diagrams/02_sequenceDiagram_pattern_interaction_failure_sc.md for sequence diagrams of these failure scenarios.

1. OR-Split Confusion (Symptom: Wrong branches activate)

Detection: OR-split activates all branches instead of runtime-determined subset, or requires manual branch selection Root cause: System conflates OR-split with AND-split or lacks runtime evaluation capability Fix: Implement true OR-split with condition evaluation at runtime, or redesign using multiple XOR-splits

2. Discriminator Race Conditions (Symptom: Multiple completions processed)

Detection: "First wins" logic processes multiple completions, late arrivals not ignored, state corruption on near-simultaneous finish Root cause: Missing atomic completion detection or lack of proper discriminator semantics Fix: Implement atomic first-completion detection with explicit late-arrival ignoring, use proper discriminator pattern not AND-join

3. Deferred Choice Polling (Symptom: Active waiting for external events)

Detection: System polls for external conditions instead of event-driven activation, high CPU usage during wait states Root cause: No event-driven external choice mechanism, treating deferred choice as sequence + condition check Fix: Implement event-based deferred choice with proper external stimulus handling, avoid polling-based workarounds

4. Cycle Termination Deadlocks (Symptom: Infinite loops or stuck processes)

Detection: Workflows with cycles never terminate naturally, require manual intervention, or deadlock on exit conditions Root cause: No implicit termination support or cycle exit condition evaluation Fix: Implement proper cycle semantics with exit conditions, use state-based termination detection

5. Pattern Interaction Failures (Symptom: Unexpected behavior when patterns combine)

Detection: Individual patterns work but combinations crash, undefined behavior at interaction boundaries Root cause: Ad-hoc pattern implementations without unified execution model Fix: Use systems with formal execution semantics (Petri nets, process algebras) or explicitly test all pattern combinations. See references/pattern-combinations-and-emergent-complexity.md for analysis of non-composability.

Worked Examples

Example 1: Multi-Agent Code Review Orchestration

Scenario: Code review requiring parallel analysis (security, performance, style) with first-completion wins logic and iterative refinement.

Pattern identification:

• AND-split: Parallel agent execution
• Discriminator: First satisfactory review wins
• Arbitrary cycles: Revision loops
• Cancellation: Abort remaining agents when one succeeds

Decision walkthrough:

1. Need parallel branches? Yes → multiple review agents
2. All branches required? No → discriminator pattern (first success wins)
3. Iteration needed? Yes → arbitrary cycles for revisions
4. External events? Yes → human reviewer can trigger revision

Expert insight: DAG-based orchestrators fail here because they cannot express discriminator + cycles combination. Need state machine or Petri net model.

Novice mistake: Using AND-join instead of discriminator, causing system to wait for all agents even after first success.

Example 2: Dynamic Pipeline with Conditional Stages

Scenario: Data processing pipeline where downstream stages depend on upstream results and data characteristics determine stage activation.

Pattern identification:

• OR-split: Runtime determination of active stages
• OR-join: Synchronize variable number of active branches
• Deferred choice: External quality check determines retry vs. proceed

Decision walkthrough:

1. Branching logic? Runtime data determines → OR-split
2. Synchronization? Must wait for activated branches only → OR-join
3. Decision timing? External quality service → deferred choice

Expert insight: OR-split/OR-join combination requires the join to know which branches were activated by the split. Many systems lack this state tracking.

Novice mistake: Using XOR-split with manual branch tracking instead of true OR-split, losing semantic clarity and introducing bugs.

Example 3: Competitive Agent Auction with Fallback

Scenario: Multiple agents bid on task, first acceptable bid wins, with timeout fallback to direct assignment.

Pattern identification:

• AND-split: Parallel agent activation
• Discriminator: First acceptable bid
• Deferred choice: Timeout vs. bid acceptance
• Cancellation region: Abort auction on timeout

Decision walkthrough:

1. Parallel execution? Yes → AND-split for simultaneous bidding
2. Completion semantics? First acceptable → discriminator
3. External event handling? Timeout can interrupt → deferred choice
4. Cleanup needed? Cancel pending bids → cancellation region

Expert insight: This requires discriminator inside deferred choice inside cancellation region. Pattern interaction complexity eliminates most orchestrators.

Novice mistake: Manual timeout handling instead of proper deferred choice, creating race conditions between bid acceptance and timeout.

Quality Gates

• All required coordination patterns identified and mapped to specific taxonomy entries
• System evaluation tests actual pattern implementation, not just feature claims
• Pattern combinations tested for workflows using multiple patterns together
• Workaround complexity measured (>10x baseline = unsupported)
• Decision points explicitly modeled (who/what decides routing at each choice point)
• Synchronization semantics verified (what triggers join completion)
• Cancellation boundaries defined with cleanup semantics
• External event handling mechanisms identified for deferred choice patterns
• Cycle termination conditions specified for iterative patterns
• Implementation gaps documented as architecture information (not just limitations)

NOT-FOR Boundaries

This skill is NOT for:

• Data flow design → Use data pipeline patterns instead
• User interface workflows → Use UI state management patterns
• Sequential scripting → Use basic programming constructs
• Database transaction design → Use ACID transaction patterns
• Error handling → Use exception handling patterns
• Performance optimization → Use performance analysis skills
• Domain modeling → Use domain-driven design patterns

Delegate to other skills:

• Task logic design → Use domain-specific problem solving skills
• Agent capability design → Use agent architecture skills
• Data transformation → Use data processing pipeline skills
• System monitoring → Use observability and monitoring skills
• Security coordination → Use security architecture patterns

Boundary indicator: If you're designing WHAT agents do (task logic), use domain skills. If you're designing HOW agents coordinate (control flow), use this skill. See references/coordination-as-first-class-problem.md for a full treatment of why coordination deserves first-class engineering attention.

Bundled Assets

Diagrams

Visual aids for pattern selection, failure diagnosis, and system expressiveness comparison.

→ diagrams/INDEX.md

References

Deep-dives on the pattern taxonomy, evaluation methodology, imperative vs. declarative tension, and systems evaluation beyond feature checklists.

→ references/INDEX.md