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

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 the Part 2 validation plan can cite for a safety-related control function. Before anything else on this page: Provael computes no Performance Level — no PL, no PLr, no MTTFd, no diagnostic coverage, no CCF — and no SIL, and makes no functional-safety claim. A PL is determined from architecture and those quantities by the designer and confirmed by validation. An attack-success rate is none of those inputs and must never be presented as one.

A maintained international standard, not a dated obligation. It is the standard a machinery validation plan is written against.Evidence, not certification.
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 reworded instruction is not a failure mode the categories anticipate.
The hook

Where a red-team result fits

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.

What a PL is made of, and why an ASR is not one of them

Performance Level comes from category, MTTFd, diagnostic coverage and common-cause failure. 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.

What Provael maps to it

Evidence produced

  • 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.
  • The one measured mitigation Provael has published: adversarial ASR 67.5% [52-80%] to 7.5% [3-20%] on the CPU fixture suite, benign false-positive rate unchanged at 0%. 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.
  • What this does NOT give you: a Performance Level, a PLr, an MTTFd, a diagnostic-coverage figure, a common-cause-failure rating, or a validation conclusion. Those are produced by your design and confirmed by your validation, and Provael is one input among them.
Timing

Dates (verified 26 Jul 2026)

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