NHL Player Props Data Audit — Council Ruling

Date: 2026-04-01 Process: Full 5-phase council (Advisory → Anonymization → Peer Review → Chairman Synthesis → Boss Ruling) Advisors: Opus, Sonnet, Gemini 3.1 Pro, Grok 4.20 Reasoning, gpt-oss-120b Winner: Opus (3 of 5 peer review votes) Status: PENDING BOSS RULING on open questions

COUNCIL SUMMARY

Where Advisors Agreed

1. Player game logs are the #1 missing data — need per-game G, A, P, SOG, TOI, PP TOI from NHL API
2. EWMA at player level is essential — with separate decay rates per stat type
3. Poisson for goals, Negative Binomial for SOG — consensus on distribution models
4. Power play unit tracking is critical — PP1 vs PP2 assignment changes prop projections by 30-65%
5. Saves props need opponent shot volume as primary input — not just goalie SV%
6. Matchup cards must separate skater format from goalie format
7. Minimum sample thresholds before any scanner fires (10+ games suggested)
8. 7 separate edge scanners — one per prop market type

Where Advisors Disagreed

1. Player vs goalie history: Gemini says "mathematically toxic, drop completely." Other 4 say use with regression to mean and minimum sample thresholds. Council verdict: Use with minimum sample (15+ shots) and Bayesian regression — do NOT drop.
2. Points distribution: gpt-oss proposes additive delta that can go negative (breaks Poisson). Opus uses convolution of goals + assists. Sonnet uses Monte Carlo with correlation. Council verdict: Monte Carlo with ~0.4 correlation is most practical.
3. Database engine: gpt-oss recommends PostgreSQL, Gemini's schema was broken (missing prop_type column on EWMA table). Council verdict: SQLite WAL is sufficient for current scale.

Strongest Arguments (from peer review)

Opus wins with the most production-ready design:

• Correct distribution assignments per prop (ZIP for goals, NB for SOG, convolution for saves)
• Scanner firing order (team-level first, then skater props) prevents async errors
• Exact API endpoints specified (NHL API, MoneyPuck CSV paths)
• Full SQL DDL schema with proper data types and foreign keys
• Comprehensive matchup card with goalie confirmation status at the top

Biggest Blind Spot (4/5 reviewers)

Gemini: Categorically rejected player-vs-goalie matchup history as "mathematically toxic." This is overconfident and wrong — the correct approach is minimum sample thresholds with Bayesian regression, not deletion. Also, Gemini's EWMA table schema was broken (no prop_type column).

What Everyone Missed

1. Empty net dynamics — 10-15% of goals scored on empty nets. EN minutes inflate Goals/Points/SOG. Must calculate P(close game) and adjust 3rd-period conversion rates.
2. Kalshi order book liquidity — Kelly sizing on thin exchange is dangerous. Must ingest bid/ask depth and constrain sizing to available liquidity.
3. Portfolio-level correlation — Multiple props on same player are NOT independent bets. Need correlation matrix and aggregate exposure limits.
4. In-season regime changes — Mid-season coaching changes, line reshuffles, and trade deadline moves structurally break historical baselines.

BUILD PLAN

Phase 1: Player Data Tables

nhl_player_game_logs:

• player_id, player_name, team, opponent, date, game_id
• goals, assists, points, shots_on_goal, toi_seconds, pp_toi_seconds
• line_assignment (1/2/3/4), pp_unit (PP1/PP2/None)
• ev_goals, ev_assists, pp_goals, pp_assists, sh_goals
• Source: NHL API /v1/player/{id}/game-log/

nhl_player_baselines:

• player_id, date, stat_type (goals/assists/points/sog/saves)
• last_5, last_10, last_20, season_avg
• ewma_010, ewma_012, ewma_015 (3 decay rates tracked)
• per_60_rate, pp_per_60_rate
• games_played (for minimum sample check)

nhl_player_matchup_context:

• player_id, opponent_team, opponent_goalie_id
• career_shots_against, career_goals_against (for BvP matchup)
• sv_pct_against (goalie's SV% vs this specific player)
• sample_flag (adequate/low/insufficient based on 15-shot threshold)

Phase 2: Prop-Specific Metrics

Custom metrics to compute:

Phase 3: Distribution Models Per Prop

Phase 4: Edge Scanner Architecture

Common scanner engine:

1. Ingest FanDuel alt lines (3+ thresholds required)
2. De-vig each threshold (multiplicative 2-way)
3. Fit distribution curve to de-vigged probabilities
4. Compare fitted curve to Kalshi contract prices
5. Calculate edge after 7% Kalshi fee
6. Apply minimum edge (4 cents) and minimum sample (10 games) gates
7. Output: {player, prop_type, threshold, model_prob, kalshi_price, edge, confidence}

Per-prop scanner differences:

Phase 5: Matchup Card Format

(See Research Pipeline ruling for full card format — same cards serve both rulings)

Phase 6: Dashboard

• Slate overview with edge count per game per prop type
• Player detail page: card + all 7 prop edges + form charts
• Edge alerts sorted by magnitude, filterable by prop type
• Historical prop results for calibration (Brier scores per prop type)
• P&L by prop type, by edge bucket

OPEN QUESTIONS FOR BOSS RULING

1. Player vs goalie matchup history: Council says use it with 15+ shot minimum and Bayesian regression. Confirm?

2. Empty net modeling: Should we explicitly model P(empty net game state) and adjust 3rd-period scoring rates, or is this over-engineering for now?

3. In-season regime detection: Should the system auto-detect coaching changes, line reshuffles, and trade deadline moves and reset baselines? Or just let EWMA naturally adjust?

4. Data history depth: How far back for player game logs? 2 seasons? 3 seasons? (Gemini said 2 years, others said 3+)

5. EWMA decay rates: Track all 3 (0.10, 0.12, 0.15) as decided for team-level, or pick one for player-level props?

COUNCIL METADATA