A trade filter can make historical results look dramatically better without proving that it will improve the next trade. Removing losing rows after seeing them is arithmetic. A defensible filter is a decision rule that could have been applied before entry, covers every eligible opportunity, includes costs, and survives an unchanged forward test.
The previous version of this page presented five unsourced “real case studies” and universal improvement ranges. Those claims were not backed by trade-level records in the evidence bundle, so this correction replaces them with five journal audit tests you can reproduce on your own data: setup coverage, session eligibility, post-loss sequences, frequency authority, and a combined holdout test.
Quick answer: run the historical before/after only to generate a hypothesis. Freeze the filter, trial count, population, costs, and verdict rule; then apply it unchanged to a later or untouched period. Report both the rows removed and the opportunities the filter would have rejected. A result can be supported, inconclusive, or rejected—not “proven” because one equity curve looks smoother.
Three Different “Before vs After” Questions
Most filtering mistakes begin by treating three different designs as if they answer the same question.
| Design | What it computes | What it cannot prove | Best use |
|---|---|---|---|
| Historical subtraction | Removes tagged executions from one realized ledger | That the tag was knowable before entry or behavior would stay unchanged | Hypothesis generation |
| Untouched holdout | Applies a frozen rule to data not used to choose it | Permanent edge across future regimes | Initial validation |
| Prospective trial | Records live or simulated decisions after the rule takes effect | That every difference was caused by the filter | Operational validation |
A historical filtered curve is counterfactual: it says what the recorded subset would have returned under declared inclusion and cost assumptions. It does not observe skipped opportunities, changed attention, replacement trades, capacity, or how the trader would behave after the filter changed the sequence.
Repeatedly trying rules on the same history and keeping the prettiest result creates selection bias. White’s Reality Check for data snooping formalizes why a winner selected from many reused tests can be a chance result. Bailey, Borwein, López de Prado, and Zhu likewise show how investment backtests can be overfit and propose a framework for estimating that risk in The Probability of Backtest Overfitting. A discretionary journal filter is simpler than their portfolio examples, but the warning transfers: log every filter tried, not only the winner.
The Filter Audit Contract
Write this contract before opening the result column:
- Decision: the exact future action the analysis may authorize.
- Population: account, instrument, setup version, dates, session definition, side, and status.
- Filter: a condition available before the decision point; post-outcome labels are diagnostic only.
- Coverage: eligible, included, excluded, unknown, missing, cancelled, skipped, and duplicate records.
- Economics: gross result, commissions, fees, financing, borrow, slippage, and currency conversion where applicable.
- Trials: every rule, threshold, combination, and segment inspected on this history.
- Validation: an untouched or later period and a date on which the frozen rule will be judged.
- Verdict: supported, inconclusive, or rejected, with a prewritten action for each.
The full edge-filtering guide explains why a filter should narrow a specific decision rather than rescue an attractive aggregate metric.
Case 1: Setup Filter Audit—Tag Coverage First
Unsafe version: delete every untagged trade and call the remaining curve the strategy. “No Setup” means the record lacks a usable setup label; it does not mean the trade was invalid or negative-expectancy.
Test: first audit label coverage. Reconstruct the active setup definition and classify each eligible decision as setup present, setup absent, or unknown using evidence that existed before entry. Keep unknown rows visible. Compare each group only after coverage, duplicates, cancellations, partial fills, and costs reconcile.
| Output | Required evidence | Interpretation |
|---|---|---|
| Setup present | Rule version plus pre-entry fields | Eligible for a strategy result |
| Setup absent | Evidence that a required condition failed | Can test an exclusion policy |
| Unknown | Missing or ambiguous decision-time evidence | Data-quality gap, not a losing strategy |
Forward rule: reject or separately queue an entry when required setup evidence is missing. Do not retroactively infer the label from whether the trade won.
Case 2: Session Filter Audit—Compare Like With Like
Unsafe version: scan every session, keep the most profitable one, and declare it universally best. That confounds session with setup mix, instrument, volatility, news, spread, sample size, and the number of sessions tested.
Test: define session boundaries and timezone before analysis. Hold setup version, instrument, side, cost basis, and eligibility rules constant. Report trade count, active trading days, net result, expectancy with its denominator, drawdown convention, and missing-session coverage. Keep overlapping sessions and daylight-saving transitions explicit.
The session-comparison method shows how to retain opportunity counts and avoid treating a small bucket as a verdict. The best-looking historical session becomes a candidate for an unchanged holdout, not an automatic ban on every other time.
Case 3: Post-Loss Sequence Audit—Observe, Don’t Diagnose
Unsafe version: label every rapid entry after a loss “revenge,” remove it, and attribute the difference to psychology. A timestamp and previous loss can identify a sequence; they cannot establish motive.
Test: freeze the sequence window, eligible prior outcomes, setup requirements, session state, and whether the next trade was already planned. Compare post-loss entries with matched control entries under the same setup and market conditions. Review notes or plan deviations separately from P&L. An entry can be plan-compliant after a loss, and a rule-breaking entry can win.
The revenge-trading cost audit distinguishes observed policy cost from an unsupported psychological causal claim. The forward control should be an objective pause, review, or authority rule—not a retroactive label chosen because the next trade lost.
Case 4: Frequency Filter Audit—Authority Before Count
Unsafe version: cap every trader at a fixed number of trades per day because a historical curve improved after removing later trades. The count may proxy for a session change, a different setup mix, rising costs, one volatile day, or simple outcome sorting.
Test: define an eligible opportunity independently of outcome. For each decision ordinal within the declared session, report opportunity count, taken and skipped decisions, setup quality evidence, exposure, costs, and rule state. Test the cap as one candidate among logged alternatives, and preserve what it would have rejected—including winners.
A practical forward cap can still be a risk or attention control even when no return improvement is proven. The overtrading protocol separates frequency drift, exposure drift, and process violations so a simple count does not carry more meaning than the evidence supports.
Case 5: Combined Filter Audit—Freeze, Then Hold Out
Unsafe version: choose the best setup, session, post-loss window, and daily cap from the same ledger, stack them, and call the resulting curve a “full optimization.” Each extra choice increases the search space; the final combination is selected with the greatest hindsight.
Test: separate discovery from validation:
- Use the discovery period to identify one operationally plausible rule.
- Record all alternatives tried and why this one was selected.
- Freeze definitions, thresholds, costs, and exception handling.
- Apply the rule to an untouched holdout or later prospective period.
- Do not reopen the discovery window when the holdout disappoints.
- Only after a verdict, authorize the next version with a new identifier.
The combined test should show an attrition waterfall: baseline eligible decisions, removed by each rule in fixed order, unknowns, retained decisions, and overlap between filters. Without that waterfall, the same trade can appear “fixed” by several rules and exaggerate the apparent contribution of each.
Metrics That Belong in Every Before/After Table
| Layer | Report | Why |
|---|---|---|
| Coverage | Eligible, included, excluded, unknown, missing, duplicate | Prevents a clean chart from hiding absent data |
| Activity | Trades, active days, opportunities, decision ordinal | Separates frequency from market access |
| Economics | Gross, each cost component, net, currency basis | Shows whether the filter survives implementation costs |
| Risk path | Declared drawdown method, exposure, largest loss, loss clustering | Keeps risk visible beside return |
| Uncertainty | Denominators, dispersion, dependence, trial count, holdout status | Stops a point estimate from becoming a universal claim |
| Operations | Rule breaches, missed decisions, overrides, data corrections | Tests whether the filter can actually be executed |
A smooth filtered equity curve is not “visual proof.” Open the removed rows, document why the filter knew to reject them before outcome, and keep an audit trail of every correction. The complete trade-review workflow provides the evidence-to-action sequence.
Supported, Inconclusive, or Rejected
- Supported: the frozen rule was operationally executable, evidence coverage passed, the holdout or prospective result met the prewritten criterion, and no known alternative explanation overturns the decision.
- Inconclusive: coverage, opportunity count, cost data, comparability, or evidence volume cannot answer the decision. Collect the missing evidence without changing the rule mid-test.
- Rejected: the rule failed its prewritten criterion, could not be applied consistently, or its apparent historical benefit did not survive validation.
“Inconclusive” is productive. It prevents weak evidence from becoming a permanent restriction and tells you exactly which field or comparison the next review needs.
Run the Filter Audit in TSB
Trader’s Second Brain can keep the original executions, source identity, available fees, setup and session labels, notes, screenshots, corrections, exclusions, and plan versions in one evidence trail. Preserve the baseline view before filtering, save the exact filter definition, and keep removed trades accessible. A result is useful only when the reader can move from the summary back to every included, excluded, and unknown row.
Coach makes this workflow substantially more powerful. Ask it to review a selected evidence set, identify supported differences, expose missing labels or thin buckets, and produce a bounded next test. Its evidence guard is the advantage: it should not turn “post-loss” into a motive, “untagged” into a bad strategy, or one filtered curve into a promise. That discipline makes the answer traceable enough to act on.
TSB has processed 600K+ imported trades across its import history, and its canonical registry recognizes 328 exact broker, exchange, platform, and prop-export profiles. Those are imported trades and recognized routes—not users, a database of these five cases, a universal sample threshold, or trades analyzed by Coach.
Turn a pretty curve into an auditable decision. Import and reconcile a representative history, write the rule and verdict in your Trading Plan, then ask AI Coach to review the frozen evidence set.
3 Mistakes Traders Make With Before/After Analysis
Mistake 1: Implementing Multiple Filters Simultaneously
A simultaneous change may be a valid risk intervention, but it cannot identify which filter mattered. If attribution is the goal, freeze one change or use a declared multivariate design with enough evidence.
Mistake 2: Treating a Historical Month as Permanent
One period can be dominated by regime, instrument, or a few dependent trades. Preserve the finding as a dated result under a specific rule version, then validate forward.
Mistake 3: Using These Tests as Performance Targets
The five tests are methods, not expected improvement ranges. Your filter may improve, worsen, or leave results unresolved. Never tune a threshold until it reproduces somebody else’s headline.
Who Should Skip Before/After Analysis (For Now)
- Journals with missing executions, unreconciled duplicates, or incomplete cost data.
- Setup labels created after outcomes were reviewed and without decision-time evidence.
- Strategies whose rule version changed repeatedly inside the proposed comparison.
- Traders looking for permission to increase risk rather than test one bounded process rule.
Repair collection first. Filtering bad coverage creates a precise answer to the wrong dataset.
Methodology Note
- Factual correction: the prior five “real case studies” had no auditable source ledger in the bundle; the title and examples now identify reproducible audit tests instead.
- Research boundary: data-snooping and backtest-overfitting research supports logging trials and using untouched validation; it does not prescribe a universal retail-trade sample size.
- Counterfactual boundary: subtracting recorded trades does not simulate changed future behavior or establish psychological causation.
- Product boundary: available fields depend on the exact import route and the trader’s own labels; reconciliation precedes analysis.
Final Verdict: “Less Is More” Is a Hypothesis, Not Proof
A good filter does not merely delete losers. It identifies a decision-time condition, applies it to the complete eligible population, keeps unknowns visible, survives all costs, and remains useful on data that did not choose it.
Run the five audits to find a candidate rule. Freeze it. Validate it forward. If the result is inconclusive, improve the evidence; if it fails, reject it. The outcome worth keeping is not the smoothest historical curve—it is a rule whose evidence, authority, and limitations remain visible after the chart closes.
Disclosure: Trader’s Second Brain is our product. Product-scale values are rendered from canonical server truth. This guide is educational, uses no customer case study, and does not promise that filtering will improve performance.