Pokémon TCG — Data Augmentation and Vehicle-Draft Contract
Provenance-bound contract for derived targets, synthetic vehicle drafting, legality checks and future MoE training data.
Pokémon TCG — Data Augmentation and Vehicle-Draft Contract
Status and scope
In this project, “data augmentation” has two different meanings that must not be collapsed:
- Derived supervision: labels computed from an existing replay or engine state, such as return, prize delta, terminal state or would-KO signals.
- Prospective vehicle generation: a later blueprint in which a model drafts or explores a legal 60-card deck, evaluates that vehicle in the engine or arena, and records the result as a new experiment.
The first category is part of the current dataset and auxiliary-head lineage. The second category is a future RoPEND/MoE research mechanism. The live repository does not contain a verified vehicle-draft generator or a production synthetic-data loop.
This distinction preserves the later architecture documents without describing them as implemented.
Why ordinary row augmentation is not enough
The blueprint does not propose random perturbation of a replay row as its main augmentation mechanism. It proposes a structured search over the policy's own vehicle:
flowchart LR
R[Replay or structured context] --> C[Context and specialist condition]
C --> D[Autoregressive legal deck draft]
D --> L[Deck legality and card-count checks]
L --> E[Rules-engine or arena evaluation]
E --> P[Provenance record]
P --> Q[Elite-pool or experiment decision]
Q --> T[Future training corpus]
The model is therefore evaluated as a pair:
policy or pilot + immutable vehicle/deck
A validation score for the pilot cannot identify the quality of the vehicle. Conversely, a strong deck-conditioned tournament slice does not prove that the router or draft policy caused the result. The experiment record must retain both objects.
Current derived supervision
The current Parquet pipeline already derives additional targets from replay and engine state. These targets are not synthetic replays. They are transformations of an observed row with an explicit validity mask and temporal-availability requirement.
| Derived signal | Source role | Current interpretation |
|---|---|---|
aux_return | Replay trajectory and terminal outcome | Sequential return target; current dataset field |
aux_prize_delta | State transition and prize accounting | Sparse turn-local target; current dataset field |
aux_terminal | Terminal-state evidence | Sparse target; current dataset field |
aux_ko | Engine-backed or rules-derived event | Sparse prospective-style target; current dataset field |
bc_would_ko | Bounded engine simulation | Oracle label, not internal model simulation |
These labels extend supervision. They do not create a new deck, a new opponent or a new tournament. Their masks and denominators must remain visible in the training ledger.
Prospective vehicle-draft sequence
The later blueprint describes the following experiment boundary:
- condition on a model, expert, router state or rating context;
- draft a legal sequence of cards until the 60-card vehicle is complete;
- validate deck rules and materialize the candidate as an immutable artifact;
- evaluate the vehicle against a declared opponent and deck cohort;
- record seed, generator, checkpoint, router and rating context;
- retain the candidate as a research observation only if the cohort and reset state are recoverable;
- promote it into an elite or orthogonal pool only under a declared selection rule.
The deck is a first-class experimental object. It must not be reconstructed later from a tournament label or inferred from a single win rate.
Minimum provenance contract
The target dataset specification already names the fields needed to connect four-dimensional position context with a pre-game vehicle. A future implementation should extend that contract with an explicit origin record:
| Provenance dimension | Required value or distinction |
|---|---|
| Origin | Replay-derived, human deck, model draft or edited candidate |
| Generator | Checkpoint, expert, router version and sampling policy |
| Deck identity | Immutable 60-card list, canonical hash and legality result |
| Temporal context | Match step, meta epoch and decision timestamp |
| Rating context | Elo snapshot, source, volume and uncertainty or freshness |
| Evaluation cohort | Opponent source, deck labels, game count, seed and tournament ID |
| Database state | Database/replay snapshot and whether prior tournament rows were reset or retained |
| Outcome | Wins, losses, draws, terminal causes and deck-conditioned slices |
| Review state | Candidate, rejected, reproduced, promoted or unresolved |
The repository's target Parquet columns include match_step, meta_epoch_day, time_remaining_s, inferred_opponent_elo, team_identity_hash and vehicle_deck_card_ids. These are target extensions in docs/dataset_compilation_and_oracle_pipeline.md, not evidence that the live dataset already contains a completed vehicle-draft experiment.
Relationship to the elite pool
The blueprint's elite pool is not simply the top numerical rows. It is intended to contain strong and sufficiently different vehicles or specialists. That creates two separate selection questions:
- Strength: does the candidate perform well under a declared tournament cohort?
- Orthogonality: does the candidate add behavioral coverage that existing specialists do not already provide?
The current survey reports an elite-filter observation of approximately 39,957 matches with both relevant participants at daily Elo >= 1100. That value belongs to the survey and must be recomputed before it becomes a final generated dataset claim. The broad current Parquet corpus and the future elite vehicle pool are different objects.
Dependency on the Stage 3 incident
Synthetic vehicle data must not be added before the loss and validation contract is repaired. Stage 3 demonstrated that a pipeline can report plausible in-pool validation while the shared Transformer representation is exposed to an uncontrolled auxiliary-loss scale. A vehicle-draft loop would increase the risk by adding new expert, generator and evaluation signals.
The minimum inherited guardrails are:
- separate denominators for behavior, auxiliary and generated-data objectives;
- valid-row counts and per-head gradient norms;
- disjoint source and time boundaries for training, validation and tournament review;
- no future-derived rating, clock or outcome field at the decision timestamp;
- a behavioral-only control with the same data budget;
- an immutable candidate deck and reproducible legality check;
- a cohort ledger that records resets instead of guessing whether the database was reset.
Without these controls, “augmentation” can become untraceable synthetic contamination or a second copy of the Stage 3 failure at a larger scale.
Current versus future boundary
| Surface | Current verified state | Future research state |
|---|---|---|
| Replay data | 30-day Parquet corpus and SQLite catalog | Elite, orthogonal and vehicle-conditioned pools |
| Auxiliary labels | Return, prize, terminal and would-KO lineage | Generated-deck outcomes and specialist targets |
| Deck object | Packaged runtime/submission deck and local deck slices | Autoregressive 60-card vehicle draft |
| Position context | Existing typed streams and metadata | 4D RoPEND coordinates |
| Routing | Shared Transformer with auxiliary heads | Pilot/Vehicle MoE and stochastic Elo routing |
| Acceptance | Cohort-specific tournament ledger | Reproducible vehicle evaluation and promotion gate |
The future column is intentionally preserved. It explains the intended direction without overwriting the current source-tree reconciliation.
Primary sources
docs/architecture/moe_pipeline_blueprint.md— Pilot/Vehicle split, autoregressive 60-card draft, elite pool and Apex sequence.docs/dataset_compilation_and_oracle_pipeline.md— current derived targets and target RoPEND/MoE columns.docs/architecture/01_ropend_theory.md— four coordinate axes for later routing and positional encoding.docs/architecture/02_stochastic_elo_inference.md— rating-aware context proposal.docs/empirical_ablation_monograph.md— deck saliency, FP16 collapse and evaluation cautions.docs/etl_architecture_and_auditing.md— zero-trust ETL and rebuild hazards.
Cross-references
- pokemon_tcg_ropend_moe_blueprint — broader future architecture lineage.
- pokemon_tcg_data_oracle_etl — replay, oracle and synthetic-data provenance.
- pokemon_tcg_neural_engine_tokenization — current streams and target delta.
- pokemon_tcg_stage3_training_failure_postmortem — loss-scale and validation prerequisite.
- pokemon_tcg_aug14_ablations_tournaments — cohort-separated deck and tournament evidence.
- pokemon_tcg_current_state_reconciliation — implementation boundary at the verified source snapshot.
- pokemon_tcg_schema_evolution — identity, evidence and derived-aggregate relations needed for synthetic candidates.
- pokemon_tcg_implementation_specification — idempotent experiment and replay acceptance requirements.
- pokemon_tcg_arena_future_architecture — reproducible future arena seam.