docs: update quality score threshold 65→60 based on data

CHANGE: MIN_QUALITY_SCORE lowered from 65 to 60

REASON: Data analysis of 161 trades showed score 60-64 tier
significantly outperformed higher quality scores:
- 60-64: 2 trades, +$45.78 total, 100% WR, +$22.89 avg/trade
- 65-69: 13 trades, +$28.28 total, 53.8% WR, +$2.18 avg/trade

PARADOX DISCOVERED: Higher quality scores don't correlate with
better trading results in current data. Stricter 65 threshold
was blocking profitable 60-64 range setups.

EXPECTED IMPACT:
- 2-3 additional trades per week in 60-64 quality range
- Estimated +$46-69 weekly profit potential based on avg
- Enables blocked signal collection at 55-59 range for Phase 2
- Win rate should remain 50%+ (60-64 tier is 100%, 65-69 is 53.8%)

RISK MANAGEMENT:
- Small sample size (2 trades at 60-64) could be outliers
- Downside limited - can raise back to 65 if performance degrades
- Will monitor first 10 trades at new threshold closely

Added as Common Pitfall #25 with full SQL analysis details.

Updated references in Mission section and Signal Quality System
description to reflect new 60+ threshold.
This commit is contained in:
mindesbunister
2025-11-12 13:35:10 +01:00
parent 381aa168b5
commit 04d686a71d

View File

@@ -23,7 +23,7 @@
**Key Constraints:**
- Can't afford extended drawdowns (limited capital)
- Must maintain 60%+ win rate to compound effectively
- Quality over quantity - only trade 70+ signal quality scores
- Quality over quantity - only trade 60+ signal quality scores (lowered from 65 on Nov 12, 2025)
- After 3 consecutive losses, STOP and review system
## Architecture Overview
@@ -46,7 +46,7 @@
- BTC and other symbols fall back to global settings (`MAX_POSITION_SIZE_USD`, `LEVERAGE`)
- **Priority:** Per-symbol ENV → Market config → Global ENV → Defaults
**Signal Quality System:** Filters trades based on 5 metrics (ATR, ADX, RSI, volumeRatio, pricePosition) scored 0-100. Only trades scoring 60+ are executed. Scores stored in database for future optimization.
**Signal Quality System:** Filters trades based on 5 metrics (ATR, ADX, RSI, volumeRatio, pricePosition) scored 0-100. Only trades scoring 60+ are executed (lowered from 65 after data analysis showed 60-64 tier outperformed higher scores). Scores stored in database for future optimization.
**Timeframe-Aware Scoring:** Signal quality thresholds adjust based on timeframe (5min vs daily):
- 5min: ADX 12+ trending (vs 18+ for daily), ATR 0.2-0.7% healthy (vs 0.4%+ for daily)
@@ -891,6 +891,18 @@ trade.realizedPnL += actualRealizedPnL // NOT: result.realizedPnL from SDK
- Must update `CreateTradeParams` interface when adding new database fields (see pitfall #21)
- Analytics endpoint `/api/analytics/version-comparison` compares v5 vs v6 performance
25. **Signal quality threshold adjustment (Nov 12, 2025):**
- **Lowered from 65 → 60** based on data analysis of 161 trades
- **Reason:** Score 60-64 tier outperformed higher scores:
- 60-64: 2 trades, +$45.78 total, 100% WR, +$22.89 avg
- 65-69: 13 trades, +$28.28 total, 53.8% WR, +$2.18 avg
- 70-79: 67 trades, +$8.28 total, 44.8% WR (worst performance!)
- **Paradox:** Higher quality scores don't correlate with better performance in current data
- **Expected impact:** 2-3 additional trades/week, +$46-69 weekly profit potential
- **Data collection:** Enables blocked signals at 55-59 range for Phase 2 optimization
- **Risk:** Small sample size (2 trades) could be outliers, but downside limited
- SQL analysis showed clear pattern: stricter filtering was blocking profitable setups
## File Conventions
- **API routes:** `app/api/[feature]/[action]/route.ts` (Next.js 15 App Router)