Van Der Aalst 2003 Workflow Patterns

---
license: Apache-2.0
name: van-der-aalst-2003-workflow-patterns
description: Apply a historical taxonomy of workflow control patterns to evaluate and debug control-flow semantics. NOT for proving resource, transaction, exception, or cancellation guarantees without separate evidence.
metadata:
  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) plus Pattern 3 (Synchronization)
   - Conditional subset → Pattern 6: OR-split (need runtime branch determination)
   - Exactly one branch → Pattern 4 (Exclusive Choice) plus Pattern 5 (Simple Merge)

3. **Synchronization requirements?**
   - Wait for all branches → AND-join or OR-join
   - Each incoming completion should activate the successor → Pattern 8: Multi-merge
   - First completion activates once, remaining arrivals are absorbed before reset → Pattern 9: Discriminator
   - A required threshold is an engine-specific extension; document it separately

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 → distinguish Patterns 12–15 by instance knowledge and synchronization needs

### System Evaluation Decision Tree

**IF** evaluating orchestration systems (see `references/pattern-based-expressiveness-evaluation.md` for the evaluation framework and `diagrams/03_pattern_support_matrix.md` for the classification flow):

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, synchronizing merge, multi-merge, discriminator
4. **Test structural patterns** → Cycles, multiple instances, implicit termination
5. **Test interactions** → Combine patterns your workflow uses together
6. **Classify the implementation** → native, encoded, unsupported, or unknown; measure any local cost with a named baseline and reproducible trace.

**Decision criteria:**
- Natural implementation = supported
- Workaround required = capability gap (see `references/implementation-gaps-as-design-information.md`)
- External code may be an explicit encoding; document its semantics and limits.
- Race conditions appear = semantic mismatch

## Failure Modes

See `diagrams/02_pattern_interaction_trace.md` for an observable OR-split plus synchronizing-merge trace.

### 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**: A DAG engine may need an explicit stateful encoding for a discriminator plus iteration. Verify the chosen engine with a trace; do not infer a blanket impossibility from its name.

**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
- [ ] Any workaround cost has a named baseline and reproducible measurement
- [ ] 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.

## Trace-conformance worksheet

For each required pattern, record: pattern number and name; an observable token/event
trace; activated branch set; terminal and late-arrival behavior; cancellation behavior
(if any); engine version and configuration; and one reproducible test. Classify only as
`NATIVE`, `ENCODED`, `UNSUPPORTED`, or `UNKNOWN`. A feature name is not a semantics
claim. The 2003 taxonomy is control flow: resource allocation, case data, exception
handling, transactions, and cancellation semantics require additional contracts.

## Discriminator worked case

Three providers are started in parallel. The first valid completion atomically records
the winner and enables the successor once. Later completions are recorded and ignored
for that discriminator cycle; they are not automatically cancelled. If work must stop,
define a separate cancellation region with request, acknowledgement, termination and
late-result disposition. A new cycle cannot reset the discriminator until the remaining
branches from the previous cycle have reached their declared disposition.

## Bundled Assets

### Diagrams

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

→ [`diagrams/INDEX.md`](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`](references/INDEX.md)