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
ISO/IEC TR 5469:2024

ISO/IEC TR 5469:2024

ISO/IEC TR 5469:2024 is the bridge between classical functional safety (IEC 61508 and its sector children) and machine-learned components: properties, risk factors and methods for using AI inside, or alongside, a safety-related function. A Provael result is verification-and-validation evidence for such an AI element: one input to the AI-safety lifecycle, not a determination within it.

Timing Published January 2024. A Technical Report, not a certifiable standard - it informs a functional-safety argument, it does not confer one.

Use it for

What a Provael report can be used for

Verification & validation of an AI element

In plain words: an adversarial-robustness rate with a matched benign control is evidence about the AI element, produced repeatably, for its verification and validation. Provael’s catalogue entry reads “AI — Functional safety and AI systems (verification & validation evidence)”, with the signal “Adversarial-robustness ASR + benign-FPR control as V&V evidence for an AI element used in or alongside a safety function (the report is one input to the AI-safety lifecycle)”.

The evidence

  • An attack-success rate per EAI risk with a 95% interval and a benign false-positive control, as V&V evidence for the AI element.
  • The benign control is the part a functional-safety reviewer will ask for first: a rate with no baseline cannot separate an induced failure from a noisy detector.
  • Retained, digest-bound run artifacts (report.json#/by_attack and report.json#/benign_fpr) so the evidence can be re-checked rather than taken on trust.
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.

  • 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

  • A Technical Report from ISO/IEC JTC 1/SC 42, published January 2024 and applicable across sectors rather than tied to one.
  • It covers three distinct situations, and they are not interchangeable: AI used inside a safety-related function, non-AI safety functions used to constrain AI-controlled equipment, and AI used to design or develop a safety function.
  • A TR is informative. It carries no clauses you can be certified against, so nothing here is a conformity route - it is vocabulary and method that a safety argument can cite.
  • Related: ISO/IEC 23894:2023 (AI risk management) and ISO/IEC 42001:2023 (AI management system). TR 5469 is the functional-safety-facing one of the three.
Timing

Dates (each line shows when it was checked)

Published
January 2024ISO/IEC JTC 1/SC 42 (checked 10 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