20.23 Structured Discriminator

Fires the outgoing flow as soon as the first of N parallel incoming branches completes. Subsequent completions are ignored. The first-wins pattern within a structured block — all branches must eventually complete before the block can close, but only the first completion triggers downstream processing.


Motivating Scenario

A trading system receives an order and simultaneously routes it to three execution venues: NYSE, NASDAQ, and CBOE. The same order is broadcast to all three. Whichever venue confirms fill first wins — the other two responses are discarded. The goal is best execution speed: the fastest venue gets the trade.

The key constraint: all three venue connections must remain open until the block completes. The system cannot cancel the order at NYSE and NASDAQ the moment CBOE confirms — the cancellation is a separate coordination problem (handled in 20.25, Cancelling Discriminator). The Structured Discriminator only guarantees that the first fill triggers the downstream confirmation flow. The branches that arrive second and third are acknowledged but not acted upon.

Structure

Zoom and pan enabled · Concrete example: multi-venue order execution with first-fill wins

Key Metrics

MetricSignal
Time to first completion Primary performance measure — the discriminator's value is entirely in this latency
Winning venue distribution Which venue wins most often — informs venue weighting or branch pruning
Margin between first and second completion Tighter margins increase duplicate-fill risk — threshold for adding cancellation logic
All-reject rate Fraction of broadcasts where no branch returns a fill — signals market conditions or pricing errors
NodeWhat it doesWhat it receivesWhat it produces
Broadcast Order Sends identical order to all three execution venues simultaneously via AND-split Order parameters (symbol, quantity, price type) Three simultaneous order submissions
NYSE Execution Submits and monitors order at NYSE; returns fill confirmation with venue timestamp Order Fill confirmation or rejection with timestamp
NASDAQ Execution Submits and monitors order at NASDAQ; returns fill confirmation with venue timestamp Order Fill confirmation or rejection with timestamp
CBOE Execution Submits and monitors order at CBOE; returns fill confirmation with venue timestamp Order Fill confirmation or rejection with timestamp
First Fill Wins OR-join that fires on first incoming completion. Passes first confirmation downstream; subsequent arrivals are acknowledged but do not retrigger the downstream flow. First arriving fill confirmation Winning venue + fill details for trade confirmation
Confirm Trade Records the execution, updates portfolio position, triggers settlement workflow First fill confirmation from winning venue Trade record + settlement instruction

When to Use

Use when
Avoid when

Value Profile

Origin of ValueWhere it appearsHow it is captured
Future Cashflow First Fill Wins node In execution, microseconds determine fill price. The discriminator's value is the latency advantage of the fastest venue. Value is in the competitive speed advantage, not in the redundancy of running all three venues.
Governance Broadcast Order node Regulatory best execution requirements mandate demonstrating that multiple venues were considered. Broadcasting to all three and taking the first fill is the governance compliance mechanism. The discriminator is both a performance and a compliance pattern.
Conditional Action Three concurrent venue connections Running N=3 branches costs 3x the single-venue execution overhead. The cost is justified by the latency improvement from racing. At N>5, the marginal speed improvement typically does not justify the coordination overhead.
Risk Exposure Ignored completions (branches 2 and 3) If branch 2 (NASDAQ) completes while the system has not yet cancelled the order there, the position may be filled twice. The Structured Discriminator does not cancel remaining branches — it only ignores their results. Duplicate fill risk must be managed externally.
Related: 20.25 Cancelling Discriminator. Extends this pattern by actively cancelling remaining branches after the first completes. Use 20.25 when branch continuity has real cost (open orders, held resources). Use 20.23 when branches can safely run to completion without downstream consequence.

Dynamics and Failure Modes

Duplicate fill (ignored completion causes real-world side effect)

CBOE confirms fill at T=10ms. The discriminator fires the downstream flow — Confirm Trade records the CBOE position. But NASDAQ also fills the same order at T=11ms, 1ms too late for the discriminator. The order was filled at both venues. The position is now 2x the intended size. The discriminator correctly ignored the NASDAQ result from the workflow perspective, but the order was never cancelled at NASDAQ before it filled. Fix: the Broadcast Order node must send cancellation instructions to non-winning venues the moment the discriminator fires. This is 20.25 (Cancelling Discriminator) behavior and must be implemented as part of the pattern instantiation.

All branches reject — discriminator starves

NYSE, NASDAQ, and CBOE all reject the order (market halt, invalid price). No branch completes with a fill. The OR-join at First Fill Wins never fires because OR semantics require at least one completion, but a rejection is not the same as "no completion" in some implementations. If rejections are not routed to the discriminator as valid completions (even if negative), the process hangs. Fix: rejections must be treated as branch completions with a negative result. The discriminator must be able to receive the first rejection and route to an error path, not wait indefinitely for a positive fill.

Sub-millisecond tie — discriminator non-determinism

Under high load, NYSE and NASDAQ both return fill confirmations within the same message processing batch. The discriminator's tie-breaking behavior is implementation-dependent — whichever message is processed first wins. If the discriminator is not deterministic in tie-breaking, the "winning" venue changes unpredictably under load. Fix: timestamps must be attached at branch entry, not at discriminator receipt. Tie-breaking by earliest branch-submission timestamp, not by arrival order at the join node.

Variants

VariantModificationWhen to use
Cancelling Discriminator (20.25) Extends 20.23 by sending explicit cancellation signals to remaining branches after first completion Remaining branches consume real resources (open orders, held locks, running compute) that must be released
Blocking Discriminator (20.24) Discriminator can reset and fire again in subsequent cycles within the same process instance Process loops and each loop iteration uses a fresh discriminator — the pattern repeats, not just runs once
Quality-Weighted Discriminator First completion fires downstream only if quality score exceeds threshold; otherwise waits for next branch "Fast enough and good enough" — speed matters but not at the cost of minimum quality standards

Related Patterns

PatternRelationship
40.42 Multi-MergeContrast: fires downstream for every completion, not just the first. Use when each result independently enriches the output.
40.41 Multi-Choice (OR-Split)Common upstream pairing — OR-split activates a variable subset of branches that race to the discriminator.
20.24 Competitive EvaluationQuality-based selection among parallel outputs — selects the best result, not the fastest.

Investment Signal

The Structured Discriminator is the core pattern behind "racing" architectures: redundant execution for latency reduction. Its commercial value depends entirely on the cost-vs-speed tradeoff: running 3 venues costs 3x the infrastructure, justified only if the latency improvement translates to better fill prices or higher throughput.

In AI-native systems, the discriminator appears when multiple LLMs or inference endpoints are called in parallel and the fastest response wins. The pattern is the same: broadcast a prompt, take the first valid response, discard the rest. The economic logic is identical to execution venues.

Due diligence question: has the cost of running N branches been validated against the actual latency improvement? Systems that race 5 LLMs for 15% latency improvement at 5x inference cost are destroying value, not creating it. The discriminator's ROI must be measured, not assumed.