Submission intake. Upload the manifest and evidence archive that `nexbench submit` produced — validation runs locally before durable, authenticated intake.
Intake
Validate, then submit. Hand-edited manifests fail by construction: scores must sit on the achievable trial grid and the runId is a content hash over the results — only the harness can mint both.
FIG.S1
Run manifest · nexbench.run/2.1
FIG.S2
Check verdicts
Paste a manifest and validate to see per-check verdicts.
Enforcement
Twelve immediate checks, followed by authoritative evidence verification. The browser catches manifest errors early. Durable intake, full evidence validation, private re-execution, signature verification, and admission are enforced by trusted backend boundaries.
Schema shape
Manifest parses as nexbench.run/2.1 with every required block present and correctly typed.
Suite & environment pins
Suite name/version, task counts, trials, and the environment-pins digest match the published release — runs against modified forks or corpora are rejected.
Metric bounds & budgets
Rates within [0,100]; agent runs must respect the per-task budgets (15 min, $10).
Trial-grid alignment
Every rate must sit on the mathematically achievable grid (m / tasks·trials). Hand-typed "pretty" numbers almost never do — this catches fabricated scores.
Internal consistency
pass^5 cannot exceed weighted pass@1; category set must be exactly the eight published categories.
Run-id recomputation
The runId is a content hash over agent identity, suite pins, and results. It is recomputed on intake — any post-mint edit to the manifest breaks it.
Canary attestation
The harness embeds a canary GUID in every task file and scans model output for it. Runs without a clean canary attestation are rejected as contaminated.
Duplicate run / trace
The runId and trace-archive root are checked against every listed run. Resubmitting an existing run — or replaying someone else’s traces — collides here.
Near-duplicate scores
A score vector within one trial-grid step of an existing entry in every category is flagged as a probable relabeled copy and held for manual review.
Published harness build
The compiled scored-runtime hash must match a published build. Unknown builds can only enter as self-reported: patched code could ship easier verifiers.
Submitter identity
A contactable submitter (email or HTTPS URL) is required; verified-tier re-execution is coordinated through it. One entry per agent+model+scaffold configuration.
Unexpected fields
Fields outside the schema are flagged — a common vector for spoofed badges and lookalike metrics.
Pipeline
From manifest to board. Three evidence-gated stages between a local run and an admitted, verified entry.
The manifest checks run in your browser for immediate feedback. The intake service independently validates the manifest and full evidence archive before scheduling verification.
Authenticated submissions receive an idempotent database-backed receipt. Their status, rejection code, audit history, and evidence reference survive restarts and can be polled by the submitting organization.
Nexis re-executes all 214 tasks across five trials in isolated pinned environments. Only a matching signed verifier attestation can admit the result to the public leaderboard.
No harness run yet? The guide takes you from install to a mintable manifest in four steps.