methodology

How every number here is calculated

Every stat on this site comes out of code you can reason about. Below, each one is explained in plain language first and then with the exact formula the app actually runs — including the places where the honest answer is "this is a proxy" or "this isn't proven."

Where a claim has been tested against real historical seasons, it links to the full writeup in the Edge Lab, which lists every factor that was tested — including the ones that failed.

1. Win Probability

Plain language: this is the market's opinion of how likely a team is to win, with the sportsbook's built-in profit margin stripped out. We take the moneyline price from every book that quotes the game, average them, convert that average to a probability, and then rescale both sides of the game so they add up to exactly 100%.

The real formula

Odds arrive in decimal form. Every book quoting a side is averaged into a single consensus price, and the implied probability is its reciprocal:

consensusDecimalOdds = mean(all books' decimal odds for that side)
rawWinProb = 1 / consensusDecimalOdds

Raw implied probabilities for the two sides of a game sum to more than 1.0 — that excess is the bookmaker's vig (the overround). De-vigging normalises both sides by that sum:

overround   = rawHome + rawAway          // e.g. 1.045
devigHome   = rawHome / overround
devigAway   = rawAway / overround        // devigHome + devigAway === 1.0

That de-vigged number is what the app displays as win prob. Source: src/lib/equity.ts (impliedProbability, devigTwoWay).

How many bookmakers are behind the number

"Consensus" only means something when several books are quoting the game. Coverage is very uneven across a season: on the live 2026 slate, Week 1 games are priced by around 10 US books, while Weeks 15–18 are currently quoted by only 1–2. A late-season number is therefore closer to one bookmaker's opinion than to a market average.

Rather than hide that, the real book count is stored with every price (books_count on each scored team) and shown next to win probability and equity on the board. When fewer than 3 books are quoting, the board says so in plain language instead of presenting the number with the same visual confidence as a 10-book average. This is a disclosure about the input data — not a derived confidence score (two attempts at building one failed calibration and were dropped).

2. Equity Score

Plain language: in a survivor pool you don't just want to win the week, you want to win the pool. If everyone picks the same 90% favourite and it wins, you've gained nothing on the field. Equity score nudges the ranking toward teams that are nearly as safe but less obvious.

The real formula

equity = devigWinProb − (LEVERAGE_WEIGHT × pickPopularityProxy)
LEVERAGE_WEIGHT = 0.25

The pick-popularity proxy — an approximation, not real data

There is no public, reliable feed of how a survivor pool's picks are actually distributed. Rather than invent one, the app uses a documented proxy: rank every team playing that week by de-vigged win probability and convert the rank to a 0–1 percentile (ties share the midpoint).

for each team p in the week's slate:
  lower = count(q < p)
  equal = count(q === p)
  proxy = (lower + (equal − 1) / 2) / (n − 1)

It is deliberately relative to the slate: a 75% favourite that is the biggest favourite of the week scores near 1.0, while the same 75% favourite in a week full of bigger favourites scores much lower. That is the whole point — it separates "chalk" from "merely favoured." But it is an estimate of obviousness, not observed crowd behaviour, and it should never be read as "X% of pools picked this team."

3. Path Survival

Plain language: picking a team burns it for the rest of the season, so the best pick this week is not always the safest team this week. Path survival takes the teams you have left, simulates the entire rest of the season thousands of times, and reports the probability that picking this team now still leaves you alive every remaining week.

How the simulation actually runs

Each trial replays a real decision policy week by week, because in a real pool you choose before you know results. For a candidate team the value is:

value(t) = p(t) × greedyTailValue(nextWeek, used ∪ {t})

That is a one-step exact lookahead over this week's candidates, with the remaining season valued by a scarcity-ordered greedy assignment: remaining weeks are sorted by their best available win probability, hardest week first, so the policy doesn't burn a team that a thin later week uniquely needs. Candidate comparisons use common random numbers, so differences between teams reflect the pick and not sampling noise. The dashboard runs 2,000 trials per board for responsiveness; the research runner uses 10,000.

4. ELO Rating

Plain language: the same chess rating idea applied to NFL teams. Every team starts equal, beating a strong team earns more points than beating a weak one, and points won by one side are exactly the points lost by the other. ELO is used here as a supporting signal and a research baseline — it never overrides the market win probability shown on the board.

The real constants

BASE_RATING           = 1500   // every team's first appearance
HOME_FIELD_ADVANTAGE  = 65     // added to home rating (0 at neutral sites)
K_FACTOR              = 20     // update speed per game
SEASON_REGRESSION     = 1/3    // pulled back toward 1500 each new season

expected = 1 / (1 + 10 ^ ((ratingAgainst − ratingFor) / 400))
delta    = K_FACTOR × (actual − expected)   // actual: win 1, tie 0.5, loss 0

65 rating points corresponds to about a 59% home win rate for two otherwise equal teams, close to the real 1999–2025 NFL average. K = 20 is the conventional NFL value: a 17-game season is short, so a bigger K overreacts to single games and a smaller K leaves ratings stale. The one-third off-season regression reflects roster turnover, coaching changes and the draft. Source: src/lib/elo.ts.