Pokémon TCG AI Battle — Ladder Evidence and Research Backlog
Observed evaluation, ladder interpretation and explicitly deferred research directions for the Pokémon TCG agent.
Pokémon TCG AI Battle — Ladder Evidence and Research Backlog
Evaluation figures and the future research list have dedicated pages: pokemon_tcg_evaluation_results and pokemon_tcg_research_backlog. This page keeps the ladder-population interpretation and release-record model.
Observed results
The repository records local tournament results and several released checkpoints, including a strong overall local win rate against the included opponent set and matchup-specific variation. The exact figures belong to model/eval_results.txt and result.html; they are observations tied to those opponents, decks, seeds and dates.
The July 29, 2026 one-epoch prospective tournament is recorded separately in pokemon_tcg_evaluation_results because it has a different architecture, dataset, deck, and source provenance.
The project handoff also records approximate competition ratings for Mikaelzinho submissions and the original author's stronger PPO/self-play line. Those numbers are not reproduced here as universal performance claims. They should be recorded per release with submission ID, deck, dataset date, matchup set and timestamp.
The correct epistemic separation is:
observed ladder/rating movement
!= proof that one code change caused the movement
Deck changes, opponent population, submission age, matchmaking, data recency and competition state are confounders. A matchup matrix is more informative than a single rating:
[ V(d,z)=P(\mathrm{win}\mid\mathrm{our\ deck}=d,\mathrm{opponent\ submission}=z). ]
Ladder as a dynamic population
The useful object is not a static list of players but a time-indexed population of submissions:
[ z_j=(\mathrm{team},\mathrm{submission},d_j,\pi_j,r_j,t_j). ]
Submissions are versioned artifacts with a deck, model, rating and lifetime. The ladder can be represented as a temporal graph:
flowchart LR
T[Team] --> S1[Submission v1]
T --> S2[Submission v2]
S1 -->|deck/policy lineage| S2
S1 -->|match result| O[Opponent submission]
O --> M[Observed matchup evidence]
M --> U[Daily population estimate]
U --> D[Deck and evaluation decision]
The interpretation of a rating is population-relative. A rating value at one time is not automatically comparable to the same value after the population, decks and submission mix change. The repository does not establish the proprietary matchmaking or rating formula; any opponent-distribution model must be learned from observed pairings and timestamps rather than assumed to be classical Elo.
Elo-oriented decisions
The local overhaul distinguishes four rating levels: concrete submission, model, deck and card. A local submission is a persistent model-revision/deck-revision combination and starts at 600 when first created. Reusing that pair continues its local lineage. A new remote Kaggle send starts a separate remote submission lineage at 600, even when it uses the same model with a different deck. Deck Elo is an independent outcome-based rating, not a mean of card ratings; card evidence and deck outcomes remain cross-queryable. Local and remote evidence are never mixed.
Before a match, the exact opponent may be unknown, but the current population can define a prior distribution conditioned on our submission's rating region and time:
[ \mu_t(z\mid r_{\mathrm{self}},\mathrm{time},\mathrm{population}). ]
A deck selector can optimize expected performance:
[ d^\star=\arg\max_d\mathbb E_{z\sim\mu_t}[V(d,z)]. ]
For robustness against catastrophic matchups, the selection objective may later include a tail-risk term such as CVaR. This is a research hypothesis, not part of the current MLX migration. Any dynamic deck selection must first be checked against the live competition rules; the repository alone cannot authorize it.
What belongs in the current release record
Each candidate release should record:
release id
dataset manifest and source days
architecture configuration
checkpoint/training state
deck artifact
submission artifact and timestamp
observed rating/Elo
matchup results
known regressions
The release criterion is Elo and matchup robustness with no semantic regressions. Throughput is an enabler for training the right temporal unit, not the evaluation target.
Deferred research backlog
The relational local overhaul is a separate design track. It includes immutable model/deck revisions, normalized replay state, dashboard-editable tournament configuration, experiments without an assumption of retraining, temporal anamnese and idempotent writes. It is not yet implemented.
The following ideas came from the originating technical discussion and are valuable research directions, but they are not decisions for the current implementation:
| Direction | Potential role | Current status |
|---|---|---|
| Mamba/Mamba-2 | Longitudinal selective state memory | Deferred |
| Hope/Nested Learning | Multi-timescale continual memory and consolidation | Deferred |
| N-dimensional RoPE | Encode semantic relational coordinates rather than array order | Deferred |
| Energy-Based Transformer | Iterative strategic refinement and adaptive compute | Deferred |
| TRM | Recurrent deliberation over a fixed state | Deferred |
| J-Lens | Causal analysis of learned workspace/registers | Deferred |
| Strategic MoE | Experts as policy regimes, not card types | Deferred |
| PPO/GRPO/GSPO | Population or trajectory-level policy optimization | Deferred |
| PSRO/population training | Non-transitive deck-policy ecology | Deferred |
| Offline world model | Counterfactual rollout and data augmentation | Deferred |
| Symbolic regression | Compact models of strategic observables | Deferred |
| Adapter library | Modular opponent/archetype or date-specific adaptation | Deferred |
| Multi-Mac/distributed MLX | Distributed model or data execution | Deferred |
These proposals must not be described as implemented capabilities. In particular, the current agent has no opponent-specific adapter router, no persistent online policy update, no world model in inference and no GRPO/GSPO training path.
Adapter and ladder hypotheses
The discussion proposed a hierarchical library of low-rank adapters for archetypes, decks, submissions or recent meta. This could be represented abstractly as:
[ W^{\mathrm{eff}}\ell=W^0\ell+ \sum_k g_{\ell,k}B_{\ell,k}A_{\ell,k}, ]
with routing conditioned on a belief over the current opponent population. That is a plausible later design, but it raises unresolved questions about adapter composition, interference, artifact size, rule compliance, reset semantics and evidence leakage. It therefore remains backlog material rather than a current architecture decision.
Related pages
- pokemon_tcg_ai_battle — evidence boundary and scope.
- pokemon_tcg_evaluation_results — observed local and reported ladder results.
- pokemon_tcg_research_backlog — deferred research directions.
- pokemon_tcg_agent_architecture — current policy and ceiling.
- pokemon_tcg_mlx_migration — current implementation boundary.
- pokemon_tcg_temporal_learning — data needed before population modeling is trustworthy.