Should I Dodge clamps every win rate to 30-70%, converts it to log-odds, and sums allies against enemies rather than averaging — so a single champion's own number, at most ±0.847 log-odds, can only ever nudge the total, never dominate it; ten champions clamped at the extremes tops out around 99.98%, not certainty. A missing or unrecognised pick contributes exactly zero log-odds, not a penalty.
The clamp sets a ceiling on any one pick's influence
Should I Dodge clamps every champion's win rate to a range of 30% to 70% before doing anything else with it. What a win rate actually means covers why that range exists — a raw win rate outside it is almost always a small-sample artefact, a rarely-picked champion whose 90%-off-three-games number says more about sample size than about the champion. This article is about what the clamp does mechanically once it's applied, which is a step further than "it filters out bad numbers."
The clamp doesn't just remove outliers, it sets a hard ceiling on how much any single champion can move the final estimate, and that ceiling is a specific, computable number. A win rate of 70% converts to a log-odds value of ln(0.7 ÷ 0.3) ≈ 0.847 — and because the clamp bounds every champion symmetrically, ±0.847 is the largest log-odds contribution any single pick can ever carry, on either side. Even the most extreme, most heavily-favoured-looking champion in the data can't contribute more evidence than that to the sum. Stack the theoretical extreme case — five allies all clamped at 70%, five enemies all clamped at 30% — and the net log-odds comes to 10 × 0.847 ≈ 8.47, which a sigmoid maps to about 99.98%. That's the model's actual ceiling: no matter how lopsided the aggregate win rates going in look, the output can get close to certain but never quite reach it, because every input that feeds it was capped before the sum ever ran.
Why sum log-odds instead of averaging percentages
A simpler-sounding design would average the ten win rates directly, or average the allies' and subtract the enemies' average. That approach has a real problem: raw percentages don't have a natural additive structure. Two 60% win rates stacked together don't obviously mean anything more than either one alone once you're just averaging, and there's no principled way to express "the enemy team's strength" as a subtraction from "the ally team's strength" on a 0-100% scale that stays bounded and symmetric no matter how many terms go into it.
Log-odds fixes both problems at once. It maps the bounded [0, 1] probability scale onto the entire real number line, with 50% landing exactly on zero — so a champion with a favourable win rate contributes positive evidence, an unfavourable one contributes negative evidence, and a coin-flip champion contributes nothing at all, by construction. Because the scale is unbounded and centred on zero, summing contributions from an arbitrary number of independent champions, and subtracting the enemy side's sum from the ally side's, is a well-defined operation that can't run off the edge of the scale the way summing raw percentages would. This is also the same transformation logistic regression is built on, for the same reason: log-odds is the scale on which independent pieces of evidence combine by simple addition, which is exactly what treating each champion pick as one independent piece of evidence about the outcome requires.
A short comparison makes the difference concrete. Average two 60% win rates together and you get 60% back — the operation can't distinguish "one moderately favourable pick" from "two moderately favourable picks stacked on the same side," because averaging always lands between its inputs, never beyond them. Convert the same two 60% win rates to log-odds (≈0.405 each) and sum them instead, and the total is ≈0.811, which a sigmoid converts back to roughly 69%. Two favourable picks compounding into a more one-sided total, rather than settling back to the same 60% either one implied alone, is exactly the behaviour summing is supposed to capture and averaging structurally can't.
What a missing champion contributes
When a slot has no recognised champion — an unpicked slot, or one OCR couldn't resolve — it contributes exactly zero log-odds. Not a penalty, not an assumed-average win rate baked in as a number; zero, the log-odds value of a true 50% coin flip, which is the only contribution that doesn't push the total toward either side. That slot is also flagged as degraded, which matters for a different reason than the number itself: it's the app's own record that this particular reading is missing information, kept separate from the arithmetic so a caller can choose to surface it without it distorting the total.
There's a second, less obvious way a slot gets flagged degraded even when it has a real number attached. If a champion's stats come back from a different tier than the one the lobby is being scored at — for instance, a tier-specific lookup came back empty and the app fell back to the all-ranks figure instead — that contribution is still a genuine, non-zero win rate and still goes into the sum normally, but it's marked degraded anyway, because it's answering a slightly different question than "how does this champion perform at this specific tier." Degraded doesn't mean "ignored." It means "this number is either absent or not quite the number this tier's score should ideally be built from" — two distinct situations that both end up under the same flag.
The damping identity, stated correctly
Should I Dodge's damping factor — the multiplier applied to the net log-odds before the sigmoid — is currently set to 1.0. That has one specific, easy-to-misread consequence: sigmoid and log-odds are exact algebraic inverses of each other, so at a damping factor of exactly 1.0, feeding a single champion's clamped win rate through the whole pipeline in an otherwise perfectly neutral lobby returns that same clamped win rate, unchanged. A 51.8% win rate produces a 51.80% team win probability. Nine other champions at exactly 0.0 log-odds contribute nothing, so the net log-odds equals that one champion's own log-odds, and the sigmoid undoes exactly what the log-odds conversion did to it.
Damping is a genuine tuning knob, not a fixed constant of the model — a value below 1.0 would pull every net log-odds figure toward zero before the sigmoid, softening every prediction toward 50%, and a value above 1.0 would do the opposite, sharpening predictions away from 50%. At any damping factor other than exactly 1.0, the single-champion-in-an- otherwise-neutral-lobby case would no longer return the input win rate unchanged — the identity described above is specific to the value the app currently uses, not a general property of the model shape.
That's an identity, not a discovery — sigmoid(logit(p)) = p is true for any p, by construction, regardless of which champion or which win rate you plug in. A sentence like "adding this champion moves the lobby by 1.8 points" is, at damping 1.0, just restating that champion's own win-rate edge back at you in different words — it hasn't told you anything the win rate itself didn't already say. The quantity that actually carries new information is that same shift measured against the tier's own noise: 1.8 points is 0.33 standard deviations at Gold, 0.41 at Diamond, and only 0.15 at Challenger — see the noise floor behind every tier's win-rate data for the full reasoning behind that comparison. A raw win-rate edge, reported on its own, always looks like the same-sized fact regardless of tier. Divided by the tier's own spread, it usually isn't.
This is exactly why Should I Dodge reports a band — Neutral, High, Really High, and so on — rather than a raw percentage-point delta from 50%. A delta restates an input. A band says whether that input, in the context of everything else known about how noisy this particular tier's data actually is, is worth paying attention to. See what each band actually means at your own rank for the full boundary table, and how the rest of the pipeline fits together for the calculation this article has been picking apart.