A sleeve of six deployments is described in the investment memo as six strategies. On most days that description is accurate. On the days that matter it is not, because the mechanism that makes momentum systems work is the same mechanism that makes them agree, and agreement across six independently sized deployments is how a two percent position becomes an eight percent position without anybody deciding to make it one.
This is a construction problem rather than a signal problem, and it has to be solved above the engine, because the engine does not have the information required to solve it.
What the deployments panel does, and where it stops
The Momentum Trading Engine's deployments tab at capture was a single section labelled deployed strategies, with a browse action and an empty state. The empty state read "No deployments yet" and explained that you browse the backtested strategies and deploy them to receive live trading signals via webhook, email, Discord or Telegram.
That sentence is the whole of the architecture, and it is worth reading slowly. Delivery is per deployment. Each subscription is its own pipe. The page description above it says that once a strategy is subscribed, Autopilot fires the signals into your linked broker under your daily caps. So there are two layers: a per-deployment signal, and a per-account cap on how much firing happens in a day.
Neither layer is a concentration control. A daily cap is a count or a notional ceiling on activity; it is indifferent to what the activity is in. Six deployments each sized correctly on its own terms, each inside its own cap, can all queue orders in the same name in the same session and every individual constraint will report as satisfied. There is no aggregate view on this tab of what the deployments are collectively asking for, and no overlap matrix, so if you want one it is something you construct from the signal stream.
The three axes overlap travels on
Name overlap is the obvious one and the least dangerous, because it is trivially detectable. Two deployments long the same ticker show up in any position file.
Factor overlap is harder. Different instruments, the same underlying exposure. The engine's strategy library at capture included separate 1day equity strategies on two large US financial names and a strategy on a developed-markets international equity fund. Those are three tickers and considerably fewer than three bets. A momentum system does not know it is running a sector concentration; it knows a price is trending.
Timing overlap is the one people miss and it is structural in this engine. The trades log stamps 1day entries at 12:00 AM UTC. Every daily deployment therefore resolves its bar at the same instant, and every daily signal is generated at the same instant. Where those signals route to a broker, they queue into the same next opening auction. The five synchronised timeframes the engine documents create a small number of shared boundaries rather than a smooth distribution of decision times, so correlated arrival is designed in, not accidental.
Building the matrix off the signal stream
The construction is unglamorous. Rows are deployments, columns are trading days, cells are signed target exposure per name. You populate it from the webhook stream rather than from fills, because you want to see what the deployments asked for including the requests that a cap or a limit rejected.
Then compute pairwise correlation on the daily signed-exposure vectors, not on the equity curves. This distinction is the point of the whole exercise. Equity-curve correlation is a smoothed, backward-looking summary that will read comfortably low across a period containing one bad week, because the bad week is one observation out of many. Exposure correlation reads what you actually care about, which is how often two deployments want the same thing on the same day.
The limit that follows is a per-name gross cap enforced at the sleeve, not at the deployment. If six deployments are each sized at two percent of the sleeve and four of them can hold one name, the name-level ceiling has to sit above the engine, in the order path, because each deployment is sizing in ignorance of the other five. Set the cap, and set a rule for what happens to the rejected portion: dropped, or allocated to whichever deployment signalled first. Both are defensible; leaving it undefined means the answer is decided by message arrival order.
The instrumentation to have running before you need it
Four things to log daily, all cheap, all impossible to reconstruct after the fact.
- Requested exposure per deployment per name, before any cap is applied. This is the raw material for the matrix and it disappears if you only store fills.
- Rejections, with the constraint that caused each one. The rejection log is the document you present at review when someone asks whether the limits bind, and a limit that has never rejected anything has not been tested.
- Realised sleeve concentration, as a Herfindahl or simply as the largest name weight, sampled at the close. One number, one time series, and it is the earliest visible sign that the deployments are converging.
- Count of deployments signalling in the same direction on the same session. When that count spikes, the sleeve has stopped being six strategies regardless of what the memo says.
What to write into the policy before the first deployment
The reason to do this while the panel is still empty is that every one of these decisions is contentious once there is money behind it. Three clauses, phrased so that a reviewer can check compliance rather than judgement.
First, the name cap and its enforcement point, stated as a percentage of sleeve gross with the explicit note that it is enforced above the engine because per-deployment sizing cannot see it. Second, a correlation review cadence: recompute the exposure-correlation matrix monthly, and define in advance what pairwise level triggers a conversation rather than deciding after you see the number. Third, the treatment of the shared daily boundary: if all daily deployments resolve at 12:00 AM UTC and route into one auction, either accept that concentration of execution and measure its cost, or deliberately stagger the routing and measure what the delay costs instead. Those are the two options and they have different failure modes; what is not an option is being surprised by it.
One number not to import into any of this. The engine's header tiles report a 96.6% average win rate, a -11.3% average drawdown and a 35.06 average profit factor. Those are library-wide backtest aggregates across nine strategies and 350 backtested trades in total, which is a short sample per strategy, and they are per-strategy statistics computed in isolation. A portfolio built from components with individually attractive drawdown figures has no inherited property at all, because the cross-terms between components are exactly what those tiles omit and exactly what this exercise exists to measure.