This page and its machine-readable twin at GET /api/track-record are computed live from the same resolution ledger the engines log to — not a highlight reel. Pending picks, thin coverage, and losses are reported as plainly as wins.
How this is scored. Every pick is logged the moment it's produced — before the event resolves — with its stated probability and, for betting markets, the odds taken. A cron job grades each one against reality (candles for market calls, results feeds for sports/racing, settlement for prediction markets) and folds it into a rolling aggregate. Nothing here is written after the fact.
Why R-multiples, not raw win %. Win rate alone is gameable — a book of odds-on favourites posts a fat win rate with zero edge. The headline number is the R-multiple (return per unit risked): a loss is always −1R, a win is sized by the odds or the reward:risk of the levels taken. It can't be inflated by favourite-stacking.
Calibration. When we say "60–80% likely," that bucket should win close to that often across enough samples. The calibration table below shows exactly that, per probability bucket, computed from every graded pick — not just the good buckets.
Full machine-readable payload (same numbers, JSON): /api/track-record — free, no auth, no rate limit beyond generous crawl-friendly throttling.