Get verified

What verified means#

Three roles, all ordinary publish keys:

• bench.betterbench.v1 pages are eligible, and from L80 1.2 scan.pwdet.v1 pages (pwdet scans). A scan published as generic.report.v1 carries no report to re-run; publish it again with L80 pwdet publish.
• A scan is verified by re-running it: L80 verify reproduce <id> runs pwdet reproduce on the same Hub files at the same commits. A verifier can stamp it only with a re-run that matches (E_REPRODUCTION_REQUIRED otherwise); there are no tolerances to accept.
• A key never sees its own requests in the queue and may never decide on them.
• Quick runs (--quick, or anything under 20 passes) can be verified. The reviewer sees a full_run warning and the badge reads “Verified by Launch80 · quick run”. L80 1.0's own verify check still fails a quick run, so send the request with --skip-checks.
• Pages stay immutable. Verification changes the badge, never the stored payload. A run that needs fixing is published again and the new page is verified.

Tiers and badges#

L80 history --tier verified lists your verified pages. When results are exported to the AwesomeList catalog, verified maps to maintainer_verified and every other tier to author_reported.

Publisher1. Check the run#

$ L80 verify check results.json        # exit 0 if the run qualifies, 4 if not$ L80 verify check <page url>          # the same, plus provenance from your local ledger

The CLI runs the same checks the server applies, plus one only it can: provenance, that the page was published from this machine from a file that has not changed since. It works with no token and no network.

Publisher2. Request review#

$ L80 verify request <page url> --note "vLLM 0.9.3, --max-model-len 32768, launch command in the README of …"$ L80 verify status <page url>$ L80 verify mine                       # your requests and their decisions

Only the key that published the page can ask. The note is for the reviewer: the engine version and launch flags, or a link to a recipe. The request carries your local checks and the hashes from ~/.config/L80/history.jsonl; the server recomputes every check from the stored page and never trusts the client's results alone.

• Passes: the page turns pending and the request joins the queue.
• Fails a server check: the attempt is recorded and closed at once, the page stays unverified, and the CLI prints which checks failed (E_VERIFY_INELIGIBLE). Fix the run, publish again, request again.
• A page with an open request answers E_VERIFY_EXISTS. Ten requests per key per day.

A rejection's reason is shown to you through verify status and verify mine; a rejected page reads like an unverified one to everyone else.

Any key3. Anyone can reproduce#

$ L80 verify queue                       # other keys’ requests, oldest first$ L80 verify show <id>                   # model, engine, hardware, settings, published figures$ L80 verify reproduce <id> --endpoint http://127.0.0.1:8000/v1

The queue is open to every valid key so the community can check runs. It shows each requester's label, never their key. reproduce reads the published results file (GET /api/v1/artifacts/<guid>/payload), reruns BetterBench with the same model, notes and settings against your endpoint, and compares the headline figures:

Verifier keys4. A verifier decides#

$ L80 verify approve <id> --note "matched on 1x RTX 4090"$ L80 verify reject <id> --reason "TTFT is 3x what this hardware does"

Verifier keys A verifier may stamp on review alone. When they reproduced the run, the comparison goes with the stamp and the badge adds “reproduced”. A reproduction outside tolerance needs --accept-differences and a note. A rejection always needs a reason, which the publisher sees. Once decided, a request is closed (E_VERIFY_CLOSED).

A suggested review:

• the numbers are plausible for the stated hardware and engine;
• the engine version and launch flags are stated, in the note or a linked recipe;
• there is no sign of a warm cache or batching games;
• for headline claims, reproduce on matching hardware.

The checks#

The server recomputes these from the stored page, so a modified client cannot talk its way past them. A fail makes the page ineligible; a warning is shown to the reviewer.

Any pwdet scan (scan.pwdet.v1) can be verified. Its checks, recomputed from the stored report, only warn the reviewer about how easily the scan can be re-run; the stamp itself needs a re-run that matches. L80's own verify check still fails some of these, so send the request with --skip-checks.

In the console#

L80 tui has a Verify screen with other keys' requests: p reproduces, and verifiers stamp with a or reject with x. The History screen's v requests verification for the selected page.