Pokémon TCG — RoPEND, MoE and Vehicle-Draft Blueprint

Status

This page documents the later architecture described in the August 13–14 repository documents. It is a blueprint and research lineage, not an implementation report. The live source tree does not contain a verified rl/ropend, rl/moe, vehicle-draft generator, strategic router or Apex runtime. Keeping those absences explicit is part of preserving the project's actual phase structure.

The proposed 4D RoPEND coordinate system

The RoPEND theory decomposes positional context into four semantic axes:

Axis	Intended meaning
Turn	Position in the game trajectory and tactical phase
Meta-epoch	Training or curriculum regime that produced the observation
Time remaining	Budget available to act or search
Elo	Relative strength/context anchor for the opponent or environment

Instead of treating one flat sequence position as sufficient, the proposal allocates subdimensions of the model width to independent rotary phases and composes them. In abstract form, a coordinate-dependent rotation can be written as:

$$R_{\mathrm{ND}}(p) = R_{\mathrm{turn}}(p_t) \oplus R_{\mathrm{meta}}(p_m) \oplus R_{\mathrm{time}}(p_\tau) \oplus R_{\mathrm{elo}}(p_e).$$

The formula expresses the design intent, not a measured property of the current model. The implementation question is not only how to rotate vectors, but how to normalize, bucket and validate each coordinate without allowing future-derived or opponent-derived information to leak into the decision.

Stochastic Elo inference

The companion architecture document proposes an ephemeral Elo anchor rather than treating rating as a permanent identity. The intended features include timestamps, match volume, an opponent-Elo proxy and a confidence or freshness interpretation. This could let a router distinguish regimes such as:

• novice or noisy opponent;
• established high-Elo opponent;
• low-volume rating with high uncertainty;
• meta-epoch shift where historical rating no longer describes the current field.

The proposal is compatible with the project's Abelian rating work because it treats rating context as relational and translation-sensitive rather than as an immutable truth about a model. It is not evidence that the current policy already performs stochastic rating inference.

MoE topology: Pilot and Vehicle

The Magnum Opus blueprint separates a stable coordinating policy from specialist behavior:

flowchart LR
    S[Structured game state] --> R[4D context router]
    R --> P[Pilot / coordinator]
    R --> V1[Vehicle specialist A]
    R --> V2[Vehicle specialist B]
    R --> V3[Vehicle specialist C]
    P --> D[Decision and delegation]
    V1 --> D
    V2 --> D
    V3 --> D
    D --> E[Engine action]

“Pilot” and “Vehicle” are architectural roles in the blueprint. They do not imply a deployed agent hierarchy. The routing contract would need to record expert selection, confidence, load, gradient ownership and fallback behavior, especially because the Stage 3 incident showed that untracked multi-task gradients can damage a shared trunk.

The proposed elite pool is described as high-Elo and orthogonal: not merely the strongest checkpoints, but specialists whose behavioral regions differ enough to provide useful routing diversity. The exact threshold, including the document's Elo 1100 example, is a research selection rule, not a current database fact.

Data augmentation through autoregressive vehicle drafting

The blueprint's data-augmentation idea is larger than ordinary row-level perturbation. It proposes an autoregressive 60-card vehicle/deck draft in which the model generates or explores a legal deck composition, then evaluates the resulting vehicle in the engine and tournament loop. The dedicated pokemon_tcg_data_augmentation_vehicle_draft page isolates this contract from the wider MoE architecture so that current derived targets, future synthetic data and database-reset uncertainty remain separately auditable.

The intended loop is:

1. sample or condition on a specialist/context state;
2. draft a legal card sequence while respecting deck constraints;
3. materialize the 60-card vehicle as an immutable candidate;
4. run engine-backed replay or tournament evaluation;
5. record the deck, model, rating context, seed, opponent regime and outcome;
6. feed successful and orthogonal candidates back into the elite pool or future training corpus.

