The dashboard's progress chart carried a series legended "durably committed" that queried jetstream_backfill_progress_completed -- a process-local gauge that resets to zero on restart and climbs again. The series under that label was showing this process's work, not the archive's. That is the mislabel behind the July experiment's worst symptom: restarts replayed work while the dashboard read as progress. stream_backfill_repos_durable{status=...} is read from the metadata store at scrape time, so it is the same number the store would give after any restart. Measured across a real restart on one data dir: 22 complete before, 49 after -- it continues the curve rather than starting a new one. The generator now points the "durably committed" legend at it, and a contract test pins which metric backs that legend so the two cannot drift apart again. Absence stays distinguishable from zero: a data dir with no repository state emits no series at all rather than zero-of-zero, because a progress panel reading 0/0 is worse than a gap. zig build test (311), ReleaseSafe, dashboard-test, http-metrics-contract. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>