TradeSight

TradeSight is designed to be a lightweight, self-hosted solution with no cloud dependencies, Docker, or Redis required. It runs on:

• Language: Python
• Web Framework: Flask
• Database: SQLite

TradeSight includes the following capabilities:

• Scanning: Supports Polymarket and US equities scanning.
• Technical Analysis: Automatically applies 15+ technical indicators.
• Paper Trading: Integrates with Alpaca (using a free account) for non-live testing.
• Automation: Uses cron for overnight strategy evolution.
• Dashboard: A web-based dashboard accessible at localhost:5000.
• Demo Mode: Allows testing the system without requiring any API keys.

A critical lookahead bias exists in the current BacktestEngine.run_backtest() implementation. The engine calls the strategy function with data.iloc[i], which includes the closing price of bar i, and then immediately fills the entry at that same close. This allows the strategy to 'know' the close before trading it, artificially inflating PnL.

To ensure realistic results, you must ensure that a signal generated at bar i is executed at the earliest possible price in the future (typically the open of bar i+1).

# Recommended Fix Pattern:
# Instead of filling at bar i's close:
# entry_price = data.iloc[i]['close'] 

# Use bar i+1's open:
entry_price = data.iloc[i+1]['open']

Strategies in TradeSight progress through a rigorous multi-stage lifecycle. A strategy must pass through several evidence gates (including out-of-sample testing, walk-forward analysis, Monte Carlo simulations, and forward-paper trading) before it can be promoted to a 'Champion' status. A challenger cannot promote automatically.

Lifecycle stages: Candidate → Backtest → Out-of-sample → Shadow paper → Qualified → Champion → Retired

When listening to the trade_updates stream, you must handle two distinct event types to track order execution: fill and partial_fill. Both events follow a similar structure within the order object. To ensure accurate accounting, you should accumulate partial fills before posting the final state to the MC activity endpoint.

// Example fill event shape
{
  "stream": "trade_updates",
  "data": {
    "event": "fill",
    "order": {
      "symbol": "AAPL",
      "filled_qty": 1,
      "filled_avg_price": 150.00
    }
  }
}
// Note: partial_fill uses event="partial_fill"

TradeSight uses a tournament-style genetic algorithm to evolve trading strategies overnight. The process follows these steps:

1. Define Base Strategy: You provide a starting point (e.g., RSI Mean Reversion).
2. Variation Generation: The system generates 100+ variations by mutating parameters such as thresholds, timeouts, and position sizes.
3. Backtesting: Each variation is backtested against historical market data.
4. Selection & Breeding: Losers are eliminated, and winning variations are used to breed the next generation of variations.
5. Reporting: A morning report is generated showing the 'champion' strategy along with full performance statistics (e.g., P&L, Sharpe ratio).

TradeSight uses specific labels to categorize the provenance and reliability of data. This ensures that unverified or synthetic data is not confused with broker-backed evidence.

• REAL: verified external market evidence.
• PAPER: broker-simulated trading evidence (e.g., from Alpaca paper endpoints).
• DEMO: explicit development-only synthetic data.
• STALE: retained data too old to support a current decision.
• UNVERIFIED: local evidence that has not met broker-proof requirements.

The current confidence scoring algorithm is flawed because it correlates confidence with volume/liquidity rather than price edge. High-volume markets that are near 50/50 (e.g., 0.48/0.52) are currently receiving high confidence scores, which produces false signals.

Correct Logic Pattern: Real opportunity should be defined as price mispricing + edge (e.g., the market implies a 35% probability, but your model estimates 60%). Confidence scoring should be based on the deviation of the market price from your 'fair value' estimate, rather than raw volume.

The Paper Trader includes several hardcoded safety guards and constraints to manage risk and diversification:

• Position Sizing Cap: Maximum position size is enforced at 15% (0.15) to ensure diversification.
• Cash Reserve Guard: A guard is in place to protect cash reserves.
• Stop-Loss Cooldown: A 7-day stop-loss cooldown is implemented to prevent re-entry loops after a loss.
• PDT Emergency Override: Includes an emergency override for 2x stop-loss and reduced position-size search ranges.
• Short-Side Restriction: Short-side signal generation is removed in the paper trader environment.