Trader's Second Brain Trader's Second Brain

Before vs After Trade Filtering: 5 Journal Audit Tests

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 rule must be knowable before entry, cover every eligible opportunity, include costs, and survive an unchanged forward test. This correction replaces five unsourced “real case studies” with five journal audit tests you can reproduce on your own data.

Quick Answer

Use historical before/after analysis only to generate a hypothesis. Freeze the filter, population, trial count, costs, and verdict rule; then apply it unchanged to an untouched or later period. The five tests cover setup-label evidence, comparable sessions, post-loss sequences without psychological diagnosis, frequency authority, and combined-filter holdout validation. Report supported, inconclusive, or rejected—not “proven” from a smoother chart.

Your trades · one review system
Import → reconcile → review

Find the leak before the next trade.

Import or log trades. Find setup, session, and behavior leaks.

Find trade leaks →
Trader's Second Brain preview
Reading map

Three checkpoints in this guide

Follow the full walkthrough in order, or jump directly to one of its main sections.

  1. 01Opening checkpointThree Different “Before vs After” Questions
  2. 02Middle checkpointCase 5: Combined Filter Audit—Freeze, Then Hold Out
  3. 03Closing checkpointFinal Verdict: “Less Is More” Is a Hypothesis, Not Proof

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.

DesignWhat it computesWhat it cannot proveBest use
Historical subtractionRemoves tagged executions from one realized ledgerThat the tag was knowable before entry or behavior would stay unchangedHypothesis generation
Untouched holdoutApplies a frozen rule to data not used to choose itPermanent edge across future regimesInitial validation
Prospective trialRecords live or simulated decisions after the rule takes effectThat every difference was caused by the filterOperational 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:

  1. Decision: the exact future action the analysis may authorize.
  2. Population: account, instrument, setup version, dates, session definition, side, and status.
  3. Filter: a condition available before the decision point; post-outcome labels are diagnostic only.
  4. Coverage: eligible, included, excluded, unknown, missing, cancelled, skipped, and duplicate records.
  5. Economics: gross result, commissions, fees, financing, borrow, slippage, and currency conversion where applicable.
  6. Trials: every rule, threshold, combination, and segment inspected on this history.
  7. Validation: an untouched or later period and a date on which the frozen rule will be judged.
  8. 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.

OutputRequired evidenceInterpretation
Setup presentRule version plus pre-entry fieldsEligible for a strategy result
Setup absentEvidence that a required condition failedCan test an exclusion policy
UnknownMissing or ambiguous decision-time evidenceData-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:

  1. Use the discovery period to identify one operationally plausible rule.
  2. Record all alternatives tried and why this one was selected.
  3. Freeze definitions, thresholds, costs, and exception handling.
  4. Apply the rule to an untouched holdout or later prospective period.
  5. Do not reopen the discovery window when the holdout disappoints.
  6. 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

LayerReportWhy
CoverageEligible, included, excluded, unknown, missing, duplicatePrevents a clean chart from hiding absent data
ActivityTrades, active days, opportunities, decision ordinalSeparates frequency from market access
EconomicsGross, each cost component, net, currency basisShows whether the filter survives implementation costs
Risk pathDeclared drawdown method, exposure, largest loss, loss clusteringKeeps risk visible beside return
UncertaintyDenominators, dispersion, dependence, trial count, holdout statusStops a point estimate from becoming a universal claim
OperationsRule breaches, missed decisions, overrides, data correctionsTests 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 330 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.

Igor Manuilov
Written and reviewed by
Igor Manuilov
Founder of Trader's Second Brain · Trader since 2014
Editorial accountability

Trader since 2014. Built Trader's Second Brain to make execution review more evidence-based and less dependent on memory, scattered spreadsheets, or vague journaling.

Your trades · one review system
Import → reconcile → review

Your trade history already knows what to fix next.

Import or log trades. Find setup, session, and behavior leaks.

Find trade leaks →
Trader's Second Brain preview

Frequently Asked Questions

Quick answers to the most common questions about Before vs After Filtering.

No customer-level source ledger supported the old five ‘real case studies,’ so this corrected guide does not present them as typical results. The five sections are reproducible audit tests. A historical subtraction can be cherry-picked even when several filters point in the same direction, especially if many rules were tried on the same data. Log every trial, freeze one operational rule, and validate it on untouched or later evidence.

There is no universal number of days or trades. The evidence needed depends on opportunity frequency, dispersion, dependence between trades, cost completeness, filter prevalence, and the size of the decision. Define an untouched or prospective review window before starting. If coverage or comparable opportunities remain too thin at the review date, report inconclusive and continue collecting the frozen rule rather than moving the threshold.

You might. Historical subtraction mechanically improves net P&L only when the removed recorded subset was net negative under the declared cost basis, but a live filter can also reject winners, change attention, alter later opportunities, or fail in a new regime. Report retained and rejected opportunities, costs, exposure, and forward results. Fewer trades are better only when the unchanged rule produces a better decision outcome at acceptable risk—not by definition.

Do not relax a validated rule merely to create activity, but do not assume that a low count proves quality either. Check whether the filter reflects a real decision-time condition, whether opportunity capture is complete, and whether the remaining evidence can support the intended decision. If the strategy is genuinely sparse, adjust review cadence or test a separately defined setup—never add trades only to hit a quota.

Either is possible. A filter can stop working because market conditions, opportunity mix, execution costs, strategy rules, or implementation changed. Preserve the rule version and continue monitoring both compliance and cost-complete outcomes on scheduled dates. Do not choose the review interval after seeing a drawdown, and do not call every regression a discipline failure before checking data and comparability.

If attribution is the goal, change one frozen rule at a time or use a declared design that can identify interactions. A simultaneous risk intervention may still be justified, but then report the package as one version and do not claim which element caused the result. Predefine the review date and evidence requirement; no universal four-to-six-month sequence or benefit split applies.

Start with the decision whose failure is observable and operationally important—not automatically the historical filter with the largest P&L lift. Audit setup coverage, session comparability, post-loss sequences, and frequency authority; log every rule tried. Prioritize a rule that was knowable before entry, has adequate coverage, controls a defined risk or process problem, and can be tested unchanged on untouched or later data.