Project Case Study · Sports Analytics · Constrained Optimization
XGalonso
Most fantasy sports models eventually hit a ceiling because they reduce the problem to predicting player performance. Fantasy games aren't prediction problems — they're decision problems, and no two managers are solving the same one. Imagine two Fantasy Premier League managers with the exact same squad before a gameweek: one says “Captain Haaland, don't sell Palmer, play a 3-5-2,” the other wants to maximize expected points. Most optimizers begin with the same underlying reasoning and only apply those preferences as filters afterward. XGalonso treats them as fundamentally different optimization problems from the start.
Python 3.12 · Polars · scikit-learn · FastAPI · Next.js 16 · uv
1. The idea
XGalonso is an ML-backed FPL decision engine. The product question is not “who will score the most points?” — it is “what should this manager do under their rules?” That means legal squad actions (transfers, XI, captain, bench) under real FPL constraints, scored against a HOLD baseline, with hard locks treated as filters so “keep Palmer” cannot be sold away for expected points.
The system ingests the official FPL API into immutable bronze snapshots, normalizes tidy tables, builds point-in-time features, trains component models, assembles points with pinned scoring rules, then recommends and explains. A parallel discovery loop searches for features that improve decisions under the active objective and reachable player pool.
2. Objective ≠ constraint ≠ belief
The contracts layer keeps three things that fantasy tools usually blur. An objective is what you are optimizing for — maximize expected points, chase a mini-league, protect a floor. A constraint is a hard rule — formation, locked players, budget, club limits. A belief is a manager override on a prediction — “I think Salah plays 90” — shown as raw versus adjusted, never silently overwriting the model.
That separation is structural: the optimizer runs constraint_filter before scoring, soft-scores candidates with objective_value, and keeps belief adjustments side by side. Preferences cannot trade against points by construction.
3. ML system architecture
The technical system preserves the manager's decision context all the way through: official FPL data becomes point-in-time features and component predictions; the constraint rail narrows the reachable player pool; the optimizer compares legal actions; and the result returns with an explanation rather than a bare ranking.
4. Component models + official scoring
Instead of predicting total points as one opaque target, XGalonso fits walk-forward HistGradientBoosting models for the scoring components FPL actually pays for: minutes, starts, goals, assists, clean sheets, goals conceded, saves, bonus, and yellow cards. Domain scoring then prices those expectations with the official FPL rules table taken from a pinned bootstrap snapshot — so a rule change does not silently poison historical labels.
5. Optimizer is the product
Prediction is an input. The product surface is advice: hold versus transfer, who to bring in, who starts, who captains. The optimizer exhaustively searches legal single transfers, scores each candidate against HOLD, and reports the opportunity cost of locks separately so a constraint's price is visible rather than buried in a black-box solution.
- Encode the manager. Compile natural-language or typed intent into objectives, constraints, and beliefs.
- Filter the feasible set. Drop illegal sells, formations, and budget breaks before any scoring.
- Search vs HOLD. Enumerate legal single transfers and compare each action to doing nothing.
- Explain the move. Attach reason codes from the same evidence used to predict.
6. Context-conditioned discovery
A feature that helps a points-maximizer is not always the feature that helps a mini-league chaser. Discovery measures candidates over the reachable player pool under active constraints, and accepts features by decision utility under the manager's objective — not by global RMSE alone. Hypotheses are compiled through a safe expression DSL (no eval), leakage-proofed, and walk-forward validated before they enter the registry.
Recent work such as LLM-FE (Abhyankar, Shojaee, Reddy) showed that feature engineering can be discovered iteratively rather than handcrafted end-to-end. XGalonso explores a similar idea, but the search itself is conditioned on the decision context: embeddings and clusters can reweight by objective, and measurements run on players the manager can actually reach.
7. Explanations
Recommendations ship with reason codes built from the prediction evidence panels — the same signals that drove the score, not a separate marketing narrative. When a lock costs expected points, that cost is reported. When a belief moves a player, raw and adjusted sit next to each other. The goal is a decision you can argue with, not a ranked list that pretends every manager wants the same thing.
Why it matters
If every manager runs the same prediction pipeline with preferences bolted on at the end, the model thinks like everyone else. XGalonso is an attempt to make the whole stack — representations, features, search, and advice — adapt to the manager's problem instead of forcing every manager through one global objective.
FPL is the first domain because the rules are public, the decisions are weekly, and the constraints are sharp. The architecture is meant to generalize: any setting where agents share a prediction surface but solve different constrained decisions can use the same objective / constraint / belief split and context-conditioned discovery loop.