# Trace logging note

The final audit found a logging bug, not an inference or scoring change. In the frozen core.ts, judgePayload put the accepted-work array into the Jev state by reference. run.ts serialized the HTTP body synchronously before awaiting each judgment, so the API saw only the prior selected steps. But the request object retained in calls[] still referenced that array. Subsequent accepted.push(...) calls caused every saved Jev request log to show the eventual full path.

Original files in results/traces are preserved unchanged. results/reconstructed-jev-traces contains explicitly labeled derived copies. For step i, accepted_work is rebuilt from selected steps 0 through i-1, and checked byte-for-byte against the accepted-work prefix in the corresponding generator request, which was recorded as an immutable string. These reconstructions follow the frozen harness; they are not independent network captures.

No prompts, choices, model outputs, token usage, runtime measurements, stopping decisions, extracted answers, or accuracy scores were changed. Gold answers were never part of either judge's state.

The audit reports how many request records needed reconstruction. Both original and reconstructed traces are included in the download. The frozen inference files and hashes are retained. For a new run, fix logging by changing `accepted_work: accepted` to `accepted_work: [...accepted]` in core.ts before freezing that new run's hashes.