Questions people actually ask.

They test the language and tool-call layer brilliantly - but they do not model the action space. A vision-language-action policy turns an instruction into a trajectory, and that trajectory is where the embodied failure lives. Text-only tools have nothing to score there. Use them for the language layer; use Provael for the action layer.

No - it is complementary. If your robot has an LLM in the loop, red-team the text with garak or PyRIT and red-team the resulting motion with Provael. The two cover different halves of the same system.

Every Provael result is an attack-success rate with a 95% Wilson confidence interval and a matched benign-control false-positive rate - plus published null results when an attack does not transfer. That is a measurement you can file, not a one-off "we broke it."

No. Provael is CPU-first: the deterministic core and every attack family except the adversarial-patch search (`optimized_patch`, which needs a real camera frame) run without a GPU. Real-model transfer tests are optional and gated behind an extra.

We measure both. Every mitigation we recommend ships with a pre/post attack-success rate and its own 95% confidence interval, so a fix is evidenced rather than asserted. two defenses have been measured end to end under that protocol: instruction canonicalization takes the stub suite from 67.5% [52–80%] to 7.5% [3–20%] (n=40), and an action envelope clamps what leaves the policy rather than what goes in. Both carry their own caveat on the page - the envelope's credit is partly circular by construction, because its bounds come from the benign policy's own magnitudes, and the study says so before it reports a rate. See /defenses for the per-family tables.

You are not paying for the software - the CLI, every attack family, the attack-success rate with its benign control, SARIF, the GitHub Action and local attestation are free and stay free. You are paying for the operated work a tool cannot do for you: someone independent choosing the threat model for your policy, running it, and signing the evidence pack. If your team can do that in-house, run it yourself. That is the honest answer and it costs us some deals.

One person - Sattyam Jain - and the About page says so rather than hiding behind a "we". That is a real risk for anything you depend on, so it is worth naming: the tool is Apache-2.0 and forkable, every result is reproducible from a committed recipe, and no evidence you hold depends on this project continuing to exist. What a single maintainer cannot promise is an SLA, and none is published for that reason.

Not yet measured, and no sim-to-real claim is made anywhere on this site. Every published number comes from simulation. What exists is a protocol - SO-ARM101 table-top arm, the same SmolVLA checkpoint, instruction family only, n = 5 per condition, a geometric keep-out predicate, filmed and seeded - registered on 24 July 2026 and published at /sim-to-real BEFORE the trials run, so a reader can check the design was fixed before there was data to fit it to. The null hypothesis is written down too: that sim and real disagree. When it runs, it reports a directional correlation for one arm, one policy and one task - never a real-robot attack-success rate.

No. No notified body, certification body, accreditation body, insurer or standards committee has reviewed Provael, and there are no published customer case studies - /case-studies says zero in its own heading rather than sitting empty. The nearest thing to external checkability is that the physical-transfer protocol at /sim-to-real is published in advance of its own trials, so that one result can be judged against a design nobody chose after seeing it. External validation is a real gap and the site states it in the places a buyer looks, instead of implying otherwise through silence. If you want to close that gap rather than read about it, /verification carries the exact commit, recipe and command to reproduce every published row, and the register of who has reproduced what - empty today, and labelled empty.

The full evidence pack is published at /sample-evidence-pack - the whole artifact, not a summary, using the project’s own public reference run. Read it before booking anything. It is the same shape you would receive: a measured attack-success rate with its confidence interval and benign control, the scope limits stated at the same size as the number, SARIF, and a compliance crosswalk.