Level 4
12 min readLesson 22 of 43

The Edge Discovery Framework

How to systematically find edges that actually exist

You Don't Find Edges By Guessing

Most traders stumble onto strategies by accident. They read about RSI divergence somewhere, try it, see a few wins, and declare they've found an edge. Six months later, their account tells a different story.

Professional quant trading doesn't work that way. You don't find edges by guessing—you find them through systematic exploration.

This lesson introduces the framework we use to discover trading edges. Not hunches. Not indicator tips from Twitter. Real, statistically validated edges that survive contact with live markets.

Hypothesis-Driven vs Data Mining

There are two fundamentally different approaches to finding edges:

Hypothesis-Driven Discovery starts with a theory about why something should work. "Funding rates above 0.1% create selling pressure as longs pay to hold positions" is a hypothesis. You then test whether the data supports it.

Data Mining takes the opposite approach: scan massive amounts of data for patterns, then try to explain them afterward. "The 17-period RSI crossing below 23 on Tuesdays shows a 58% win rate" might be a data mining result.

Both approaches can work, but they have different failure modes:

Hypothesis-driven discovery can miss edges you wouldn't think to look for. Your mental model of markets might be incomplete or wrong.

Data mining can find patterns that are pure noise—statistical artifacts that exist in your sample but won't persist into the future.

Our approach uses both. We have hypotheses about what should work (based on market microstructure, derivatives mechanics, and flow dynamics), but we also systematically scan combinations to find edges we wouldn't have guessed.

The Discovery Pipeline

Edge discovery isn't a single step—it's a pipeline. Each stage filters candidates, and only the survivors move forward.

Stage 1: Data Preparation Before you can discover anything, you need clean, aligned, properly normalized data. We covered this in the Data level. Z-score normalization, regime labeling, and temporal alignment all happen here.

Stage 2: Candidate Generation This is where you generate potential edges to test. For us, this means systematically combining indicators:

  • Primary indicator threshold crossed
  • Secondary indicator confirmation
  • Direction (LONG or SHORT)
  • Holding period

A single indicator might have 10 meaningful threshold levels. Two indicators combined across two directions and five holding periods creates 10 × 10 × 2 × 5 = 1,000 candidates. That's from just two indicators.

Stage 3: Initial Backtest Run every candidate through your backtesting engine. Most will fail immediately—sub-50% win rates, negative expectancy, or too few samples. These get filtered out.

We typically eliminate 95%+ of candidates at this stage.

Stage 4: Validation Testing Surviving candidates get proper validation: walk-forward testing, out-of-sample periods, regime stress tests. This is where curve-fitted edges get exposed.

Another 80-90% typically fail here.

Stage 5: Robustness Checks Final survivors face robustness analysis: parameter sensitivity, minor threshold changes, different time windows. If small changes dramatically alter performance, the edge is fragile.

Stage 6: Paper Trading Edges that pass all backtest validation run on paper before getting real capital. This catches execution assumptions, data timing issues, and operational problems.

Only after all stages does an edge get promoted to live trading with real money.

The Indicator Combination Approach

Why combine indicators at all? Because single-indicator edges are almost always weak or non-existent in efficient markets.

Think about it: if buying when RSI drops below 30 worked reliably, everyone would do it, and the edge would disappear. Markets price in simple signals almost instantly.

But combinations are different. When funding rate z-score drops below -2 AND open interest is rising AND price is at a liquidation cluster—that's a specific confluence that requires understanding multiple data sources.

The combinatorial space is massive. With 50 indicators, 10 thresholds each, 2 directions, and 5 holding periods, you're looking at millions of potential combinations. You can't test these manually.

This is why systematic discovery requires code. You need to generate candidates programmatically, test them efficiently, and track results in databases.

Filtering False Positives

The biggest danger in edge discovery is false positives—patterns that look like edges but are actually noise.

With millions of candidates, you're guaranteed to find some that show 80%+ win rates purely by chance. If you flip a coin 1,000 times, you'll find stretches that look like a biased coin even though it's perfectly fair.

We handle this several ways:

Sample Size Requirements: We require minimum sample sizes (typically 500+ events) before considering an edge valid. More samples = less likely to be noise.

Walk-Forward Validation: The edge must work not just in-sample but out-of-sample. If it only worked historically, it might be curve-fitted.

Multi-Period Testing: Test across different time periods. Real edges should persist; noise patterns disappear.

Parameter Stability: If changing the threshold from 2.0 to 2.1 destroys the edge, it's probably overfitted to the exact parameter.

Economic Rationale: Can you explain WHY the edge should exist? Edges with clear market microstructure explanations are more likely to persist.

Documentation and Tracking

Every edge candidate needs proper documentation:

  • Discovery Date: When you found it
  • Data Period: What timeframe the backtest covers
  • Parameters: Exact thresholds and conditions
  • Results: Win rate, profit factor, sample size, Sharpe ratio
  • Validation Status: What tests it passed/failed
  • Notes: Any observations about behavior

We store all this in a database. When we discover a new edge, we can check if we've tested similar combinations before. When edges stop working in production, we can trace back to their discovery conditions.

Good documentation also prevents you from "rediscovering" the same edge repeatedly with slightly different parameters—a common trap.

The Numbers Game

Here's the reality: most candidates fail. Of millions of combinations tested, maybe 0.1% survive all validation stages.

This isn't a problem—it's the point.

You don't need thousands of edges. You need a handful of genuinely robust ones. Better to have 10 validated edges with 60% win rates than 100 untested edges that might be noise.

The discovery pipeline is designed to be brutal. False positives are expensive—they lose real money when deployed. Every filter, every validation test, every robustness check exists to kill weak candidates before they kill your capital.

What's Next

This lesson introduced the framework. In upcoming lessons, we'll dive into specific techniques:

  • Z-score normalization for indicator comparison
  • Regime filtering to find context-dependent edges
  • Combining indicators without redundancy
  • Testing millions of combinations efficiently
  • The promotion pipeline from discovery to live trading

Edge discovery is systematic work. It's not glamorous. Most of your time is spent filtering out noise. But the edges that survive are the foundation of profitable trading.

The goal isn't to find edges. The goal is to find edges that actually work.