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 13849-1 / ISO 13849-2

ISO 13849-1/-2 · safety-related parts of control systems

ISO 13849 governs the safety-related parts of control systems: Part 1 is design, Part 2 is validation. Provael supplies adversarial fault cases that a Part 2 validation plan can cite for a safety-related control function. An attack-success rate is not a Performance Level and is not one of its inputs.

Timing A maintained international standard, not a dated obligation.

Use it for

What a Provael report can be used for

Part 2 — validation

A validation plan lists the fault cases the safety-related control function must withstand. An adversarial episode that drove the policy out of its benign envelope is a fault case with a measured rate, an interval and a benign control — evidence the plan can cite, at the weight it deserves.

The evidence

  • report.json#/by_attack — per-attack ASR with its 95% Wilson interval and the benign false-positive control, usable as enumerated fault cases in the validation plan.
  • report.mitigation.json — the pre/post result where a defence was applied, so a claimed risk reduction is measured rather than asserted.
  • attestation.json — the signed, dated bundle binding those numbers to the report digest.
  • dossier.oscal.json — OSCAL assessment-results for the assessor’s toolchain.
  • 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: credited, and substantially circular. The study leads with that judgement rather than burying it, and this page repeats it rather than quoting the improvement alone.
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 Performance Level and no SIL: no PL, no PLr, no MTTFd, no diagnostic-coverage figure, no common-cause-failure rating. A PL comes from category, MTTFd, diagnostic coverage and common-cause failure, determined by the designer and confirmed by validation, and Provael measures none of those. A vendor offering to turn an attack-success rate into a PL is selling you a conversion that does not exist.
  • No functional-safety claim and no validation conclusion. Those are produced by your design and confirmed by your validation, and Provael is one input among them.
  • 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.
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

  • ISO 13849-1 specifies safety requirements and guidance for designing the safety-related parts of control systems, expressed as a required Performance Level (PLr) and an achieved PL from category, MTTFd, diagnostic coverage and common-cause failure.
  • ISO 13849-2 specifies the validation process: the plan, the analysis, and the tests that confirm the design meets its specified PL.
  • It is the standard a machinery integrator’s control-system file is written against, and it is named in the NVIDIA Halos inspection programme alongside IEC 61508 (see Primary references).
  • Machine-learned behaviour sits awkwardly in it: the framework was built for components whose failure modes are enumerable, and a policy driven off-task by a reframed instruction is not a failure mode the categories anticipate.
Timing

Dates (each line shows when it was checked)

Status
In force, maintainedISO 13849-1 and -2 are maintained standards rather than regulations with an application date. (no check date recorded)
NVIDIA Halos AI Systems Inspection Lab announced
22 June 2026The programme names ISO 13849 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