A Profit Factor of 2387 Isn't a Win -- It's a Sample Size of 57

My pipeline has a rule I wrote into it myself: a pair/family combination needs at least 30 real entry signals before it's eligible for LIVE_READY. Below that, it gets stamped NEED_MORE_DATA no matter how good the numbers look. I built that rule because I kept getting burned by exactly this problem. Looking back at one ranking pass -- 19 pairs, sorted by signal count -- the rule caught some of it. It didn't catch all of it.

Profit factor (PF) is gross profit divided by gross loss. Zero losing trades makes that division undefined, so my engine caps it at a flat 999.000 rather than reporting infinity. Three of my 19 ranked rows hit that cap exactly: LLYUSDT (6 signals, 100% win rate), BILLUSDT range_bounce (1 signal, 100% win rate), and MEGAUSDT range_bottom_reclaim (1 signal, 100% win rate). All three got the honest label: NEED_MORE_DATA. A PF of 999 on one trade means exactly one thing -- I haven't lost yet.

The ones that passed my own bar still look insane

That's the part that actually worries me. Two rows cleared the 30-signal minimum and got stamped LIVE_READY, and their profit factors are still absurd: 1000PEPEUSDT (volume_reversal, 57 signals, PF 2387.179, 98.2% win rate, net +65.4%) and 1000BONKUSDT (volume_reversal, 71 signals, PF 376.922, 94.4% win rate, net +79.2%). A third, 1000000MOGUSDT (volume_reversal, 44 signals, PF 334.776, 95.5% win rate), clears the bar too.

Look at the shape of that table. The two range_bounce rows that cleared LIVE_READY carry the most signals in the entire ranking -- 176 and 119 -- and the most boring profit factors, 2.576 and 1.717, with win rates near a coin flip. The three volume_reversal rows carry a third to half as many signals and profit factors in the hundreds, with win rates in the mid-to-high 90s. Every single row in this ranking follows the same direction: fewer signals, wilder number. I didn't have to cherry-pick to find that pattern -- it's all 19 rows, no exceptions.

Why volume_reversal produces this and range_bounce doesn't

I don't have the per-trade ledger open in front of me to point at the exact candle that did it, so I'll say this honestly rather than overclaim a mechanism I can't fully verify from the summary row alone. But the shape fits a known failure mode: profit factor has no ceiling on the win side and a hard floor on the loss side once a stop-loss is fixed. A handful of outsized meme-coin breakout trades -- these are 1000PEPE, 1000BONK, and 1000000MOG, not exactly low-volatility names -- can each contribute gross profit many multiples of what a single stopped-out loser costs. Run that through 44-71 signals instead of 150+, and a couple of lucky tail trades can dominate the whole PF calculation. The range_bounce rows with 3-4x the sample size have had more chances for a bad trade to show up and drag the ratio back toward something believable. That's not volume_reversal being a better strategy. It's volume_reversal having had fewer chances to be wrong yet.

What I actually do with a number like 2387

My 30-signal floor caught the most obvious cases -- the three rows sitting at the 999 cap didn't sneak into LIVE_READY. But it didn't catch the subtler version: a sample that's technically "enough" by my own rule while still being small enough for one fat tail to run the whole show. The fix I'm applying going forward isn't a bigger minimum-signal number. It's treating profit factor itself as a tell once it leaves a sane range -- anything north of maybe 10-15 gets flagged for a second pass with a much higher bar, same as NEED_MORE_DATA, instead of taking the LIVE_READY label at face value. A win rate pushing 98% is the same signal from the other direction: I run it through the win rate calculator against the actual risk/reward it was traded at, and if the required win rate on the breakeven win-rate calculator doesn't explain the gap, I don't trust the row. The boring rows with coin-flip win rates and PF under 3 are the ones I'd actually risk size on.