- Joined
- Jul 11, 2008
- Messages
- 1,940
- Reaction score
- 185
- Points
- 63
You cannot analyse fifty fixtures properly. Nobody can. The bettors who try end up with shallow analysis across everything rather than serious analysis across anything, which produces exactly the results you'd expect - a lot of bets, poor average CLV, and a vague sense that everything is slightly underperforming.
The solution isn't to arbitrarily reduce your scope. It's to build a screening process that identifies which fixtures within your scope deserve serious attention this week, based on the specific conditions your analytical framework identifies as opportunity-generating. The screen is not the analysis. It's the triage that makes the analysis possible.
An LLM-assisted screen doesn't replace this judgement - it accelerates the first pass. What used to take two to three hours of manual data checking to identify which fixtures warranted deeper attention now takes thirty to forty minutes. The analysis that follows is still yours. The screen just stops you spending forty-five minutes on a fixture that had nothing in it from the first line of data.
This is how to build it.
The Failure Mode You're Building Against
Name it first, because it's common enough that it deserves a warning before anything else.
The failure mode is the screen becoming a betting system. You build a screen that flags fixtures with certain characteristics. You start placing bets on everything the screen flags. The screen was never designed to do that - it was designed to identify fixtures worth analysing, not fixtures worth betting. But the shortcut is tempting, especially after a few weeks where the screen flags something and the subsequent analysis confirms a bet and the bet wins.
The screen-as-system fails for the same reason any mechanical system built from a short characteristic checklist fails. The variables that make a fixture worth looking at are not the same as the variables that confirm an edge once you've looked. A fixture with referee assignment data suggesting elevated card rate and a team with squad depth concerns is worth analysing. It is not automatically a bet. The analysis determines whether there's genuine edge at the current price. The screen only determines whether the analysis is worth running.
If you track your results separately - bets that came through the screen versus bets you identified without it - you'll notice that the screen itself has no edge. The edge is in the subsequent analysis. Keep that distinction clear throughout, and revisit it any time you find yourself placing a bet based on screen output alone.
What Makes a Good Screening Criterion
Not every analytical input that matters for a bet makes a good screening criterion. A good screening criterion has three properties.
It's quickly assessable from publicly available data. The screen is a first pass - it needs to run fast. A criterion that requires thirty minutes of FBref querying to evaluate is not a screening criterion, it's analysis. The screen should use data you can pull in seconds per fixture.
It's genuinely discriminating. A criterion that flags seventy percent of fixtures in your scope isn't useful - it hasn't narrowed the field meaningfully. A criterion that flags fifteen to twenty percent is doing triage work. If your current criteria flag too many fixtures, tighten the thresholds. If they flag too few, you're leaving opportunities unexamined.
It correlates with your documented edge patterns, not with betting narrative. The screen should reflect where you've actually found CLV historically, not where betting commentary suggests there ought to be value. If your CLV tracker shows you've consistently beaten the market in fixtures with referee tenure mismatches and squad rotation ahead of European fixtures, those are your screening criteria. The popular narrative variables - revenge fixtures, managerial honeymoon periods, derby motivation - are for other people's screens.
Building Your Criterion Set
Five to eight criteria covers most analytical frameworks adequately. Fewer than five and the screen isn't discriminating enough. More than eight and you're running a multi-variable model rather than a first-pass filter, which defeats the purpose.
The criteria that work well as screening inputs - quickly assessable, discriminating, and tied to documented edge patterns - tend to fall into four categories.
Referee assignment signals. Is a referee assigned to this fixture whose card rate, foul tolerance, or added time behaviour sits more than one standard deviation from the competition average? This is quickly assessable once you have the referee database the earlier article described. Flag the outlier officials, don't flag the middle of the distribution.
Squad situation anomalies. Does either team have documented injury to a key positional player - specifically a player whose absence is known to affect the market's usual assumptions? Set piece specialist absent, first-choice goalkeeper unavailable, primary press-trigger striker missing. These are quickly assessable from the official injury list and the press conference transcript filter. Not all injuries qualify - only the ones whose mechanism affects the market at the level your framework operates.
xPoints divergence flags. Is either team showing a significant gap between their xPoints position and their actual position in the table? The xPoints article gave the rough threshold - five points over eight matches as the level where the signal is worth taking seriously. A team sitting third but with xPoints suggesting eighth-place quality is a fixture worth screening in. A team in mid-table whose xPoints position matches their actual position is not.
Fixture congestion and rotation signals. Is either team playing a fixture within seventy-two hours of another, or returning from European competition, or entering a run of six fixtures in eighteen days? These are quickly assessable from the fixture calendar and they affect the market in ways the headline odds often don't fully account for.
Those four categories, turned into specific yes/no questions per fixture, are the skeleton of the screen. Add one or two criteria specific to your own edge patterns - if you've found consistent CLV in promoted team early-season fixtures or in Championship relegation six-pointers under specific conditions, those belong in your screen - and you have a criterion set worth encoding.
Encoding the Criteria as Prompts
The weekly screening workflow has two stages. Data aggregation, then LLM processing.
For data aggregation, you're pulling three things before you touch a prompt. The fixture list for your scope, with kick-off times and referee assignments where available. The current official injury and availability lists for teams in your scope, from club websites and official league channels. The current standings table with points, and a separate xPoints table from a source like Understat or FBref for competitions that carry it.
Pull all three once, paste them into a working document, and then run the screening prompt against that document. Don't run separate prompts per fixture - that's slow and produces inconsistent output formats that are hard to compare across the weekend's fixtures.
The screening prompt:
"I'm going to paste three data sets: the fixture list for this weekend, the current injury and availability information for teams in these fixtures, and the current standings with xPoints data. Apply the following screening criteria to each fixture and flag any fixture that meets two or more criteria. Criteria: (1) Referee assigned whose documented profile includes card rate or foul rate more than one standard deviation from competition average - I'll note these referees in the data. (2) Either team missing a player classified as a set piece delivery specialist or first-choice goalkeeper. (3) Either team showing an xPoints gap of five or more points from their actual points position over the last eight matches, in either direction. (4) Either team playing within seventy-two hours of a previous fixture or returning from European competition this week. (5) [Your additional criterion specific to your edge patterns]. For each flagged fixture, list which criteria it meets and one sentence on why each criterion applies. Do not add analysis beyond the criterion check - I will do the analysis. Format as a list: fixture name, criteria met, brief reason for each."
The "do not add analysis" instruction is the structural boundary that prevents the screen from becoming a recommendation engine. The model will want to add context and implication if you don't stop it - and that context, presented at the screening stage before you've done the analysis, is exactly how the screen-as-system failure mode gets started.
The two-or-more-criteria threshold is adjustable. In a busy weekend with fifty fixtures in scope, two criteria flags roughly twelve to eighteen fixtures for closer examination - a manageable number for serious analysis. If you're running a tighter scope or want a higher signal threshold, move to three criteria. If you're finding the screen flags too few fixtures and you're missing opportunities, move to one.
Reading the Screen Output
The output is a list of flagged fixtures with the specific criteria each meets. Your job with this list is two things: validate the flags and prioritise the analysis.
Validation means quickly checking whether the flag is correct before you invest analysis time in it. The referee assignment flag is usually correct if your referee database is current. The injury flag is worth cross-referencing against the press conference transcript you've already pulled - sometimes the official injury list lags behind what the manager said in Thursday's session. The xPoints flag is worth checking against the competition calendar - a team with a flattering xPoints divergence who's been playing a soft run of fixtures should be discounted relative to one whose divergence has accumulated against a mixed schedule.
Prioritisation means ranking the validated flagged fixtures by how many criteria they meet and by how closely the criteria align with your specific documented edge patterns. A fixture meeting three criteria including the referee signal and the squad anomaly is higher priority than one meeting two criteria where one is marginal. You're ordering your analysis workload for the week, not producing a betting list.
The output of this step is typically six to ten fixtures that warrant serious analysis, ranked by priority. That's the right number. Six fixtures with thorough analysis produces better decisions than forty fixtures with shallow analysis. The screen has done its job.
The Weekly Maintenance Requirement
The screen is only as good as the data it processes. Three maintenance tasks keep it functional.
Referee database updates. The earlier article covered the monthly update cycle. If an official has had a notable decision in the past week that's generated coverage - whether positive or negative - run the qualitative extraction prompt on the match reports from that fixture and update the profile. Referee tendencies drift slowly but they do drift, and a profile that's two months stale for an official with thirty fixtures in that window is worth refreshing.
Criterion review. Every six to eight weeks, run a retrospective against your CLV tracker. Of the fixtures the screen flagged over the past two months, which ones produced positive CLV after analysis? Of the fixtures it didn't flag, did you manually identify opportunities that the screen should have caught? The retrospective tells you whether your criteria are discriminating in the right direction or whether they need adjustment. A criterion that flags a lot of fixtures but correlates weakly with positive CLV outcomes is worth replacing or tightening. One that almost never fires but consistently correlates with your best CLV results is worth loosening.
Data source reliability. The official injury lists are sometimes incomplete or delayed. Club websites for lower-league teams are sometimes updated intermittently. If you notice the screen is consistently missing a type of information that matters for your criteria, add a manual check for that information type before running the prompt.
What the Screen Can't Do
It can't catch the genuinely novel situations - the ones where no standard criterion applies but something unusual is happening that creates an edge. A managerial sacking confirmed at noon on Friday, a fixture relocated for security reasons, a sudden weather event that changes the expected game environment significantly. These require human attention to the news cycle that the screen doesn't provide. The screen is built from structured data. Unstructured breaking developments bypass it entirely.
It also can't account for the interaction between criteria. A fixture that meets the referee assignment criterion and the squad anomaly criterion might have those two factors pulling in opposite directions - an aggressive referee whose tendency is high-card matches, combined with an attacking player missing whose absence reduces the likelihood of the match reaching the confrontational moments that typically trigger that referee's card behaviour. The screen flags the fixture. The analysis determines whether the criteria are additive or cancelling.
That's the right division. The screen surfaces. The analysis interprets. Keep those as separate stages and the tool works. Collapse them and you've built yourself a mechanical system dressed up as a research process.
Anyway. The setup takes a few hours - building the criterion set, calibrating the thresholds against your scope, writing the screening prompt in the format that produces clean output. After that it's thirty to forty minutes per week. The return on that investment is recovered in the first weekend where you would otherwise have spent three hours on a manual first pass that produced the same six flagged fixtures the screen identifies in twenty minutes.
The analysis after the screen is still the hard part. It's supposed to be. The screen just means you spend the hard part on the right fixtures.
FAQ
Q: How do I handle competitions where xPoints data isn't publicly available?
Drop that criterion for those competitions and replace it with something assessable from data you do have. Recent form differential over the last five matches is a weaker proxy but a quickly assessable one. Alternatively, accept that the screen operates on three criteria rather than four for competitions with thinner data coverage - the threshold for flagging adjusts accordingly. Don't try to approximate xPoints from raw results data; the approximation introduces enough noise that the criterion becomes less useful than form differential anyway.
Q: Can the screen cover in-play betting opportunities as well as pre-match?
Not in the form described here. Pre-match screening runs on data that's stable enough to process in batch before the weekend. In-play opportunities are situation-specific and time-pressured in ways that don't suit a batch screening workflow. The in-play opportunities that come from the pre-match screening are the scenario planning elements - knowing in advance that a specific fixture has a referee whose behaviour changes in the sixty-fifth minute with a lead, so you've pre-planned what that situation looks like when it arrives. The screen surfaces the fixture. The scenario planning covers the in-play application. Those are separate steps.
Q: My scope is small enough that I already know which fixtures deserve attention each week without a screen. Is this worth building?
Probably not, or at least not yet. The screen is valuable when the ratio of fixtures in scope to available analysis time is high enough that informal prioritisation is losing you something. If you cover two competitions with ten fixtures each and you have fifteen hours per week, you have enough time to look at everything seriously without needing a triage layer. Build the screen when scope expansion or time reduction makes informal prioritisation visibly insufficient - when you're noticing that you're skipping fixtures you shouldn't be skipping or spending time on fixtures that aren't worth it. The tool solves a specific problem. If the problem isn't present yet, the tool is overhead without payoff.
