Every backtest result you look at is a survivor list. It shows the trades your rules permitted, which is the population you can see, and it is silent about the population that decides whether your rules are any good: the signals that arrived and were turned away because a limit was already full.
That second list is where the honest assessment of a guardrail lives. A cap that declined a dozen trades which all went on to lose is doing its job. A cap that declined the four trades that carried the whole period is not a risk control, it is a tax you are paying for a comfort you could have bought more cheaply. From the headline result the two are indistinguishable, because both simply produce a smaller number.
Why the rejected set is invisible by construction
The Backtest a Profile panel on Autopilot replays historical signals against a chosen profile with no real orders placed, and it states that it honors all filters, sizing, leverage caps, and risk guards. That sentence is the reason rejections exist inside the run. The engine walks the signal history, and every time a signal arrives while a constraint binds, the trade is not taken. The event happens. It just does not necessarily leave a mark you can read.
I cannot confirm from the panel that the run outputs a list of skipped signals, so do not build a routine that assumes one. Look first, because if it is there this becomes a five minute job. If it is not, the rejected set is still recoverable, and the method below needs nothing beyond the three inputs the panel already takes: a profile, a number of days, and a start equity.
Getting the list by differencing two runs
The trick is that a rejected signal is just a trade that appears in one run and not another. So make two runs that differ in exactly one guard, and subtract.
- Duplicate the profile so you have an identical copy. You are going to loosen one setting on the copy and you do not want to be editing the profile you actually run.
- On the copy, widen a single constraint as far as it will go. If you are testing a concurrency or exposure limit, take it high enough that it cannot bind. Change nothing else, not the entry logic, not the filters, not the stops.
- Run both profiles on the same day, with the same day count and the same start equity. The day count is measured back from when you press the button, so runs on different days cover different windows and your difference will be partly calendar.
- Export or copy both trade lists into a spreadsheet, keyed on instrument plus entry timestamp. The rows present in the loosened run and absent from the real one are your rejected set.
- Sum the results of those rows. That total, positive or negative, is what the guard cost or saved you over that window.
If the loosened run produces a wildly larger trade count, resist the temptation to read its return as an alternative you could have had. It is not. It is a diagnostic, and it required capital and attention you may not possess. The only number you are extracting is the difference.
Three tests that separate a healthy rejection from a mis-set cap
With the rejected list in front of you, run it through three checks. Each one answers a different question and they can disagree.
The first is the hit rate comparison. Work out the win rate and average result of the rejected trades and put them next to the same figures for the trades that were taken. If the rejected trades are meaningfully worse, your guard is selecting, which is the best outcome available and rarer than people expect. If they are statistically indistinguishable, the guard is sampling rather than selecting: it is removing a random slice of your strategy, which reduces your return in proportion to the slice and reduces your risk in the same proportion. That is a fair trade and worth keeping if the risk reduction is what you wanted.
The second is the timing check, and it is the one that catches the expensive mistakes. Look at when the rejections clustered. A guard that declines trades evenly across the window is behaving like a size control. A guard that declines nothing for weeks and then declines nine signals in three days is a cluster control, and clusters are not random samples of your strategy. They are the days everything moved together. Whether that is where your money is made is the single most important thing this exercise tells you, and it depends entirely on your entry logic.
The third is the count of firings. If a guard declined two signals in six months, it is not a control, it is decoration, and your real constraint is something else. Find out what actually binds before you congratulate yourself on the setting.
The rejection you should not fix
Suppose the timing check tells you your concurrency limit is eating the clusters, and the cluster trades were the profitable ones. The obvious move is to raise the limit, and it is usually the wrong one.
Raising it puts your worst week straight back where it was, because the reason the cluster is profitable and the reason it is dangerous are the same reason: the positions are correlated. Ten simultaneous entries selected by one engine reading one condition across related instruments are closer to one large bet than to ten small ones. When that bet is right the run looks superb, and when it is wrong nothing diversifies it away.
The better response is to hold the total risk constant and change its shape. Cut the per trade size and raise the count by the same factor, so eight positions at half size replaces four at full size. The worst week is unchanged, you participate in most of the cluster, and you get twice as many samples. What stops this working is friction: halving the size doubles the order count, and on any venue charging a fixed fee per order you can spend the entire benefit on commissions. Price it before you commit, using your venue's real round trip cost against your new average position size.
What the difference cannot tell you once it is live
Two limits on this whole method deserve stating, because both of them bite in the same direction, which is toward optimism.
The rejected trades were priced at the backtest's assumed entry. In a real cluster, those are precisely the fills you would have been least likely to get on your terms, since everyone else's systems are reading the same condition at the same moment. The counterfactual value of your rejected list is therefore an upper bound, and on thin instruments it can be a generous one. The module's own warning on this screen makes the general point: with paper mode off it places real orders on connected exchanges, execution prices may differ from signal prices because of market conditions and latency, and you are solely responsible for the trades. It tells you to start in paper, verify the behaviour, then go live small, and this is one of the specific behaviours worth verifying.
The second limit is that the differencing method works on history and stops working the moment you go live, unless you keep the record yourself. A declined signal that leaves no trace in your live log is a hole you will notice three months from now, when the profile's realised results do not match the signal source's published results and you have no way to demonstrate that the gap is your own caps rather than the strategy failing. Check whether declined signals appear anywhere in the profile's history, and if they do not, start logging the signal feed separately from day one. It is dull, it takes minutes a week, and it is the difference between explaining your results and guessing at them.