A point in the process where one or more branches are activated based on conditions evaluated at runtime. Unlike XOR (exactly one), OR can activate any non-empty subset of outgoing branches — the exact set is determined by data flags present at split time.
A clinical trial management system routes each patient record to specialist reviewers. A Safety Monitor always receives every record. A Pharmacologist is added if a drug interaction flag is set. A Neurologist is added if CNS involvement is detected. On average, 1.7 branches activate per record — most records hit Safety + one specialist, but complex cases hit all three.
The key insight: the review set is not fixed, but it is not arbitrary either. Conditions are known, evaluable, and deterministic given the data present at triage time. OR-split is the correct primitive here — XOR would force exactly one reviewer (dangerous), AND would force all three (wasteful for simple cases).
| Metric | Signal |
|---|---|
| Branch activation rate per condition | Target: matches expected clinical flag prevalence. Drift signals condition logic errors or data quality issues. |
| Mean branches per record | Cost multiplier over XOR. Should be stable — sudden increases indicate flag inflation. |
| OR-join wait time | Time from first branch completion to all-branch completion. Long tail indicates stalling branches. |
| Timeout rate per branch | Fraction of activations that exceed SLA. Rising rate signals branch reliability issues. |
| Node | What it does | What it receives | What it produces |
|---|---|---|---|
| Patient Triage | Evaluates patient flags and determines the non-empty subset of specialist paths to activate | Raw patient record with clinical flags | Activation signal for each branch based on flag evaluation |
| Safety Monitor | Reviews every record for adverse event risk — always activated | Patient record + adverse event criteria | Safety clearance or hold flag |
| Pharmacologist | Reviews drug interaction profile — activated only if drug interaction flag is set | Patient record + formulary database | Drug interaction assessment |
| Neurologist | Reviews CNS involvement — activated only if CNS flag is set | Patient record + CNS diagnostic criteria | Neurological safety assessment |
| Case Consolidation | Merges all active specialist reviews into a unified case decision. OR-join fires when all activated branches have completed. | Assessments from all activated specialist branches | Consolidated review packet ready for case decision |
| Origin of Value | Where it appears | How it is captured |
|---|---|---|
| Future Cashflow | Case Consolidation node | Quality of the consolidated review scales with the relevance of activated branches. Routing only relevant specialists means each active branch contributes signal, not noise. Value is in the selection accuracy of the OR condition evaluation. |
| Governance | Patient Triage split node | The condition logic at the OR-split encodes the clinical protocol — which flags mandate which reviews. This is the compliance constraint. Incorrect condition logic is a regulatory risk, not just a quality risk. |
| Conditional Action | Each activated branch | Each active branch consumes specialist compute. The OR-split is an Access Token: the flag set unlocks specific compute paths. Average branch activation rate (1.7/record) is the cost multiplier over a pure XOR design. |
| Risk Exposure | OR-join (consolidation) | OR-join deadlock: if a branch activates but never completes, the join waits indefinitely. A branch that stalls silently blocks the downstream process without signaling failure. |
VCM analog: Access Token. The OR-split issues tokens to each qualifying branch. A branch without a token (condition not met) does not run. A branch with a token must complete before the OR-join can proceed. Each token represents a compute commitment.
A branch activates at split time but stalls mid-execution — the Pharmacologist agent hits a rate limit and never returns a result. The OR-join is waiting for all activated branches to complete. The Safety Monitor and Neurologist finished 4 minutes ago, but the case is stuck. The process instance is neither progressing nor failing — it is silently blocked. Fix: each branch must have a timeout and a compensating path. If a branch times out, the OR-join should receive a "timeout" token that counts as branch completion, with a flag that consolidation must note the missing assessment.
The drug interaction flag was set based on a formulary lookup that ran 6 hours before triage. The formulary was updated in the interim. The flag reflects the old state — the Pharmacologist runs based on a condition that no longer applies. Alternatively, a new drug was added to the record after flag evaluation, but the Pharmacologist was not activated because the flag was already cached as false. Fix: condition evaluation must be atomic with the split decision. Flags cannot be pre-computed and cached across process stages if the underlying data can change.
The condition logic is too permissive — the "CNS involvement" flag is set to true for any record mentioning neurological history, even minor ones. Result: Neurologist activates on 94% of records instead of the expected 30%. The OR-split has effectively become a Parallel Split (AND-split) in practice. Fix: audit activation rates per branch against design intent. If a branch activates >80% of the time, either the condition is wrong or the branch should be merged into the always-on path.
| Variant | Modification | When to use |
|---|---|---|
| Weighted OR-Split | Conditions have priority weights; higher-priority branches activate first and lower-priority branches activate only if budget remains | Branch activation has a cost ceiling per record — route the highest-value checks first |
| OR-Split with Mandatory Minimum | At least K branches must activate regardless of flag evaluation; missing branches trigger a default fallback | Regulatory requirements demand minimum review coverage even when flags are absent |
| Sequential OR-Split | Branches activate in priority order; if an earlier branch returns a hold, later branches are suppressed | Early negative result makes later reviews redundant — avoid compute on records already flagged for rejection |
| Pattern | Relationship |
|---|---|
| 10.12 Router (XOR-Split) | Simpler case — exactly one branch activates. Use when conditions are mutually exclusive and exhaustive. |
| 40.42 Multi-Merge | Alternative convergence — instead of waiting for all active branches, downstream fires independently for each completing branch. |
| 40.43 Structured Discriminator | First-wins convergence — fire downstream as soon as one branch completes, ignore the rest. |
| 70.71 Deferred Choice | Event-driven split — activation is determined by external events arriving, not internal data conditions evaluated at split time. |
OR-split logic encodes the routing policy of the organization. In clinical trial systems, the condition logic is the protocol — changing it requires regulatory approval. In AI-native systems, condition evaluation is itself an LLM call, which means the split logic can be learned and updated from outcomes.
The moat is in the condition calibration: organizations that have accumulated ground truth on which flags actually predict which specialist reviews add value have a compounding advantage. The condition logic becomes more accurate over time as false positives are trimmed and false negatives are caught.
Red flag: a system where all branches activate on >70% of records has degraded to an expensive AND-split. The OR-split provides no routing value — the firm is paying for parallelism without benefiting from selection.