This is a prospective augmentation and search mechanism, not a claim that the current BC corpus contains generated 60-card examples. It must not be mixed into ordinary behavioral-cloning rows without a provenance flag. A future dataset should distinguish at least:

Field family	Required distinction
Origin	Human/replay-derived versus model-drafted
Generator	Checkpoint, expert, router version and sampling policy
Legality	Deck-rule validation and engine acceptance
Evaluation	Tournament cohort, opponent source, number of games and reset state
Rating context	Elo snapshot, date and uncertainty/volume
Outcome	Win/loss/draw, terminal causes and deck-conditioned result

Without those fields, data augmentation would turn into untraceable synthetic contamination. The ETL and experiment/anamnesis designs are therefore prerequisites for this blueprint, not post-processing details.

Training path proposed by the blueprint

The document presents two broad initialization choices:

• train a new base from scratch with the structured architecture;
• upcycle a stable Stage 4 or later baseline into the routed design.

The second path is attractive only if the Stage 3/4 loss and validation contracts are repaired first. A checkpoint that already has an unstable shared representation should not be treated as a neutral base for expert routing. The pokemon_tcg_stage3_training_failure_postmortem is therefore part of the future architecture's dependency chain.

Apex mode and phase boundary

The blueprint places Apex mode after the stated August 16 competition horizon. It is a later runtime or orchestration mode, not part of the current arena contract. The correct Wikifita statement is:

current structured BC baseline
    -> validated data and loss contracts
    -> prospective / rating-aware experiments
    -> RoPEND and specialist routing
    -> vehicle-draft augmentation
    -> Apex runtime research

Each arrow represents an experimental gate. The repository documentation contains the destination architecture even where the source tree has not crossed the gate.

Risks inherited from the current phase

The blueprint must answer four risks before implementation:

• Temporal leakage: time remaining, opponent Elo and meta-epoch can become future-derived features if they are computed after the decision.
• Objective interference: multiple experts and auxiliary heads can recreate the Stage 3 gradient-scale failure at larger scale.
• Synthetic distribution drift: drafted vehicles can overrepresent the generator's preferences and underrepresent legal but strategically diverse decks.
• Evaluation ambiguity: an apparently stronger vehicle may owe its result to opponent selection, reset state, deck pairing or tournament regime rather than routing.

The future design should therefore inherit the repository's explicit source, denominator and tournament-cohort fields rather than adding a separate opaque experiment path.

Primary sources and provenance

• docs/architecture/01_ropend_theory.md — four-dimensional rotary theory.
• docs/architecture/02_stochastic_elo_inference.md — rating-aware context and routing inputs.
• docs/architecture/moe_pipeline_blueprint.md — Pilot/Vehicle, elite pool, deck draft and Apex sequence.
• docs/dataset_compilation_and_oracle_pipeline.md — target dataset fields for RoPEND/MoE context.
• docs/abelian_group_elo_formulation.md — relational rating formalization.
• docs/pagerank_and_abelian_graph_invariance.md — graph-invariance analogy.
• docs/arena-future-architecture.md — later application/worker boundary.

Cross-references

• pokemon_tcg_neural_engine_tokenization — current streams and explicit as-built/target table.
• pokemon_tcg_stage3_training_failure_postmortem — prerequisite loss and validation postmortem.
• pokemon_tcg_data_oracle_etl — provenance fields needed before synthetic augmentation.
• pokemon_tcg_data_augmentation_vehicle_draft — dedicated derived-target and vehicle-draft provenance contract.
• pokemon_tcg_schema_evolution — relational identity and evidence graph required before routing or synthetic candidates can be persisted safely.
• pokemon_tcg_arena_future_architecture — future execution boundary for reproducible vehicle evaluation.
• pokemon_tcg_implementation_specification — target acceptance and idempotency requirements.
• pokemon_tcg_elo_pagerank_invariance — rating and graph research lineage.
• pokemon_tcg_long_horizon_vision — earlier staged BC → world model → MoE direction.
• pokemon_tcg_research_backlog — deferred research boundary.