Pokémon TCG AI Battle — would-KO, RoPE-ND, and Prospective Planning
Current would-KO mechanism (implemented, at build + inference) and historical RoPE-ND + prospective planner design (deferred backlog, not in current runtime).
Pokémon TCG AI Battle — would-KO, RoPE-ND, and Prospective Planning
Status
- would-KO — implemented and shipping. The trio (
P(KO),expected prizes taken,P(ending the game)) is a per-option input feature computed by the offline dataset builder from the search agent and packed intoopt_attr. At inference the same search agent recomputes it deterministically. Toggle via--bc-would-koat build time and honored end-to-end. - RoPE-ND — not implemented. Positional information in the current model is carried by zone-typed token embeddings and explicit
opt_src_pos/opt_tgt_posgather from state tokens (see pokemon_tcg_agent_architecture). RoPE-ND remains research backlog in pokemon_tcg_ladder_and_research. - Prospective V2 planner (sidecar) — deprecated. No sidecar
.npyfiles exist in the current dataset layout and no code path inscripts//rl/reads them. See pokemon_tcg_prospective_v2 for the historical design and the reason it was rejected. If the prospective signal returns it will be integrated (aux head or offline GRPO), not a second separate model.
Current would-KO
would_ko is a prospective option feature computed before attack decisions.
It estimates:
P(any KO)
expected prizes
P(ending the game)
The repaired builder passes the resolved configuration to spawned workers, uses deterministic decision seeds, distinguishes valid zero from failure, rejects non-finite values, records an audit sidecar, and fails an enabled build when no computation succeeds. It does not use the replay's hidden opponent deck as a feature.
The real smoke corpus computed 78 eligible attack options, including 44 valid zeros, with no failures.
Relationship to TBPTT and GRPO
TBPTT carries causal past state through recurrent registers. would-KO queries the simulator about a candidate present action. The current would-KO feature is not GRPO because it does not compute group-relative advantages or update policy probabilities.
It is, however, the first bounded instance of the computation needed by a group-relative planner:
[ G(s)={\tau_1,\ldots,\tau_K}, \qquad A_i=\frac{r_i-\operatorname{mean}(r_G)} {\operatorname{std}(r_G)+\epsilon}. ]
When behavior/reference log-probabilities are retained, this signal can enter a GRPO-style clipped policy objective. Without those probabilities, the same groups support relative ranking or policy distillation and should not be described as strict GRPO.
All branches in a group must use the same hidden-state determinizations and random streams. This common-random-number contract prevents an action from appearing better merely because it received a more favorable sampled world.
Historical additive planner design
The broader Prospective V2 implementation is now recorded separately in pokemon_tcg_prospective_v2. The exact legal-action coverage contract is in pokemon_tcg_action_coverage. At the historical planner snapshot, the planner was a separate module layered over the existing Transformer. That design is preserved here for lineage; it is not a current runtime statement. This page keeps the conceptual boundary between the older would-KO feature and the newer branch planner.
The planner is a separate module. It does not replace the existing Transformer, TBPTT, BC loss, would-KO feature, or recurrent registers.
current Transformer + TBPTT memory
|
v
prospective branch tokens + RoPE-ND
|
v
branch score, return, KO, prizes, terminality, uncertainty
|
v
gated/cross-attention contribution to the existing policy
RoPE-ND supplies the planner's relational geometry:
- real match time;
- future rollout depth;
- branch/action identity;
- entity, zone, and relation coordinate.
RoPE-ND is therefore part of the planning solution, but rollout generation, reward construction, tree masks, and policy supervision provide the remaining mechanism.
Learning from own defeats
Daily metadata recognizes FitaLabs and Alef Oliveira. For each real decision
from an own-agent defeat, the simulator can compare the chosen action with
legal alternatives under matched determinizations. The relative signal answers
which branch was better at that state; it does not clone the losing action or
infer that every action in a lost game was wrong.
The 2026-07-28 archive contains no confirmed replay under either alias, so own defeat training requires a source day where those names occur.
Hidden-information boundary
Exact solving is available only in fully specified, tractable subspaces. Pokémon TCG includes hidden cards, stochastic effects, and a large branching factor, so general planning is belief-state search over sampled determinizations. Claims of exactness or soundness must be restricted to the bounded subspace actually enumerated.
Stockfish provides a useful boundary: ordinary play uses selective search and position evaluation, while exact Syzygy tablebase results apply only to bounded endgames.
Sources
- RoFormer: Rotary Position Embedding
- LieRE: generalized N-dimensional rotary encodings
- Qwen2-VL and multimodal RoPE
- Stockfish search implementation
- Stockfish advanced topics and Syzygy tablebases
Status (audit 2026-08-07)
Reconciling the design described on this page against the live codebase at commit 290d6f9:
- would-KO trio — shipped and stable. Computed at build time by the search agent, packed into
opt_attr[OPT_WK : OPT_WK+3]per option, consumed as a pure input feature by the primary Transformer at both training and inference. Toggled by--bc-would-koat build time and honored end-to-end. - would-KO variance count —
--bc-wk-nvar(default 10) drives the number of variable-attack determinizations. Persisted in the checkpoint'sinference_configso inference reruns match training-time semantics. --zero-wouldko— flag onbc_train_mlx.pyto zero the trio at load time (ablation tool).- RoPE-ND positional encoding — not implemented on the primary model. Positional information is carried by zone-typed token embeddings and explicit
opt_src_pos/opt_tgt_posgather. RoPE-ND remains research backlog in pokemon_tcg_ladder_and_research. - MLX-side prospective planner and PyTorch runtime planner as separate modules — removed at commit
a942373(2026-08-03). No sidecar.npyfiles exist under the current dataset layout and no code path inscripts/orrl/reads them. The prospective signal, if it returns, will be an integrated aux head or an offline GRPO objective on the primary model, not a second module. See pokemon_tcg_prospective_v2 for the full design record. - Autoregressive multi-select fallback (from the planner era) — the fallback is now the only inference path; there is no planner to fall back FROM. See pokemon_tcg_torch_inference.
Provenance / anchor commits
2996583(2026-07-29) — complete compact would-ko prospective pipeline — first shipping of the would-KO builder + planner.10c3750(2026-07-29) — fix prospective reward balancing and action coverage.770364b(2026-07-29) — add real prospective RoPE-ND planner foundation (design; later reverted).a942373(2026-08-03) — sidecar removed, aux heads + meta features + parquet pipeline — kept would-KO; removed the RoPE-ND planner and sidecar file layout.
Full timeline in pokemon_tcg_repository_timeline.