STALE MEASUREMENTNewest real-model measurement: 26 days old, measured with v0.32.0; 7 releases have shipped since, past this project’s own 7-day window. Why, and what unblocks it

ProvaelStar on GitHubQuickstart
ProductEvidenceTop 10LeaderboardCompliancePricingDocsStar on GitHub Quickstart

STALE CLOCKThe regulatory entries on this page were last checked against their primary sources on — 39 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

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. Provael produces one input to the argument you make under it — measured evidence of how a policy behaved under adversarial input. Read the next sentence before the rest of this page: Provael computes no SIL and no Performance Level, and makes no functional-safety claim. Determining systematic capability, and the whole lifecycle around it, is your assessor’s work. An attack-success rate is not a SIL and cannot be converted into one.

A maintained international standard, not a dated obligation. It becomes a deadline when your certification body schedules the assessment.Evidence, not certification.
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).
The hook

Where a red-team result fits

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.

What Provael does not do

No SIL determination. No Performance Level. No claim that a system is functionally safe. Provael measures policy behaviour in simulation and hands you the artifact; the determination stays with the designer and the assessor.

What Provael maps to it

Evidence produced

  • 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.
  • The one measured mitigation Provael has published: adversarial ASR 67.5% [52-80%] to 7.5% [3-20%] on the CPU fixture suite, with the benign false-positive rate unchanged at 0%. That result is credited and substantially circular — the study says so above its own results table, because the fixture’s danger score is itself lexical and the attack’s payload is the same adverbial text the defence strips. It is reported here with that caveat attached, because a mitigation number quoted without it would be the exact overclaim this page is arguing against.
  • 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.
Timing

Dates (verified 26 Jul 2026)

Status
In force, maintained
IEC 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.
NVIDIA Halos AI Systems Inspection Lab announced
22 June 2026
The programme names IEC 61508 among the standards robot software is assessed against. Verified against the NVIDIA newsroom release on 1 August 2026.

Not legal advice; verify the live EUR-Lex/ISO text at launch before relying on these dates.

Sources

Primary references

How to read this mapping

What it is - and isn’t

  • adversarial-only - Provael measures adversarial robustness - susceptibility to manipulation - not general accuracy, reliability, or functional safety.
  • evidence-not-certification - The output is evidence you file, not a certificate. Provael is not a notified body, a lab, or a certification scheme.
  • behavioural-not-worst-case - Attacks are templated and auditable, not gradient- or search-optimised. Results are a floor on susceptibility - a behavioural lower bound, not a certified worst-case bound.
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.

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

Clause references are indicative; a wrong clause citation is worse than a missing one.

Turn this into filed evidence.

Download the redacted sample pack, or book an assessment to get the crosswalk filled in for your policy.

Sample SARIF ↓Book an assessment