The problem is not that a lot of signals arrive. It is that they arrive together, they arrive in the same direction, and they arrive at the exact moment the market is least able to absorb them. That combination is not bad luck. It is the structure of the thing.
The default response, which is to start working all of them and see how far you get, is the worst available option. It produces a partially executed basket with unintended net exposure, an execution cost that nobody budgeted, and a set of decisions made at speed by whoever happened to be at the desk. Every part of that is avoidable, but only by writing the rules down while nothing is happening.
Why bursts are correlated rather than random
Queueing models default to independent arrivals because the mathematics is friendly. Signal engines violate that assumption by construction, and the violation is the whole problem.
The Trade Alpha feed aggregates across multiple engines, with the source chips at capture reading MTE, MANUAL, AOE, MRS and MRE and the platform describing a wider set of contributing sources including momentum, reversal, relative strength, macro tilt and manual desk entries. Those engines consume overlapping inputs. When a regime shifts, momentum systems flip, relative strength rankings reshuffle, reversal confluence triggers and a macro tilt updates, all off the same underlying price and volatility move. The arrival process is driven by a common factor, so the tail of the arrival distribution is far fatter than the mean suggests.
There is a second structural detail worth writing into the design note. The platform describes signals as confidence scored and deduped across sources on a ninety second window. That is good product behaviour, and it means the burst you observe is smaller than the underlying agreement that produced it. Two consequences follow. Row count is not a measure of conviction, so do not build an urgency score on it. And the dedup window sets a floor on how tightly you can distinguish arrival times, which matters if you were planning to prioritise by arrival order within a burst.
The order budget, denominated in capacity rather than in count
The first artefact you need is a per-interval budget, and the most common mistake is to express it as a number of orders. Ten orders in the most liquid names on the book is a smaller demand on the desk than two orders in a thin one, so a count-based budget will be simultaneously too loose and too tight.
Express the budget as participation-adjusted notional per interval. For each candidate order, compute the share of expected interval volume it would consume in its own instrument, and let the budget be the sum of those shares subject to a ceiling. That way a basket of liquid names passes and a single illiquid name can consume the whole allowance, which is the correct behaviour rather than an inconvenience.
Four constraints set the ceiling and you take the minimum of them. The impact cap from your own transaction cost work, which is the one that should bind most often. The venue and broker capacity you have actually tested rather than been quoted. The risk limits that apply to intraday gross and net. And an operational limit, which is the number of orders your reconciliation process can handle without falling behind, because a burst that breaks reconciliation creates a control failure on top of a cost problem.
Set the interval short. Fifteen minutes is a reasonable starting point for most books. A daily budget is not a budget, because it is satisfied by a schedule that spends everything in the first twenty minutes, which is exactly what a burst causes.
The priority rule, written before it is needed
Priority has to be deterministic and it has to be computable from fields you already have. Anything requiring judgement during a burst will not be applied consistently, and inconsistency is what you will be asked about afterwards.
Risk-reducing orders go first, unconditionally and outside the budget. Closing a position, trimming an oversized exposure or executing the hedge leg of an existing structure is not competing for capacity with new ideas. Put this at the top of the rule in plain language, because during a burst the new ideas are the exciting ones and they will otherwise crowd out the boring order that was the only one that had to happen.
Below that, rank on signal half-life first. The feed carries a Timeframe column and a Period column, reading Mid-Term with periods of 1day and 4h on the rows visible at capture. A four hour idea and a daily idea have materially different tolerance for waiting, and half-life is the only dimension where waiting is genuinely more costly for one than the other.
Then rank on budget efficiency, which is expected contribution divided by the share of the interval budget the order would consume. This is what stops a single illiquid name from displacing five liquid ones that together carry more of the intended exposure.
Then a tie-break that is fixed in advance and mechanical. A stable ordering by instrument identifier is fine. What matters is that it cannot be influenced by anyone during the burst.
The drop list, and why half-execution is the worst outcome
The part of this design that desks resist is the explicit statement that some signals will not be traded. It feels like leaving money on the table. It is the opposite: it is the mechanism that stops a burst from converting a diversified intention into a concentrated accident.
Consider what half-executing a basket actually does. You intended a set of positions whose net factor exposure was small because the legs offset. You executed the ones that filled easily, which are systematically the liquid, large, high-beta names, and you did not execute the rest. Your realised exposure is now the liquid subset, which is not a scaled-down version of your intention. It is a different portfolio with a factor tilt nobody chose and nobody sized.
So write the drop list as a rule, not as a discretion. Everything below the budget line at the end of the interval is dropped. An order whose remaining half-life is shorter than the wait until the next interval is dropped immediately rather than queued, because queueing it guarantees it will be executed at the point where its edge has already decayed. Any basket that cannot be executed to a stated minimum completion, and I would put that around three quarters of intended legs, is dropped in full rather than executed in part.
Dropped means dropped. The failure I have watched most often is a dropped signal quietly resurfacing two hours later when the desk has capacity, entered at a materially worse price against a thesis that has already played out. If a dropped idea is to be reconsidered, it goes back through the normal process as a new decision with a current price, and it is logged as such.
Instrumenting the queue so the next burst is evidence
None of the parameters above are knowable in advance with any precision. The first version is a considered guess and its real purpose is to generate the data that makes the second version defensible.
Log five things per burst, at the row level. Queue depth over time. Wait time from arrival to order transmission for everything executed. Every dropped row with the rule that dropped it. The realised cost of the orders that were worked. And the counterfactual outcome of every dropped row, priced from the row's own reference through the horizon it was supposed to be held.
The last one is the one that will be skipped and the only one that can change your parameters. Without it you have a record of what you did and no basis for judging whether the budget was too tight, and every review turns into an argument about intuitions. With it you can say, with a quarter of data behind you, that dropped signals in the top liquidity tier would have contributed a measurable amount and the budget should therefore be widened for that tier specifically.
Report the burst statistics separately from the ordinary flow in your execution pack. Averaged into the whole quarter they disappear, because bursts are rare by definition. Broken out, they are the clearest evidence you have about capacity, and capacity is the question the investment committee is really asking when it asks how much more the strategy can take.