Test one variable at a time

A candidate has reached its sample and cleared the threshold. The next step is not to change the rule; it is to test the change, in a way that produces a clean comparison. That means one variable, a fixed number of trades, and a decision rule written before the test starts.

Why one at a time

If the new plan version changes the filter, the trail and the time stop all at once, and the next fifty trades are better, you have learned that the bundle is better. You do not know which change did it, whether one of the three is actually hurting, or what to do when results turn. You have replaced one plan you did not understand with another.

One change per version. It is slower. It is the only way the journal can attribute an effect.

The test protocol

State the change as a rule, in the plan's format. "Trail: stop to one tick below each new 5-minute higher low" becomes "Trail: stop to close of first 5-minute bar closing below the 10 EMA".
State the prediction. Which number should move, and by how much. "Average realised R on trades that reach +1R should improve by at least 0.3R, because the current trail is giving back too much on the retest." If you cannot say which number should move, you do not have a hypothesis; you have a hunch.
State the sample. Thirty trades on the new rule, minimum. Write the number down.
State the decision rule. "If the metric improves by 0.3R or more, keep. If it is within ±0.3R, revert to the old rule; the change was not worth its complexity. If it is worse, revert." Written before trade one.
Bump the version. v1.1 becomes v1.2, valid from a date. Every journal row from that date carries the new version.
Run it without touching anything else. No other candidate is tested during the window.
Evaluate at the sample, not before. Not at trade 18 because it looks great, not at trade 12 because it looks bad.

Key idea: One variable, a prediction of which number moves, a sample size and a keep/revert rule, all written before the first trade of the new version.

Shadow testing

Some changes can be tested without changing what you trade. If the candidate is a tighter filter, you can keep trading the current filter and simply tag which trades would have been excluded under the new one. After thirty tagged trades, compare. This is a shadow test: it costs nothing, it runs in parallel, and it is the right first step for any filter change.

Exit rules can be shadow-tested too, with more effort: on every trade, record where the alternative trail would have exited. The journal template has an optional "shadow exit" column for this. It is worth the ninety seconds when the candidate is a trail or a target level.

Setup criteria cannot be shadow-tested cleanly, because a trade that was not taken has no execution record. Those need a live version bump.

What "better" means

Better is measured on the number the prediction named, and checked against two others:

The named metric moved by at least the threshold.
Average R overall did not get worse.
Mistake frequency did not go up. A rule that improves the numbers but is harder to execute correctly will lose its improvement to execution errors within a quarter.

A change that improves the named metric but raises the mistake rate is a change that needs a simpler formulation, not a keep.

Reverting is a result

At least half of tested changes should revert. If every test is a keep, the decision rule is too loose or the evaluation is being done by someone who wanted the change. A revert is logged with the same care as a keep: version, dates, sample, metric, decision. The plan's history file (next lesson) records it, so that the same idea is not tested again in six months by someone who has forgotten.

A worked test

Plan v1.1, MES breakout, 83 trades. Candidate: the 30-minute time stop is closing trades that later work. Subset: trades closed by time stop, 19 of them, average −0.2R; shadow-tracked, 12 of the 19 would have reached +1R within the next 30 minutes. Nineteen is under the thirty minimum, so the candidate waits. At 112 trades, the subset is 31, average −0.15R, and 20 of the 31 would have reached +1R with a 60-minute window.

Test: v1.2, time stop moved from 30 to 60 minutes. Prediction: average R on trades that were previously time-stopped improves by 0.4R or more. Sample: 30 time-stop-eligible trades. Decision rule: keep if ≥ +0.4R, revert if under +0.2R, extend to 50 trades if between.

Result at 30: +0.35R. Between the thresholds; extended to 50. At 50: +0.42R, mistake rate unchanged, overall average R up from 0.18R to 0.24R. Keep. v1.2 becomes the base.

Try it: Take the strongest candidate on your list and write the seven-step protocol for it: rule, prediction, sample, decision rule, version, exclusions, evaluation date. If step 2 is hard, the candidate is not ready. If it can be shadow-tested, start the shadow tags tomorrow instead of the version bump.

Recap

One change per plan version. A bundle of changes that works teaches you nothing about which part worked.
Before trade one: the rule, the metric that should move, the sample size, and the keep/revert thresholds.
Filters and most exits can be shadow-tested at no cost by tagging trades. Setup criteria need a live version.
A keep requires the named metric to improve and mistake frequency not to rise.
Half of tests should revert. A revert is logged as carefully as a keep, so it is not repeated.