Benchmark lifecycle — full pipeline

What the diagram shows

The seven-state lifecycle diagram is honest about the request enum, but it stops where the request becomes a measurement. In practice the trip from a typed-in form to a high-confidence row is longer. Editorial moderates the request first; an operator claims it; the operator runs the measurement and submits it through /submit/benchmark; editorial moderates the submission; the row goes approved-public; subsequent operators reproduce it; once two distinct independent operators have confirmed the numbers, the row earns the “independently- reproduced” label and the confidence tier promotes.

The three side branches are deliberately drawn faint. They are real, they happen often, and they are terminal. A rejected request never appears on /benchmarks/wanted. A duplicate submission gets pointed back at the existing row. A stale row ages out after eighteen months because stack churn (driver updates, runtime versions, model re-releases) eventually erodes the comparability of an old measurement; the catalog protects itself by retiring rows that have not been reproduced recently.

The discipline this diagram enforces is the asymmetry between submission and reproduction. Anyone can file a request. Anyone can submit a measurement. But the catalog only promotes a row when independent operators on distinct hardware have confirmed it. That is the line between “a number we have” and “a number you can rely on for a buying decision.”

Use this diagram in articles, blog posts, or onboarding decks where you need to explain what “published, reviewed, and independently reproduced” actually means in editorial practice. The state names match the schema enums and the moderation queue UI; the same vocabulary travels through the codebase, the admin dashboard, and the public market.