Methodology

For a signal to enter evaluation, three conditions must simultaneously hold on the Binance Futures side:

• quoteAsset = USDT
• contractType = PERPETUAL
• status = TRADING

Any symbol failing these conditions is dropped to EXCLUDED and is never evaluated. The rule is fixed in code; an operator cannot override it manually. This prevents post-hoc statistics polishing.

Every signal has a single outcome: TP1, SL, TIMEOUT, or EXCLUDED. Evaluation walks candle by candle:

• TP1 won, price reached the take-profit target.
• SL won, price hit the stop-loss level.
• Both TP and SL triggered in the same candle, tie-break kicks in: SL wins (conservative interpretation). Most competitors pick TP in this case to inflate win rate. We do the opposite.
• TIMEOUT, neither TP nor SL was reached within the allowed horizon.

Evaluation runs are snapshot-based: an EvalRun can have only one RUNNING instance at a time. Recompute flows use full-pass semantics. A daily determinism check verifies that the same input always produces the same output.

Net bps = Gross return − Fees − Slippage − Funding. Every closed signal stores this decomposition explicitly in signal_evals.

• Fees (fees_bps): Binance Futures taker/maker fees applied per signal type.
• Slippage: instead of a static slippage_bps, we use a liquidity-aware dynamic slippage model (spread, depth, notional at entry).
• Funding: every funding event between open and close is accumulated. funding_bps_signed reflects the net flow with the correct sign for the signal's side.

Most competitor sites report gross only. That means you lose money in real trading relative to their published numbers. We only expose net.

Every signal that passes the quality gate flows through a tiered ML stack:

• Side-aware calibrator (LONG/SHORT), separate models; long and short have different dynamics.
• GBT shadow model, a gradient-boosted-tree challenger predicts every signal; not promoted directly, but compared against champion.
• Meta-blender, lane scores + calibrator outputs become a composite score.
• Regime-specific calibration, separate calibrators for trend / range / volatile.
• Feature drift monitor (PSI), tracks how far live features drift from training; on breach, calibrator retrains.

Autopilot v2 is a policy-driven self-tuning system. A two-hour cycle runs replay-based tuning:

• Candidate policy configurations are replayed across the historic candidate log (past market is re-lived for fast counterfactual analysis).
• Each candidate is scored by an objective: EV, PF, calibration, side balance, drawdown proxy.
• Best candidate passes canary precheck: change budget, risk guard, audit logging.
• After canary deploy, KPI deterioration triggers automatic rollback.

Policy JSON is type-safe via Zod. Kill-switch is a single command:worker_state.autopilot_enabled = false.

Two automatic protective mechanisms run 24/7:

• Eval Disagreement Guard: realtime vs terminal eval mismatches are classified (path_diff, data_gap, tie_break, late_tick,mark_anomaly). Threshold breach → strict EV + topN cap auto-applied; auto-recover when ratio normalizes.
• Throughput Guard: selection / candidate throughput below policy band triggers a starvation rescue patch, blocked when risk-off is active (risk discipline takes precedence).

All data comes from free sources:

• Binance Futures REST (exchange info, tickers, technicals)
• Binance Futures WebSocket (depth10, mark price, agg trades). 24/7 streamer container
• Our own database (signal_evals, signals, quality metrics, liqmap snapshots)

Monthly-subscription services such as LunarCrush, CoinGlass, Glassnode, and Kaiko are intentionally not used.

Every significant event is recorded:

• Every signal insert gets a fingerprint: code_git_sha, policy_hash, calibrator_artifact_id, quality_snapshot_at.
• Autopilot logs before/after + reason for every policy apply.
• Daily ops report (ops_reports): KPIs, funnel, reject reasons, incident list.
• Determinism check: same input → same outcome/net. Divergence becomes an incident.