RLVE opened 128 reasoning teachers. Keep the missing training state visible

THE SIGNAL IN ONE SENTENCE

A model file can tell you what the machine became. It usually cannot tell you how it got there. That distinction matters this morning because a new open release offers much more than one tidy checkpoint. On October 25, researcher David Heineman published a Hugging Face collection containing 128 specialist teacher models from the original RLVE data-scaling experiments. A companion collection contains eight student models trained across four environment counts and two methods. Every listed model is about two billion parameters in BF16 format and traces back to DeepSeek-R1-Distill-Qwen-1.5B. The teachers are narrow specialists. One is trained on a path-counting task. Others focus on graph isomorphism, number theory, games, string operations and dozens of other verifiable environments. The release is not simply a wall of similarly named weight files. Each teacher repository names its environment, training method and run. It records a training cap of 4,000 rollouts, a final checkpoint update and a validation rule. The published example says evaluation used 32 prompts with eight responses per prompt every 50 updates, and that teachers stopped at the rollout cap or when in-distribution validation pass@1 reached at least 0.98. The student repository goes a step further than the usual model card shrug. It includes the environment list, a run record and the exact configuration file. It also states what is not there: optimizer and dataloader state are absent. That sentence is the signal. Open weights are useful. Open training receipts are better. A receipt lets another researcher ask what data and settings shaped the model, which result belongs to which run and whether a claimed comparison can be reconstructed. It also stops the community from confusing a downloadable artifact with a reproducible experiment. The release does not establish that every teacher is broadly capable, that every student gain will transfer beyond the selected reasoning environments or that a fresh run will land on the same result. These models are small specialists built inside a particular experimental setup. Their value is partly scientific: they expose the intermediate machinery of a scaling study instead of presenting only the winner. The Plain Signal recommendation is simple: keep a missing-state card beside every open model. Start with the files that are present. Record the base model, tokenizer, exact revision, precision, method, environment list, prompt format, rollout budget, validation schedule, stopping rule and final checkpoint. Preserve links to the run tracker and the code revision used to launch training. If a user changes the chat template or generation settings, that change should become part of the local receipt. Then name the state that is absent. Optimizer state includes the numerical history used to update model parameters. Without it, a researcher generally cannot resume training at the precise point where the published run stopped. Dataloader state records where the training process was in its stream of examples and how those examples were ordered. Without it, even the same data and seed may arrive in a different sequence. Those omissions do not make the release bad. They define what kind of reuse is possible. A practitioner can download the final weights and test inference. A researcher can compare the configurations and inspect the specialist lineup. A team can fine-tune from the final checkpoint. But anyone claiming an exact continuation or an exact replay needs more state than the repositories currently provide. That boundary should be machine-readable, not buried in prose. Imagine a compact release manifest with five columns. The first column lists identity: model name, immutable revision, base model and license. The second lists training inputs: datasets or environments, versions, sampling rules and prompt templates. The third lists procedure: code commit, hyperparameters, hardware, precision, seeds, rollout budgets and stop conditions. The fourth lists evaluation: prompt set, sample count, scoring rule, frequency, pass threshold and held-out boundaries. The fifth lists recoverability: final weights present, intermediate weights present, optimizer state absent, dataloader state absent, logs linked and resume tested or not tested. That final column prevents a common category error. Reproducibility is not one switch. There is inference reproducibility: can another person run the same checkpoint and obtain behavior within an expected range? There is evaluation reproducibility: can they rerun the benchmark with the same prompts, sampling settings and scorer? There is training reproducibility: can they repeat the process from the base model and obtain a comparable result? And there is continuation reproducibility: can they resume from a particular step without silently changing the optimization path? The RLVE repositories support parts of that ladder. They do not claim to support all of it. The release also offers a useful way to study teachers instead of treating a teacher model as an oracle. Each specialist can be tested on the environment it saw, neighboring tasks it did not see and prompts that preserve the underlying problem while changing surface form. Researchers can compare teacher confidence, wrong-answer patterns, explanation length and sensitivity to formatting. They can ask whether a student trained from several specialists learns a transferable reasoning habit or merely a library of narrow response patterns. On-policy distillation makes that question especially important. In this family of methods, a student generates trajectories from its own evolving policy and a teacher supplies dense guidance on those student-visited states. That can reduce the mismatch created by training only on polished answers produced by a stronger model. It also creates a dependency chain. The student outcome depends on which student states were sampled, which teacher evaluated them, how the teacher signals were combined, how environments were balanced and when training stopped. A final student checkpoint compresses all of that history into weights. The receipt expands enough of the history back into view to make analysis possible. Users should resist one seductive shortcut: treating 128 teachers as 128 independent confirmations. The collection says the teachers share the same base lineage and experimental family. Their task diversity is valuable, but common initialization, code and evaluation practices create shared failure modes. A bug in the harness, a leaky validation split or a brittle prompt convention could travel through the whole shelf. So a good reuse plan includes cross-checks. Run a small sample of environments with an independent scorer. Change superficial wording while holding the solution fixed. Test held-out difficulty. Compare results with and without answer forcing. Inspect failed rollouts instead of reporting only pass@1. Keep a separate list of artifacts that were verified locally and those accepted from the release card. The same discipline applies to hardware claims. The repositories describe weights and configurations, but the model cards viewed for this release do not present a complete hardware and energy ledger. A team should record accelerator type, count, runtime, memory, software stack and estimated energy for any reproduction attempt. Otherwise a technically repeatable recipe may remain practically inaccessible. Open-model culture often rewards the largest upload and the cleanest benchmark table. This release points toward a more useful norm. Publish the shelf, not only the champion. Name the run. Preserve the configuration. Link the validation. State the stop rule. Say what is missing. Then let the next researcher decide whether they are downloading a model, replaying an evaluation, repeating a training study or attempting to continue an unfinished run. Those are four different jobs. A good release tells you which ones the evidence can support.