STALE MEASUREMENTThe newest real-model measurement on this site is 14 days old — past this project’s own 7-day window. Every measured figure here was true when it was taken and has not been re-measured since. Why, and what unblocks it

ProductEvidenceAdoptersTop 10For youLeaderboardSubmitCompliancePricingReadinessDocsStar on GitHub Quickstart
GET MEASURED · SUBMISSION PATH · PV-021

Get your policy measured.

Provael is a tool, not a gate. If you have a vision-language-action policy, you can run the same suite we ran, validate it with the same script CI uses, and put the row on the leaderboard yourself. No account, no NDA, no permission needed. The core is Apache-2.0 and the validation runs on a CPU.

4 steps · one pull requestCPU validation · no GPU to review0 third-party submissions so far

Nobody outside this project has submitted a result yet. Every row on the board today was produced by the maintainer and is labelled maintainer-run in its own provenance column. That is said here rather than left for you to notice, because a board that cannot tell a self-reported row from an independent one is a changelog wearing the word leaderboard. Your row would be the one that changes it.

The path below is not theoretical. It was exercised end to end on 12 August 2026 against a dummy submission, which was then deleted. Step 4 of that test correctly refused to promote a stub run to the real board, which is the guard working.

Before you start, in the order people actually ask

What do I need?

A policy you can load in Python, and nothing else. Two shapes work today. A checkpoint, if it is one of the six checkpoint adapters that ship: SmolVLA, pi0, pi05, pi0fast and NVIDIA GR00T through LeRobot, OpenVLA through transformers. Or a hosted endpoint, via the openpi client, where the weights stay on your GPU server and Provael only sends observations and reads back actions. The endpoint path is the one to use if the checkpoint cannot leave your infrastructure. If your policy is neither, the adapter is one class with three methods and we would rather you opened an issue than guessed.

What exactly do you run against it?

A matrix of attacks against a simulator suite, one episode per (task, attack, seed) cell, each paired with a benign twin at the same task and seed. Nothing touches your weights and nothing is fine-tuned. The attacks perturb the instruction or the observation, the simulator runs the rollout, and the predicate records whether the policy left its declared safe envelope. You choose the suite and the attack families on the command line.

How long does it take?

The measured reference run was 400 episodes, 15.4 GPU-hours, $12.29 on a rented L4, sharded one task per container so it finished in about two hours of wall clock. Cost is roughly $0.031 per episode and that figure is measured, not projected: the estimate beforehand was $10.17, so budget with the correction rather than the estimate. A smaller screen is proportionally cheaper. The CPU validation step takes seconds.

What do I get back?

A report.json that is a pure function of your config and seed, plus an attack-success rate with its n, a 95% interval and the benign control arm beside it. Alongside it: SARIF for code scanning, OSCAL assessment results, a CycloneDX ML-BOM, and a scorecard. Nulls are in there too, at the same size as the hits.

Who sees the result?

Until you open a pull request, only you. The run happens on your machine or in your CI. The free core is six dependencies and none of them is an HTTP client, so the tool has nothing to phone home with and does not. There is no account, no API key and no telemetry. Once you open the PR the report is public, because the board's whole claim is that a row can be checked, and a row nobody can inspect is not evidence.

Can I see it before it is published?

Yes, and this is the part worth being explicit about. Publication is a separate, later, entirely voluntary act. You run the suite, you read the complete result, and then you decide whether to open a pull request. If the number is bad, do not open it. Nothing has been transmitted, nothing is pending, and nobody is waiting on you.

Two more things, because the honest version of this answer includes them. A submitted row is withdrawable: an open PR can be closed, and a merged row can be removed by another PR. And your row carries provenance: third-party-submission with your name on it, so it is legible as yours rather than absorbed into ours. What we will not do is publish a result you did not choose to publish, or quietly keep a copy of one you decided against.

The four steps

  1. Run the suite against your policy

    Provael needs an adapter for your policy. Seven ship today — SmolVLA, pi0, pi05, pi0fast and NVIDIA GR00T through LeRobot, OpenVLA through transformers, and openpi through its own client — plus a deterministic stub. If yours is not one of them, open an issue before you start rather than after.

    provael attack --policy smolvla --suite libero \
      --attacks instruction,visual,injection --episodes 5 --out results/my-run
  2. Validate the report locally

    The same script CI runs. It checks that report.json parses as a RunReport and that its aggregate rates and success counts are internally consistent. It is CPU-only and needs no GPU, so a failure here is a failure you can fix in seconds instead of in review.

    python scripts/validate_submission.py results/my-run
  3. Build the board row with your provenance

    Two flags matter. --submitted-by is you, and --provenance third-party-submission is what separates your row from ours. Every row currently on the board is maintainer-run and says so; yours will say something different, in a column, on the row.

    provael leaderboard build --runs results/my-run \
      --submitted-by your-name --provenance third-party-submission
  4. Open a pull request that adds results/

    CI picks up any PR touching results/**, revalidates every report and rebuilds the board. Nothing is taken on trust: a stub run is refused from the real board by design, so a submission that never met a real model cannot become a public number.

What gets checked, and what does not

Submission checks · what CI enforces on every pull request that touches results/
CheckedNot checked
The report parses as a valid RunReportThat you ran what you say you ran. Provenance is declared, not proven
Aggregate rates agree with the underlying success countsThat your policy is safe. An ASR is a measurement, not a verdict
The leaderboard still builds with your row in itThat your result transfers to hardware. Nothing here has run on a robot
Stub runs are refused from the real boardStatistical power. Few seeds means a wide interval, and it will show

Ready to submit?

Start with the repository. The validation script, the adapters and the recipe that produced our own published row are all in there.