You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Generating from a single file is fine for a quick look at one release in isolation, but it drops every model not present in that file — including the carried-forward older generations — so do not commit a single-file render as the shipped dashboard. `batch_eval` writes to `eval_results.jsonl` by default; rename to a versioned filename before committing to the repo.
175
177
176
-
### Eval generations and post-release addenda
177
-
178
-
The `gen` field (an integer injected per-row, legend in `report.py:GEN_INFO`) is a **comparability epoch, not a release version**. It is bumped only when a change is judged eval-material; many releases can share one gen, and a single gen can span several eval waves merged across files (`dedup_latest_gen` keeps the newest gen per config). This decouples "did we add models / re-sweep" from "did we cut a release" — adding models does not require a version bump.
179
-
180
-
To fold new models into an existing dataset, stamp them with that dataset's `gen` and append the rows. Because they are net-new configs, no existing number is recomputed and they slot into the leaderboard as same-gen peers (no carry-forward badge).
178
+
### Eval generations and collection
179
+
180
+
The `gen` field is a **comparability epoch, not a release version**. It is
181
+
bumped only when a change is judged eval-material; many releases can share one
182
+
generation, and one generation can span several eval waves merged across files
183
+
(`dedup_latest_gen` keeps the newest generation per config). Generation 0 is
184
+
reserved for scratch runs and legacy rows that predate the field. Every new row
185
+
records an explicit generation; invoke a released collection with, for example,
186
+
`--generation 4` rather than adding the field after collection.
187
+
188
+
One output file carries only one effective generation. Before dry-run or live
189
+
collection starts a client/server or appends a row, `batch_eval` streams the
190
+
existing file and rejects generation mismatches, mixed generations, malformed
191
+
generation values, malformed JSON, and ambiguous resume rows. A legacy file
192
+
whose rows all omit `gen` is generation 0 and can only resume with generation
193
+
0. For resume identity, historical rows without `reasoning_replay` mean `full`
194
+
(the behavior they actually ran); they do not collide with an explicit modern
0 commit comments