[FeathBow]

Why

A run with a positive staleness trains on rollouts from an earlier policy, so it is a different run whose result has to be judged against a synchronous one. Refs #18.

What

• A results page reports one pair of GRPO runs on one GPU, at staleness zero and then at staleness one, from the same initial checkpoint with the same settings. It lists the settings fixed and confirmed before training, the use contract frozen before evaluation, the quality decision and the reliance it holds under, the training wall time and token throughput of both runs, the GPU time and memory of training, evaluation and admission, and the trace that shows generation advancing while an update runs.
• The page states that the frozen admission ran out of memory and was repeated with a revised core that reads each batch log once, after both cores gave identical output on a complete earlier evaluation, and that this departs from the frozen procedure.
• The loop design states that the core fixes the logical assignment and use of every sample, and that identical weights additionally require evidence of the workers' numerical invariance.
• The README links the page.

Validation

Every figure on the page comes from the retained records of these runs.