This document establishes the methodological contract under which the system operates. It defines system intent, modeling assumptions, scope boundaries, and conservatism principles.
Disclaimer: This document is for transparency. Users are not required to understand these details to use the tool.
Relationship to Validation: This Methodology section defines what the system is designed to do and the assumptions under which it operates. The companion Validation & Diagnostics section provides empirical evidence that the system behaves according to these specifications. Methodology establishes the contract; Validation verifies adherence to that contract.
The system is designed as a decision support tool for professional coaching staff during the champion selection phase. Its function is to surface historical patterns, quantify trade-offs, and expose opportunity costs at each decision point. The system analyzes professional match data to identify what strategic options are being gained, foregone, or constrained as the draft progresses.
All system outputs take the form of probability distributions, not point estimates or prescriptive recommendations. Role flexibility is represented as a distribution over positions, preserving uncertainty rather than collapsing it into deterministic assignments. This design choice ensures that outputs remain amenable to human interrogation, contextual interpretation, and override.
The system is explicitly designed to augment human decision-making, not to replace it. It functions as an analyst-facing tool that surfaces structured data for human interpretation. The system does not prescribe actions; it exposes information that informs decisions made by domain experts.
Design Principle: The system surfaces patterns; it does not make decisions. Strategic context, opponent modeling, player state, and meta-game interpretation remain exclusively within the domain of the coaching staff.
The following capabilities are explicitly excluded from the system's scope. These are not missing features but deliberate design boundaries that define what the system does not claim to do.
No Meta Prediction
The system does not forecast how balance changes, patch updates, or meta shifts will affect champion viability. All outputs reflect historical patterns observed in the data, not predictions of future states.
No Optimal Draft Solutions
The system does not claim to identify optimal draft compositions. Draft quality is contingent on execution, adaptation, and factors outside pre-game analysis. The system exposes trade-offs and opportunity costs; it does not prescribe solutions.
No Win Rate Optimization
The system makes no claims about win rate improvement. Post-draft execution, in-game adaptation, and individual performance are outside the scope of this analysis. Using system outputs does not guarantee improved outcomes.
Scope Boundary: The system assists with understanding historical patterns in professional drafts. It does not predict, prescribe, or optimize.
The following constraints are deliberate design choices that prioritize statistical rigor and interpretability over model complexity.
No Patch-Specific Learning
The system does not train patch-specific models or learn causal patch effects. Context filtering reports observed frequencies in data subsets; it does not model patch dynamics or balance change impacts.
No Region-Specific Model Training
Regional differences are exposed through data filtering, not separate learned models. The base model is trained on global data; regional views represent data subsets, not distinct learned representations.
No Small-Sample Reweighting
When sample size is insufficient (below the minimum threshold), the system returns the global baseline unchanged. This prevents noise from small samples from contaminating outputs.
Design Rationale: Historical data exists for interpretability and prior transparency, not for driving current-patch predictions. These constraints reflect commitment to statistical rigor, not missing capabilities.
The system provides two distinct views of role probability distributions. These views differ in their reference population, not in their underlying model. The Bayesian model structure remains identical; only the data subset from which frequencies are computed changes.
Default View
Global baseline derived from full dataset
Represents stable, long-term role distributions. This is the authoritative baseline against which all contextual views are calibrated.
Context-Filtered View
Conditioned on user-specified subset
Reports observed frequencies within a specified data subset. This is a conditioning operation on historical data, not a prediction of future behavior.
The default mode computes role probabilities from the full dataset using Bayesian posteriors with a Dirichlet-Multinomial conjugate prior. The prior strength parameter is selected via cross-validation to balance responsiveness and stability.
When a user selects a specific patch or region, the system conditions the reference population to that subset and recomputes observed frequencies. The output reports what was observed in the selected context—it does not predict what will occur in future games under similar conditions.
Context filtering addresses a specific methodological concern: the global baseline aggregates data across heterogeneous conditions. When an analyst is preparing for a match in a specific context, the global distribution may not accurately represent the relevant reference population.
Prevents Incorrect Generalization
Global frequencies may misrepresent role distributions in specific contexts. Context filtering surfaces this heterogeneity.
Constrains Reference Population
Enables analysts to query historical data within specific contexts. This is a question about historical data, not a request for prediction.
Supports Analyst Validation
Allows analysts to validate whether global patterns hold in specific contexts. This is an inspection tool for data heterogeneity.
To prevent misinterpretation, the following constraints are explicit:
Not Patch-Level Meta Modeling
The system does not learn patch effects or model balance changes. It reports observed frequencies in historical data subsets.
Not Predictive
Filtered frequencies describe what was observed, not what will occur. No claim is made that historical context frequencies generalize to future games.
Not Causal
The system does not claim that patch changes cause role shifts. It only reports that observed frequencies differ across data subsets.
To prevent noise from small samples from contaminating outputs, the system enforces minimum sample thresholds and implements automatic fallback to the global baseline.
Minimum Sample Threshold
Context adjustments are only applied when sufficient games exist in the specified context. Below this threshold, the global baseline is returned unchanged.
Graceful Degradation
When context data is insufficient, unavailable, or not specified, the system returns the global baseline without error. This ensures stable outputs under all conditions.
Context filtering is an explicit, user-controlled operation. The system never automatically applies context adjustments based on inferred conditions. Users must actively select a context to activate filtering.
Design Principle: Users always know which reference population is active. Context filtering is transparent and reversible—never hidden, never automatic, never permanent.
Methodological Position: The system does not predict patch meta. It conditions historical data to ensure probabilities remain decision-relevant under explicitly defined contexts. The context filter is a reference population selector, not a forecasting mechanism.
All analysis is derived from professional match data spanning the 2024–2025 competitive seasons across major regional leagues. Data is sourced from the GRID Esports API.
Temporal Coverage:
Region Coverage:
LCK (Korea) - 14 tournaments
Spring 2024 (Regular Season, Playoffs), Summer 2024 (Regular Season, Playoffs), Regional Qualifier 2024, LCK Cup 2025 (Groups, Play-Ins, Playoffs), Split 2 2025 (Regular Season, Road to MSI), Split 3 2025 (Groups, Play-Ins, Playoffs)
LPL (China) - 30 tournaments
Spring 2024 (Regular Season, Playoffs), Summer 2024 (Group Stage A-D, Rumble Stage, Playoffs, Play-in), Regional Qualifier 2024, Split 1 2025 (Groups A-D, Knockouts), Split 2 2025 (Group Stage A-D, Rumble Stage, Qualifying Series, Playoffs, Play-in), Split 3 2025 (Rumble Stage, Regional Qualifier, Playoffs, Play-in)
LEC (Europe) - 14 tournaments
Winter 2024 (Regular Season, Playoffs), Spring 2024 (Regular Season, Playoffs), Summer 2024 (Regular Season, Playoffs), Season Finals 2024, Winter 2025 (Regular Season, Playoffs), Spring 2025 (Regular Season, Playoffs), Summer 2025 (Groups, Playoffs)
LTA (Americas) - 22 tournaments
LCS: Spring 2024 (Regular Season, Playoffs), Summer 2024 (Regular Season, Playoffs) | LTA North: Split 1-3 2025 (Rounds 1-3, Playoffs, Regional Qualifier) | LTA South: Split 1-3 2025 (Rounds 1-3, Playoffs, Regional Qualifier) | Cross-Conference: Split 1 2025, Regional Championship 2025
Interpretation note: A champion showing high presence in the data indicates frequent professional selection during the covered period, not necessarily current meta viability or balance state. Champion evaluations reflect historical usage patterns, not theoretical optimal usage or current patch strength.
Temporal Lag
Data is historical and does not cover matches after 2025-09-28. Outputs reflect past patterns, not real-time meta shifts.
Regional Imbalance
LCS coverage is limited to 2024 season only. LTA coverage begins from 2025. Regional comparisons should account for differing sample sizes.
No International Events
The current dataset focuses on regional league play. International tournaments (MSI, Worlds) are not included in this analysis.
No Causal Claims
All outputs reflect correlation (observed frequency differences), not causation. The system does not claim that patch changes cause role shifts; it only reports that frequencies differ across data subsets.
All match data is acquired through the GRID Esports API (test version). Data retrieval follows a maximum-coverage strategy as documented in the API Fields Reference, ensuring comprehensive capture of all available match attributes including draft actions, player statistics, team compositions, and game outcomes.
Initial Data Retrieval:
API Version Note: The current dataset is sourced from the test version of the GRID API. Production API access would provide improved data consistency and reduced error rates. Many of the data quality issues addressed below are artifacts of the test environment and would be significantly mitigated with production access.
Player identifiers in the source data exhibit inconsistencies including case variations, whitespace differences, and prefix/suffix variations. The following normalization rules are applied:
Case Normalization
Player names with case differences are unified to a canonical form (e.g., "Xun" → "XUN", "Knight" → "knight", "shad0w" → "Shad0w").
Whitespace Trimming
Leading and trailing whitespace is removed (e.g., "Loki " → "Loki", "Quantum " → "Quantum").
Team Prefix/Suffix Removal
Team prefixes and promotional suffixes are removed to ensure consistent player identification (e.g., "FNC Wunder" → "Wunder", "LGDBurdol" → "Burdol", "TH Flakked" → "Flakked").
A small number of records required manual intervention due to data quality issues that could not be resolved through automated normalization:
Test Account Corrections
Records associated with test accounts (e.g., "BJTest" placeholder players) were identified and corrected with actual player information where determinable from match context.
Missing Player Name Recovery
Players with empty or null names in game state data (e.g., player "Samver") were recovered by cross-referencing with hierarchy data and manual verification.
The following categories of records are excluded from the analysis dataset. These exclusions are deliberate quality controls, not data loss.
Empty API Responses
Series where the API returned empty data objects (data: {}) with no game information. These represent matches that were scheduled but either not played or not recorded. 145 series removed at initial retrieval.
Games With Incomplete Draft Data
Games where the draft phase (Ban/Pick) does not contain exactly 20 actions (10 bans + 10 picks) are excluded. This ensures draft analysis operates on complete, standard-format drafts only. This includes games with missing score data, as incomplete games typically also have incomplete draft records. 9 series (56 games) removed.
The system is designed specifically for Ban/Pick phase analysis. Draft data integrity is therefore a critical requirement. Games with non-standard draft action counts may indicate:
Data Collection Issues
Match Irregularities
Design Decision: Given the system's focus on draft phase analysis, any uncertainty in draft data integrity is unacceptable. The excluded games represent approximately 1.6% of the total dataset (56 of 3,442 games). This conservative exclusion ensures that all draft-based analysis operates on verified, complete data.
Complete data flow from API retrieval to final dataset:
1,478
Series
3,386
Games
442
Players
56
Teams
All games in the final dataset have exactly 20 draft actions (10 bans + 10 picks), ensuring complete draft phase coverage for analysis. Data retention rate: 90.6% (1,478 / 1,632).
Methodological Position: Data quality is prioritized over data quantity. The exclusion of incomplete or anomalous records ensures that all analysis operates on verified, consistent data. With production API access, the proportion of excluded records would be significantly reduced.
The system surfaces evidence only where sufficient historical data exists to support meaningful attribution. Evidence coverage is bounded by data availability, and the system explicitly discloses these boundaries rather than extrapolating beyond them.
Current Coverage:
Absence handling: When evidence is absent for a champion, player, or context, the system treats this as uncertainty, not as a negative signal. No inference is drawn from missing data; the system simply does not surface evidence where none exists.
Not all evidence is treated equally. Evidence strength is calibrated from observed data distributions, not from heuristic rules or manual tuning. Each evidence type has empirically derived thresholds that determine whether a signal qualifies as STRONG, MODERATE, or WEAK.
Team Denial Evidence
Strength is derived from empirical score percentiles computed across all positive denial signals.
Role Flexibility Evidence
Measured via normalized Shannon entropy of role probability distributions. Higher entropy indicates greater role ambiguity.
Player Specialty Evidence
Based on pick concentration within a player's champion pool, not on performance metrics. This reflects historical selection patterns, not effectiveness claims.
Calibration principle: All thresholds are derived from observed distributions in the underlying data. No threshold is manually tuned or heuristically chosen. When data distributions change, thresholds are recalibrated accordingly.
The system is intentionally conservative by design. Multiple mechanisms prevent over-attribution and ensure that weak signals cannot be misinterpreted as strong evidence.
Low-sample player gating
Players with fewer than 10 games cannot produce STRONG evidence. Their maximum evidence strength is capped at MODERATE regardless of concentration metrics.
Weak evidence exclusion from primary attribution
WEAK evidence cannot become a primary driver of any explanation. Only STRONG or MODERATE evidence may be surfaced as the primary attribution for a signal.
Read-only evidence layers
Evidence layers are strictly read-only and do not influence decision ordering. All actionable operations (bans) flow through a single Action Panel, ensuring clear separation between evidence display and action execution.
No inferential claims
The system makes no win-rate inferences, no causal claims, and uses no predictive language. All outputs describe historical patterns, not future expectations.
These constraints are design choices, not limitations.
Conservative defaults ensure that the system remains interpretable, stable, and under analyst control. Aggressive inference would undermine trust and reduce the system's utility as a decision support tool.
Evidence calibration affects explanation metadata only. The following system behaviors remain unchanged:
Unchanged: Scoring
Unchanged: Architecture
Scope boundary: Evidence calibration determines how signals are explained, not how they are ranked or prioritized. The decision order presented to analysts is determined by threat scores and draft state, not by evidence attribution.
Methodological position: This section establishes the evidentiary standards under which the system operates. Coverage is disclosed, strength is calibrated from data, and conservatism is enforced by design. These properties ensure that system outputs remain trustworthy, interpretable, and appropriate for professional decision support contexts.
The system may expose historical outcome differences across role assignments, including low-frequency roles. These statistics reflect conditional historical outcomes only and do not imply strategic intent or likelihood.
Low-frequency role outcomes are only displayed when ALL three criteria are met:
1. Low Probability
Role probability ≤ threshold (mean − 1 std dev of all role probabilities)
Current threshold: 6.1%
2. Sufficient Sample
Sample size ≥ minimum threshold for statistical reliability
Current minimum: 15 games
3. Notable Difference
Win rate difference from main role ≥ delta threshold
Current delta: 10%
All thresholds are data-driven, computed from the actual distribution of role statistics:
Probability Threshold:
threshold = max(0.05, mean(all_role_probabilities) − stddev(all_role_probabilities))
This identifies roles that are statistically uncommon (below average minus one standard deviation).
The minimum sample size (15 games) is based on practical considerations for professional match data, balancing statistical reliability against data availability.
Interpretation note: Low-frequency roles may reflect niche usage, team-specific strategies, or situational picks. A higher win rate in a low-frequency role does not imply that the role is "better" — it may simply reflect favorable matchup conditions or opponent unfamiliarity. These statistics are descriptive, not prescriptive.