Expected points explained: inside the FPLRogue model

The short answer

xPts is a ranking and decision aid, not a score forecast. A central estimate of 7.91 means the weighted average across many plausible outcomes is 7.91; the player can still score two, twelve or another value. FPLRogue therefore exposes a floor, central estimate and ceiling to keep variance visible.

The metric or rule should always be read with its timestamp and scope. A methodology guide can remain useful for a season, but player examples change whenever fixtures, roles, prices or availability move. The permanent lesson is the decision framework; the numbers are a worked snapshot. Every annual refresh should preserve that separation.

FPL decisions combine prediction and constraint. A higher estimate may be unusable because of price, club limits, position or captaincy; a safer estimate may be preferable when the bench is weak. The guide therefore explains what the input means, how it changes and which other fields must be checked before it becomes an action.

A useful shorthand is to ask three questions: what does this input measure, what can change it, and what decision is it allowed to support? If any answer is missing, the number should remain context rather than become a recommendation. This discipline keeps model outputs, official facts and editorial judgement in their proper roles and makes the conclusion easier for another reviewer to audit.

How it works

The current engine uses Dixon-Coles 3.1 team ratings trained on recent results and expected goals. Each fixture supplies team scoring and conceding expectations plus clean-sheet probability. Player role, start probability and xMins determine opportunity. The xPts layer maps goals, assists, clean sheets, saves, bonus, cards and defensive contributions into current FPL scoring.

Inputs should be traceable from source to display. Official rules and prices come from FPL; fixture and player estimates come from the named model endpoint; current injuries and roles require fresh primary reporting. The article embeds a data snapshot so later readers can distinguish a contemporary example from a live recommendation.

Uncertainty is a feature of the calculation, not an error to erase. Starting status, substitution timing, scoring events and price movements all have multiple possible outcomes. A useful model weights those outcomes consistently and shows enough context for the editor to challenge an assumption. It should never upgrade a probability into a fact.

The calculation should fail visibly when a required input is missing. Defaulting an injured player to normal minutes, carrying an old club after a transfer or treating an unknown price as zero produces a precise-looking but unsafe result. Automation should return the draft to Needs review with a named warning. The editor resolves the evidence and reruns the dependency chain; dismissing the warning does not repair the estimate.

A practical example

Haaland's Gameweek 1 central estimate is 7.91 with a model floor of 6.02 and ceiling of 9.80. Across three matches the estimate rises to 24.63. Bruno's three-match estimate is 22.31. The model prefers Haaland, but the decision can still prefer Bruno when £3.5m improves the rest of the squad by more than the projected gap.

A practical comparison should keep the planning horizon constant and include opportunity cost. Compare like with like, then build the resulting squads. Small differences in a central estimate should not dominate a large difference in expected minutes, price or transfer flexibility. Record the reason for the final choice so the review is not rewritten after the result.

Sensitivity testing makes the example more robust. Remove the riskiest start, lower one expected-minute input or move a price by £0.1m, then check whether the decision changes. If a conclusion flips under a tiny adjustment, label confidence accordingly and preserve an easy pivot.

When communicating the example, use units consistently and round only for readers. Calculations can retain full precision while copy normally shows two decimal points for expected points, one for minutes and one for price. Explain any difference caused by rounding. Do not mix per-match and multi-Gameweek totals in the same ranking without an explicit label, because the figures can look directly comparable when they are not.

Common mistakes

Do not add certainty that the model does not claim. Do not compare players from snapshots generated under different assumptions. Do not ignore xMins, price or club limits. Do not call a small xPts edge decisive when the ranges overlap. And do not use the model after a transfer without refreshing team, fixtures and role.

The most common analytical mistake is mixing evidence captured at different times. A new injury update paired with an old projection can look current while retaining the old minutes assumption. Refresh the complete dependency chain or state the mismatch. The same applies when a player changes club: team strength, fixtures, role and competition all need recalculation.

Another mistake is judging the framework by one match. Football outcomes are noisy, and a low-probability event can occur without making the estimate irrational. Review calibration across repeated comparable cases. At the individual level, examine whether the decision used the available evidence correctly rather than whether the player happened to score.

Good uncertainty language is specific. Use 'the model estimates', 'currently listed', 'reported by' and 'confirmed by' according to the evidence state. Avoid 'will start', 'guaranteed rise' or 'certain return' unless the fact itself is guaranteed, which football selection rarely is. A concise qualification improves trust and does not weaken a recommendation that already has sound comparative evidence.

Decision checklist

Confirm the endpoint, captured time, model version and horizon. Compare central estimate with floor and ceiling. Check xMins and start probability. Verify price, position, team and availability. Evaluate captaincy and squad opportunity cost. Record the choice before the match, then review calibration over a meaningful sample rather than one outcome.

Before using the guide, confirm the season, official rule version, model version, endpoint, captured time and next review date. For a player decision, add current team, position, price, fixture horizon, xMins, availability and alternatives. For a transfer, include free transfers and the cost of waiting. For a published claim, retain the exact source URL.

The maintenance owner should review this page before each new season and after any material official rule or model change. Update examples visibly rather than silently changing their meaning. Keep prior model identifiers in archived articles so a later audit can reproduce what readers saw and distinguish editorial error from a model version change.

Archive the input payload or a compact receipt with every published example. At minimum retain source endpoint, access time, model identifier, horizon and the values displayed in the chart. That receipt allows a later correction without scraping an old page and supports honest post-Gameweek review. It also prevents a live API change from silently rewriting the factual basis of an existing article.

The guide should end with a worked audit: identify the input, quote its capture time, state the inference, name the decision and list the evidence that would reverse it. This short chain is understandable to a new manager and rigorous enough for an experienced reviewer. It also supplies a reusable test case for future automation. When a system update changes the result, compare the old and new receipts, explain the changed assumption and update the article's review date rather than overwriting history without a note. Readers should always be able to distinguish the durable method from the dated example and reach the current live tool for a fresh calculation.