msr-spare-1/nemotron-3-nano-30b-20260719-spare-games-envs

Nemotron-3-Nano-30B SPARE Self-Play Environments (run20260719final)

This dataset packages the self-play generated game environments produced by a live SPARE (Self-Play with Adaptive cuRriculum Extension) training run of NVIDIA-Nemotron-3-Nano-30B-A3B. It is a raw-data export for another agent to pick up, replay, and build its own visualization / weave log from.

Provenance

• —Run: run_20260719_final
• —Source Ray job: spare_nemotron_games_mtpg768_1784556397 (the live, currently-running job at export time; the games directory run_20260719_final/ is shared across it and a prior, now-stopped job, spare_nemotron_games_final_1784483925, whose logs were also mined for reward metadata — see below)
• —Base model: NVIDIA-Nemotron-3-Nano-30B-A3B
• —Training method: SPARE self-play — the model alternates between an environment role (generates a Python game env) and an actor role (plays the generated games); environment reward tracks a plateau+regret-blend proposer signal against actor performance.
• —WandB group: nemotron-3-nano-30b-games-kl005
• —Config: 24 games generated per rollout, 16 plays per game, max_turns=15, game_regeneration_interval=4 steps, 6 cognitive skills: Mathematical_Reasoning, Logical_Deduction, Spatial_Reasoning, Pattern_Recognition, Optimization, Causal_Inference.

No weave traces are included. Weave logging was disabled for this run. What's included instead are the standalone Python game environment files themselves — each one is a self-contained gym-like environment with a class implementing:

def reset(self, seed=None) -> tuple[str, dict]: ...      # -> (observation, info)
def step(self, action: str) -> tuple[str, float, bool, bool, dict]: ...  # -> (obs, reward, terminated, truncated, info)

Another agent can replay these environments (reset() / step() in a loop, feeding actions from any policy — including re-running the original Nemotron actor or a different model) to generate its own trace/weave log for visualization. See spare/core/envs/synthetic_game_env.py in the SPARE repo for a reference loader (make_synthetic_env(path)).

Directory layout

generations/
  gen_00_step_00000/   # full generation snapshot at training step 0  (24 games + hints)
  gen_01_step_00004/   # full generation snapshot at training step 4  (24 games + hints)
  gen_02_step_00008/   # full generation snapshot at training step 8  (21 games + hints)
  gen_03_step_00012/   # full generation snapshot at training step 12 (23 games + hints)
  gen_04_step_00016/   # full generation snapshot at training step 16 (22 games + hints)
  gen_05_step_00020/   # full generation snapshot at training step 20 (24 games + hints)
  gen_06_step_00024/   # full generation snapshot at training step 24 (23 games + hints)
  gen_07_step_00028/   # full generation snapshot at training step 28 (24 games + hints)
  partial/
    step_00001/  step_00005/  step_00006/  step_00009/  step_00013/  step_00017/  step_00025/
      # minor / intermediate regen steps: 1-3 games each, no proposer hints
      # (partial or delayed-proposer generations between the full snapshots above)
env_memory.json   # the environment-memory bank: game code snippets + skill + metadata
                  # accumulated by the proposer across the run (200 entries)
manifest.json     # per-game index + reward metadata (see schema below)
README.md         # this file

Each game generation directory contains, per game:

• —game_SSSSS_III_skill.py — the environment source file (SSSSS = training step at which it was generated, III = index within that generation's batch, skill = cognitive skill suffix)
• —game_SSSSS_III_skill_hint.txt — the proposer's self-authored hint for how to solve the game (only present for the 8 full-generation snapshots; the partial/intermediate steps were captured mid-generation before the hint was written)

Note: the live spare_games/ directory (the "current generation" pointer at export time) was verified byte-identical to gen_01_step_00004 for all 24 game_*.py files, so it is not duplicated here — its content is fully represented by gen_01_step_00004/.

manifest.json schema

A JSON object with two top-level keys:

• —summary: run-level rollup —
• —total_games: total game files indexed (195)
• —per_generation_counts: dict of generation/partial-step dir name → game count
• —per_skill_counts: dict of skill name → game count
• —games_with_reward_data / games_without_reward_data: how many games were joined against observed play-reward stats mined from training logs
• —reward_stats_source: which jobs' logs were parsed and how many [COLLECT] stats log entries were found in each
• —note_spare_games_live_dir: note on the spare_games/ de-duplication described above

• —games: a list, one entry per game file:

How reward metadata was derived

Per-game play rewards are not stored in a structured metrics file for this run — they were mined from the raw Ray job stdout logs, which periodically print lines of the form:

[COLLECT] stats: {'game': {'/scratch/.../game_00000_002_spatial_reasoning.py': [reward, reward, ...], ...}, 'skill': {...}}

These were pulled via the Ray dashboard API (/api/jobs/<job_id>/logs) for both the job that produced this run's directory (spare_nemotron_games_final_1784483925, stopped) and the job currently continuing it (spare_nemotron_games_mtpg768_1784556397, running at export time), ANSI-stripped, regex-extracted, and ast.literal_eval'd. Rewards for the same game basename were concatenated across all log entries from both jobs to get the full observed play history for that game. 35 such log entries were parsed in total (30 from the stopped job, 5 from the running one); all 195 games in this export had at least one matching reward-stats entry (100% join rate) — see manifest.json's summary block for exact counts. Because the Ray dashboard retains a bounded scrollback (~20k lines) for running jobs, the live job's logs could in principle be truncated and miss early-generation data — that did not end up happening for this snapshot, but note it if you re-run this export later in the job's lifetime.

Replay instruction

To replay any game and generate your own trace/weave log, load the file as a Python module and drive its class through reset()/step() — e.g. using make_synthetic_env(path) from spare/core/envs/synthetic_game_env.py in the SPARE repo, feeding actions from whatever policy you want to visualize.