Classify the combination first
| Combination | Main dependence question | Settlement question |
|---|---|---|
| Match result plus another match result | Shared team, competition, news or model error? | Does each market use the same period? |
| Result plus total goals in one match | Does score state connect both legs? | Is this an ordinary multiple or priced builder? |
| Player prop plus team result | Does player time affect both outcomes? | What participation rule applies? |
| Corners plus cards | Do tactics and game state connect the counts? | Which data provider and correction window settle? |
| Season outright plus match selection | Does the match materially change the season event? | Are both legs eligible to combine? |
OpenStax's definition of independence requires that one outcome not change the chance of another. Different matches are not automatically independent, and same-match outcomes frequently are not.
Product acceptance is evidence, not a probability model
bet365's related-contingency page explains one operator's distinction between rejected ordinary multiples and separately priced builder combinations. DraftKings' current market rules define product-specific same-game settlement.
If two cross-match selections are accepted at 1.70 and 1.90, the mechanical combined price is:
1.70 * 1.90 = 3.23
A GBP 10 winning return would be GBP 32.30. This does not establish that their probabilities can be multiplied.
Evidence map
For every leg, store the contract and evidence needed to test independence and settlement. OpenStax's independence rule and the operator examples above provide the basis for this inventory:
- Market, line, period and accepted price.
- Official result or named statistics provider.
- Model probability and information cutoff.
- Shared teams, players, competition states and data inputs.
- Conditional links to other legs.
- Void, push, non-runner and correction rules.
Betfair's current football rules illustrate how result, player, card and corner products can have different settlement definitions even within the same sport.
Verification sequence
- Write each leg as a precise event.
- Draw a dependence graph between events.
- Reject naive probability multiplication where an edge exists.
- Use a directly modelled joint event or conditional probabilities.
- Preserve any product-specific quoted price.
- Reconcile every leg and the final product result separately.
Next step
Use Correlated Parlay for the next part of this topic.
Align every information cutoff
scikit-learn's data-leakage guidance warns against using information unavailable at prediction time, and its TimeSeriesSplit documentation preserves chronological order during evaluation. Store the forecast timestamp and last available event for every input so a late lineup cannot enter a supposedly earlier forecast.
| Layer | Freeze with the decision |
|---|---|
| Contract | Market, line, period, price and settlement source |
| Football evidence | Team news, lineup, injuries, schedule and event data |
| Model | Version, parameters, training cutoff and probability output |
| Dependence | Shared causes, conditional links and joint method |
| Outcome | Official result, provider events, corrections and settlement |
OpenStax's probability framework supports a completeness check in which mutually exclusive joint states cover the event space and sum to one. Keep the accepted product price separate from the model probability, and exclude a combination from performance analysis when its frozen evidence cannot reconstruct a required leg.
Continue learning
- Next guide: Corners Accumulators
- Related guide: Correlated Parlays
Assumptions and limitations
The cross-match price example is illustrative. Acceptance does not prove fair pricing, independence or positive expected value. Eligibility and settlement vary by product and date.

