A systematic sleeve does not usually stop being systematic in one decision. It happens through a sequence of small, individually reasonable parameter changes, each made in a bad week, each undocumented, until the strategy running in production is not the strategy anyone approved and nobody can say when it stopped being it. The performance record continues in a straight line across every one of those changes, which is precisely the problem.
Change control is the process that makes that impossible. It is four gates, and the fourth is the one that determines whether your attribution means anything a year later.
What the deployments surface gives you, and what it does not
Start with an honest reading of the product, because the control has to be designed around what is actually there. The deployments tab presents a panel headed DEPLOYED STRATEGIES with a browse action alongside it. At capture it showed an empty state, reading that there were no deployments yet and inviting the user to browse the backtested strategies and deploy them to receive live trading signals via webhook, email, Discord or Telegram.
Two things follow from that sentence. The first is that a deployment here is a delivery arrangement. The engine's own step produces signals into a channel. Whatever turns a signal into an order sits downstream in your stack, which means your staged rollout and your kill switch live in your execution layer and not in this panel, and you should stop looking for them here.
The second is a gap I want to state plainly rather than paper over. I cannot confirm from the captured surfaces that this module offers an in place parameter editor, a change log, a version history or a config diff on a running deployment. It may. The empty state does not show one, and I am not going to describe a control I have not seen. Design your process so that it does not depend on the vendor keeping the register for you, because the version of this that fails is the one where three people assume the system is recording something and none of them checked.
Gate one, a proposal that names what would falsify it
Every proposed change gets written down before any evidence is gathered, and the order matters. The document is short and it contains five things. The parameter, its current value and its proposed value. The mechanism you believe is at work, in one sentence, in economic terms rather than statistical ones. The success criterion, stated as a number, decided now. The rollback trigger, also a number. And the count of variants already examined on this strategy, cumulatively, since it went live.
That last field is the one nobody wants to fill in and it is the most important. If this is the eleventh parameter proposal on a strategy this year, the evidence for the eleventh has to clear a materially higher bar than the first did, because you have been searching. A register that carries the running count makes the search visible to the committee rather than leaving it in the researcher's head.
Distinguish two categories at this gate as well. Changing a lookback, a threshold or a stop distance is a research change. Changing leverage, position size or the instrument is a risk change, and the crypto signal payloads carry Leverage as an explicit field, at 2 on one configuration and 0 on another. A risk change that arrives dressed as a parameter tweak is the most common way a mandate breach happens quietly, and it belongs on a different approval path with the risk function on it.
Gate two, evidence from a window the proposer has never seen
The evidence requirement is not that the new parameter tests better. It is that it tests better on data the person proposing it has not previously used, on a window carved out and held in reserve before the current investigation started.
Two supporting requirements make that real. The out of sample window has to be long enough to contain a meaningful number of trades for that strategy, and on this library that is a live constraint rather than a formality, since the engine reports 350 backtested trades across nine strategies, which is on the order of 39 each. Splitting 39 trades into a training set and a hold out set leaves you testing on single digit trade counts, and no committee should accept a parameter change justified on six trades.
The other is that the comparison must be run on the same cost assumptions as production, not on gross prices. A parameter change that shortens holding periods will almost always look better gross and can easily be worse net, because it moves the strategy up the turnover table. Ask for the round trip count under both the old and the new parameter as a mandatory line in the evidence pack.
Gate three, a rollout staged in size with dwell measured in trades
Approved does not mean live at full size. Three stages, and the dwell at each is counted in completed trades rather than in calendar days, because a strategy that trades once a fortnight learns nothing in a month.
- Shadow. The new configuration runs and its signals are recorded, but nothing routes to a broker. This is the stage the module's delivery model makes cheap, since receiving a signal and not acting on it is the default behaviour of a webhook you have not wired up yet.
- Fractional. A fixed and small share of the sleeve's normal size, held for a pre agreed number of completed round trips.
- Full. Only after the fractional stage has completed its trade count without hitting the rollback trigger.
Write the rollback trigger as a number at gate one and honour it mechanically. The failure mode here is not that people ignore the trigger. It is that they renegotiate it while the position is open, which is the same thing with a meeting attached. Name in advance who is allowed to flatten immediately without convening anyone, and require that person to file the record after the fact rather than before, because an emergency path that requires paperwork first is an emergency path that will be bypassed.
Gate four, the record, and the join key the log does not carry
Now the part that makes the previous three worth doing. Every fill has to be attributable to the exact configuration that produced it, and the trade log alone will not get you there.
Its columns run Asset, Strategy, Direction, Status, Timeframe, Order, Time in UTC, Entry, Current, PnL, Run-up, Drawdown, Source and Duration. On the active row at capture the Strategy value read F MTE 1day and the Source read MTEAdopted. That strategy label encodes an instrument and a timeframe. It carries no version and no parameter set, so two fills six months apart under different parameters are indistinguishable in that column.
The identifier you need exists, but it lives in the signal payload rather than the table. Each card in the signal feeds is headed with a configuration label, for example MTE V2 - CONFIGURATION 19 or CONFIGURATION 20, and the card body carries Trading Pair, Trade Action, Prior Trade Position, Current Trade Position, Leverage, Price, Time Period and a Notes string. So capture the entire payload at the moment of receipt, stamp it with your own receive time, hash it, and store it against the resulting order id. That gives you a join from fill to configuration that does not depend on the vendor's table ever gaining a column.
Hashing the whole payload buys you one more thing, which is detection of changes you did not make. Note the version string in that label. MTE V2 implies that a V1 existed, and a vendor side migration of a strategy library is a parameter change to your live sleeve that no gate of yours approved. If your register alerts when the version string, the Time Period, the Leverage field or even the Notes text changes for a configuration you are running, you find out on the day it happens instead of during the post mortem. Then, when a position goes wrong and someone asks what was running, the answer is a configuration identifier, an effective from timestamp in UTC, an approval date, a named approver and a link to the evidence pack. That answer takes ten seconds to produce and it is the entire reason for the process.