Benchmark request lifecycle

The states

pending — submitted; awaiting triage. Editors decide whether the request is in scope, well-formed, and measurable. accepted — the request has been scoped and is queued for an operator with the right hardware. claimed — an operator has committed to running it; this is a soft lock, not a hard one. The operator can release the claim back to accepted at any time.

measured — the result has been published and tied to the request. This is the terminal happy-path state. The triple gains a measurement; subsequent reproductions attach to that measurement, not back to the request.

rejected — the request was out of scope (asking us to measure a hosted API, for example), or the configuration was unverifiable. duplicate — the request matches an existing benchmark already in the catalog; the contributor is pointed at the existing row. archived — accepted, but no operator picked it up within the freshness window. Archived requests can be revived by anyone.

The color encoding follows queue conventions used elsewhere on the site: amber for waiting (pending), blue for ready (accepted), purple for in-flight (claimed), green for done (measured), red for declined (rejected), gray for resolved- but-not-measured (duplicate, archived). The vocabulary is load-bearing — every list view, admin action, and email template uses these exact strings.