STALE: OUR MEASUREMENT

Our published benchmark result was measured with v0.41.2, 5 releases ago, past this project's own 2-release window, and the newest real-model measurement, dated 2026-09-18, is past this project's own 7-day window. That is our own number, not your assessment, which runs against your policy on the current release. Why, and what unblocks it

STALE: REGULATORY CLOCK

The regulatory entries on this page were last checked against their primary sources on — 34 days before this build’s anchor of , past this project’s own 30-day window. Every date here was true when it was read and has not been re-read since. Verify against the primary source before relying on it. The clock, with every source

ProvaelGitHub, star the repositoryQuickstart
IEC 61508 (E/E/PE safety-related systems)

IEC 61508 · functional safety

IEC 61508 is the base functional-safety standard for electrical, electronic and programmable electronic safety-related systems. A Provael result is one input to the argument you make under it: measured evidence of how a policy behaved under adversarial input. An attack-success rate is not a SIL and cannot be converted into one.

Timing A maintained international standard, not a dated obligation.

Use it for

What a Provael report can be used for

Systematic capability

The argument that a safety-related element is free of systematic faults has to account for how the element behaves under inputs it was not designed for. A measured attack-success rate, with its interval and its benign control, is a record of exactly that — an input to the argument, never the conclusion.

The evidence

  • report.json#/by_attack — the per-attack attack-success rate, each with its 95% Wilson confidence interval and the benign false-positive control it is read against.
  • report.mitigation.json — the pre/post measurement where a defence was applied, so a mitigation claim carries a number rather than an assertion.
  • attestation.json — an Ed25519-signed, dated bundle binding the result to the exact report digest, so an assessor can verify the evidence was not edited after the fact.
  • dossier.oscal.json — the same evidence as OSCAL assessment-results, for a GRC toolchain that ingests it directly.
  • Provael has published 2 measured mitigations, each on the deterministic CPU stub fixture, and none is a measured risk reduction on a real checkpoint. The instruction-canonicalization study moved adversarial ASR from 67.5% [52–80%] to 7.5% [3–20%] (benign false-positive rate 0.0% → 0.0%) on the fixture suite. The study calls that result credited and substantially circular, above its own results table: the fixture’s danger score is itself lexical, and the attack’s payload is the same adverbial text the defence strips. It is quoted here with that caveat, because a mitigation number quoted without it would be the exact overclaim this page argues against.
Limits

What it cannot be used for

A mapping identifies possible relevance. It does not establish that this framework applies to your product, that anything here is compliance, that an assessor or insurer will accept it, or a real-world risk probability. Whether it applies to your product depends on your role, market and product class: a question for your counsel, not a determination this page makes.

  • No SIL determination, no Performance Level, and no claim that a system is functionally safe. Provael measures policy behaviour and hands you the artifact; determining systematic capability, and the whole lifecycle around it, stays with the designer and the assessor.
  • The action-channel (EAI04) evidence these rows lean on is stub-validated today. The EAI04 action-space study records it as not-applicable on the real policies tested, because the out-of-band directive channel it uses is honoured by the deterministic fixture and not by a real VLA, which reads images and instructions only. Filing against IEC 61508 today means filing fixture evidence with its transfer statement attached.
  • Simulation evidence for the tested checkpoint and protocol. Physical safety and conformity require separate assessment.
  • Provael measures adversarial robustness - susceptibility to manipulation - not general accuracy, reliability, or functional safety.
  • The measured result uses templated, auditable attacks; the search-based families (optimized, universal_patch, gradient_patch) have no real-policy rate. Results are a floor on susceptibility - a behavioural lower bound, not a certified worst-case bound.
  • Provael’s own Embodied AI Security Top 10 is an independent taxonomy maintained by Provael, not one of the instruments on this page; a mapping onto it is a categorisation, not a legal or standards requirement.
Evidence, not certification

Running Provael does not make a system compliant or certified - it generates measurements you can put into a conformity or assurance file. Provael is not a notified body, a lab, or a certification scheme.

Independent project. Not affiliated with or endorsed by ISO, the EU, NIST, IEC, OWASP, or MITRE. Not legal advice.

Clause references are indicative: check each against the text you hold before you cite it.

What it is

The framework

  • IEC 61508 is the umbrella functional-safety standard from which sector standards (ISO 13849, ISO 26262, IEC 62061) derive.
  • It governs the safety lifecycle of E/E/PE safety-related systems and introduces Safety Integrity Levels (SIL 1-4) as a measure of the risk reduction a safety function delivers.
  • Systematic capability is the part a machine-learned component stresses hardest: it asks what confidence you have that the element is free of systematic faults, which is a question about process and evidence rather than about failure rates.
  • It is named explicitly in the NVIDIA Halos AI Systems Inspection Lab programme as one of the standards robot software is assessed against before third-party certification (see Primary references).
Timing

Dates (each line shows when it was checked)

Status
In force, maintainedIEC 61508 is a maintained series rather than a regulation with an application date. The date that matters to you is set by your certification body. (no check date recorded)
NVIDIA Halos AI Systems Inspection Lab announced
22 June 2026The programme names IEC 61508 among the standards robot software is assessed against. Verified against the NVIDIA newsroom release (checked 1 August 2026)

Check the live EUR-Lex or ISO text before relying on a date.

Sources

Primary references

Sample SARIF ↓All frameworks

See what a report contains.

The sample report comes from a public run and is published in full, nothing redacted. To have this mapping filled in for your own policy, request a scoping call.

See the sample reportRequest a scoping call