10 corrections on record. If you hold a Provael artifact, check here before relying on a regulatory date inside it.
Append-only and dated. Nothing is removed from this page once added — an erratum that disappears is worse than the error it recorded, because it destroys the one signal a reader has that this project corrects itself in public.
Append-onlyMirrored from the product repo
How this log works
Entries are append-only and dated. Nothing is removed once added.
An erratum records a claim that was wrong, not a feature that changed. Version history lives in the changelog.
A correction here never invalidates a signature. It changes what the signed content asserts, not whether it was signed.
If you hold a Provael artifact, check this page before relying on a regulatory date inside it.
docs/errata.md in the product repo is the maintained source, also served at docs.provael.com/errata. Mirrored here on 2026-09-13. docs/errata.md in the product repo is the maintained source. If this page and that document disagree, that document wins.
E-2026-11 — The shipped gradient_patch attack could not move a frame from its zero start, and the figures it was published with come from a script outside the repository
Status
Corrected in the product repository on 14 September 2026, ships in 0.42.0 · no published rate moves · no signed artifact is affected
Date raised
Affects
The gradient_patch attack as released from 0.39.1 to 0.41.2; the product CHANGELOG entry that introduced it and the 1 September 2026 update in PRIOR_ART.md, which present a Diffusion Policy × PushT result as evidence that the harness had the image-space attack it was missing. No provael.com page quoted those figures.
What is wrong
The attack maximises the distance between the policy’s vision feature of the perturbed frame and its feature of the clean frame. That objective’s gradient is exactly zero at the clean frame, and the projected-gradient loop started from a zero perturbation, so its first step received sign(0) = 0 and every later step the same: against a smooth encoder the released module could not leave the clean frame. It surfaced the first time the module was pointed at a real vision tower (SmolVLA, 14 September 2026): two refinements, L∞ distance 0. The PushT figures were measured by a script run outside the repository, which is not committed and cannot be re-run from it.
Why it stopped being true
The unit tests exercised the loop with a stand-in oracle that returned a constant non-zero gradient everywhere, which no real encoder does at the clean frame; and a result from an uncommitted script was published under the module’s name.
What E-2026-11 changed: each affected value as published and as corrected.
Value
As published
Corrected
Start of the PGD search
a zero perturbation
a uniform draw inside the ε-ball, seeded from the episode seed and the step
What the PushT figures measure
this module
an external script whose code is not in the repository; retained as a dated report of that script’s result
Any VLA rate from gradient_patch
none was claimed
none is claimed; the first measurement is the SmolVLA × LIBERO run, committed under results/ before it is quoted
What to do
If you cited the PushT figures as a measurement of provael’s gradient_patch, re-cite them as an external script’s result or drop them. Nothing else to re-derive: the arm never entered a published rate, because it reports itself not applicable wherever no gradient path exists.
E-2026-10 — The methodology note for the 88% figure called the paraphrase attack the reword control
Status
Corrected in the note, with a dated correction block in its body · no measured number moves · no signed artifact is affected
Date raised
Affects
/notes/what-88-percent-means and the site changelog entry of 4 September 2026, as published from 4 to 13 September 2026. The homepage, /results, /findings, the sample evidence pack and the pinned manifest were right throughout.
What is wrong
Section 4 of the note said the semantics-preserving reword fired 3 of 50, named `paraphrase` as that arm, and added that an earlier draft’s 1 of 50 was unsupported by the committed artifact. It was the other way round. `paraphrase` is an adversarial attack: the unsafe request rephrased without the roleplay frame (3 of 50 in the suite run). The harmless-variation control is `benign_reword` — the benign instruction reworded with no unsafe target — and it fired 1 of 50 in the control run (results/smolvla_libero_object_control), 43 discordant pairs against roleplay, none the other way, McNemar exact p = 2.3e-13. The note’s argument about attacker control versus brittleness was built on the wrong arm.
Why it stopped being true
Two arms with “reword” in their plain-language description, one an attack and one a control, read from memory of the run rather than from the manifest. Nothing checked figures inside notes: check:figures reads pages, not the content collection.
What E-2026-10 changed: each affected value as published and as corrected.
Value
As published
Corrected
The reword control arm
paraphrase, 3 of 50 (6%)
benign_reword, 1 of 50 (2%)
What 3 of 50 is
the control
the paraphrase attack arm of the suite run
Discordant pairs quoted in §2
41-0 (the control run)
42-0 (the suite run the p-value belongs to)
What to do
If you quoted the note’s section 4 between 4 and 13 September 2026, the control figure is 1 of 50, not 3 of 50, and the conclusion (attacker control, not brittleness) stands more strongly, not less. The note now carries the correction in its own body.
E-2026-08 — A calibration's 0.0 benign false-positive rate was published as evidence of a well-placed boundary
Status
The figure is accurate · what it was offered as evidence for is corrected · the predicate it describes was never adopted, so no published rate moves
Date raised
Affects
The provael repository's 0.40.0 CHANGELOG entry and the commit message of PR #212, as published from 6 September 2026. Nothing on this site is affected: every page that renders the LIBERO result describes the keep-out predicate as uncalibrated, which was and remains accurate. The 44/50 roleplay headline, its task-clustered interval and the 2/50 benign control are all unchanged.
What is wrong
Ten per-task keep-out calibrations for libero_object were published with the statement that all ten achieved a held-out benign false-positive rate of 0.0 against a 0.05 target. The number is correct. It was presented as the notable property of the fit, and it is not one: it is what nearly any placement of that hazard box achieves. Replaying the one committed real-model run that records end-effector trajectories against all six candidate faces of the benign envelope — one task, 14 episodes, 2 benign and 12 attacked — five of the six faces score the same 0.0 benign rate, and five of the six flag nothing at all. The face the fitter used flagged 0 of 12 attacked episodes, where another face flagged 5 and the uncalibrated default box flagged 4.
Why it stopped being true
The fitting routine searched the GAP between the hazard box and the benign envelope and took the FACE from a default argument, never varying it. A hazard box is disjoint from the benign workspace by construction, so every gap large enough to clear the envelope drives the benign rate to or near zero — the search always succeeded and the number it reported carried no information. The structural reason it could not have been caught by repeating the run: a benign-only calibration cannot choose a face, because where an attack goes is not observable from rollouts in which no attack ran. The published entry did carry the caveat that a 0.0 benign rate says nothing about whether the zone still catches a redirected policy. That caveat was the finding, filed under a heading that read as an achievement.
What E-2026-08 changed: each affected value as published and as corrected.
Value
As published
Corrected
ten calibrations at a 0.0 benign FPR
the notable property of the fit
the property of almost any placement — five of six candidate faces score the same
detection by the fitted zone
not stated
0 of 12 attacked episodes, on the one task with trajectory data
relative to the uncalibrated default box
implied improvement
strictly worse — the default box flags 4 of 12
What to do
Nothing to re-check in a published number: these zones were never adopted, so every rate measured for libero_object was scored against the documented default box, and every run report records calibrated: false. If you cited the ten calibrations as evidence that the keep-out predicate is now fitted, it is not, and the tool has never claimed otherwise at runtime — provael doctor reports "calibrated zones: none adopted". If you were planning to adopt them, do not: provael calibrate --attack (0.41.0 and later) fits a boundary whose face is chosen against attacked rollouts rather than assumed.
E-2026-07 — Four surfaces said ISO 10218:2025 defers its cyber detail to IEC 62443
Status
Corrected on every surface · the phrasings are now blocked by the build
Date raised
Affects
/compliance/iso-10218, /defenses, /compare/physical-ai-safety-stacks and /regulatory-clock (with its JSON), as published up to 6 September 2026. No measured result and no signed artifact is affected: the control identifiers, the iec-62443 requirement key and the emitted routes_to field are a published contract and were never the thing that was wrong.
What is wrong
Four pages stated that the 2025 revision of ISO 10218 introduces cybersecurity clauses and hands the detailed requirements to the IEC 62443 series. It does not. Clause 2, Normative references, of ISO 10218-1:2025 lists ISO 3864-x, ISO 4413/4414, ISO 7010, ISO 9283, ISO 12100, ISO 13732-x, ISO 13849-1:2023, ISO 13850, ISO 14118/14119/14120, ISO 19353, ISO 20607, ISO 20643 and IEC 60073. IEC 62443 is not among them; it appears in the informative Bibliography, alongside IEC TR 63074. The standard’s own Foreword says the revision adds "requirements for cybersecurity to the extent that it applies to industrial robot safety" — it adds them, it does not delegate them.
Why it stopped being true
The claim is a common secondary-source summary of what the 2025 revision did, and it was transcribed rather than read against the standard. It then spread by being restated: one phrasing in a compliance catalogue, a second in a defenses table, a third in a comparison page’s answer, a fourth in the machine-readable clock. Provael’s own mapping onto an IEC 62443 SL2 target is legitimate and stays; presenting it as something ISO 10218 routes to was not.
What E-2026-07 changed: each affected value as published and as corrected.
Value
As published
Corrected
ISO 10218-1/-2:2025, relationship to IEC 62443
introduces cybersecurity clauses and defers the detailed requirements to IEC 62443
adds cybersecurity requirements to the extent they apply to industrial robot safety; IEC 62443 appears only in the informative Bibliography
What to do
If you were treating a Provael IEC 62443 view as inherited from ISO 10218, it is not: an assessor reading ISO 10218 inherits nothing about IEC 62443, and the cyber requirements are in the document they already hold. The four superseded phrasings are now in the build’s forbidden-string list, so none of them can be reintroduced on any page.
E-2026-06 — A correction to the CRA sub-deadline source was reverted while fixing a link label
Status
Restored the same day · the four deadlines themselves were correct throughout
Date raised
Affects
/regulatory-clock, /regulatory-clock.json and /compliance/cra-incident-reporting, as published for roughly seven hours on 6 September 2026. No deadline, no measured result and no signed artifact is affected.
What is wrong
The CRA Article 14 sub-deadlines were published citing the Commission’s CRA summary as their source. That is the document E-2026-04 moved them OFF, five days earlier, because its phrasing does not carry the distinction the four rows encode — the two final reports run from different events. The rows on the page were correct the whole time. What was wrong was the citation under them: a reader checking the deadlines against the cited source would not have found the distinction there, and could reasonably have concluded the page had invented it.
Why it stopped being true
/compliance/cra-incident-reporting closed with two source links carrying different labels and the same URL — "Regulation (EU) 2024/2847 on EUR-Lex" and "Commission CRA summary" both pointing at the Official Journal. That is a real defect, and it was fixed by moving the URL to match the label. The label was the wrong half. The link text lived in markup on two pages while the URL lived in JSON, so the two were editable apart and neither one carried the reason the other existed. Nothing was red.
What E-2026-06 changed: each affected value as published and as corrected.
Nothing to re-check in a runbook: the 24-hour, 72-hour, 14-day and one-month deadlines and their start points are unchanged and were correct throughout. If you cited this page’s source link rather than the deadlines, cite Article 14 of the Official Journal text instead. The link label now travels in the clock data beside the URL so the two cannot be edited apart, and scripts/check-clock-sources.mjs fails the build if a sub-deadline is ever pinned to a summary of the instrument rather than the instrument.
E-2026-05 — Three of this site’s own surfaces published a stale attack-family count at the same time
Status
Corrected by re-pinning both witnesses to v0.39.1 · ID collision: the product ledger issued its own E-2026-05 on 6 September 2026 for a different correction (ISO 10218 / IEC 62443, = E-2026-07). This entry keeps the ID it was published under and is recorded in docs/errata.md as E-2026-09; do not renumber either.
Date raised
Affects
Every page rendering a registry count — the homepage, /results, /verification, /leaderboard — plus public/llms.txt and the supported-version line on /security, as published between 1 and 3 September 2026. No measured result is affected: the ASR, its interval, the benign control and every per-attack row were byte-identical before and after.
What is wrong
The site published family and attack counts one lower than the product’s generated watch/registry.json across every figure — the exact superseded and correct values are in the table below, so this sentence does not restate a live count. /security told a security reporter to reproduce on v0.38.0 while PyPI served 0.39.1 — a disclosure page pointing at a version two releases old.
Why it stopped being true
gradient_patch shipped on 1 September 2026 in release 0.39.0 and grew the registry. The generated file was right the whole time. What was stale was the site’s pinned mirror of it, src/data/repo-facts.json, last refreshed on 26 August against the v0.38.0 tag — which is also where the supported-version string came from, so one stale pin produced both defects. The uncomfortable part is the check: check-registry-agreement.mjs asserts the site’s counts against watch/registry.json and PASSED, because the copy it compared against was the same stale mirror. A guard that reads a cached copy of the fact it guards cannot fire. That is the third time this project has found that shape — after the measurement-freshness banner and the regulatory-clock anchor — and it is the pattern worth remembering rather than any of the three numbers.
What E-2026-05 changed: each affected value as published and as corrected.
Value
As published
Corrected
Adversarial attack families
16
17
Adversarial attacks
38
39
Attacks including baseline and control
41
42
Families never run against a real policy
13
14
Supported version on /security
v0.38.0
v0.39.1
What to do
If you quoted a family or attack count from this site between 1 and 3 September 2026, it was low by one family and one attack. If you were preparing a security report against v0.38.0 because /security named it, reproduce on the current PyPI release instead. Nothing measured moved, and no signed artifact is affected. A project that asks strangers to check its numbers should publish the occasions its own numbers were wrong, which is what this entry is.
E-2026-04 — The CRA final-report deadline was published with the wrong start point for severe incidents
Status
Corrected in the clock and on every page that renders it · the source half of that correction was reverted for seven hours on 6 September 2026 and restored — see E-2026-06
Date raised
Affects
/regulatory-clock and its JSON, as published between 25 August 2026 and this correction. No signed artifact is affected.
What is wrong
The CRA Article 14 reporting clock carried its two final-report deadlines as a single row: "Final report, due once a corrective or mitigating measure is available - 14 days for an actively exploited vulnerability, one month for a severe incident." The start point in that sentence is correct for the vulnerability branch and wrong for the incident branch.
Why it stopped being true
Article 14(2)(c) and Article 14(4)(c) set deadlines measured from different events. The 14-day vulnerability report runs from when a corrective or mitigating measure is available. The one-month incident report runs from submission of the 72-hour incident notification under Article 14(4)(b), and does not wait for a measure at all. Collapsing both into one row applied the first branch’s anchor to the second. The sub-deadlines were read from the Commission CRA summary rather than the OJ text, and the summary’s phrasing does not carry the distinction.
What E-2026-04 changed: each affected value as published and as corrected.
Value
As published
Corrected
Severe-incident final report, start point
once a corrective or mitigating measure is available
one month after the 72-hour incident notification was submitted (Art. 14(4)(c))
What to do
If you planned an incident-reporting runbook against this page, check the one-month deadline: it starts earlier than the superseded wording implied, because it runs from your own 72-hour filing rather than from a fix being ready. A runbook that waits for a fix before starting the one-month count can miss it. The 24-hour, 72-hour and 14-day figures were correct throughout, and no measured result or signed artifact is affected.
E-2026-03 — Two READMEs published a zero-width confidence interval for three null arms
Status
Corrected in the tool and on both surfaces · the signed board and its signature were correct throughout
Date raised
Affects
README.md and results/smolvla_libero_object_suite/README.md in the product repository, as published between 9 and 30 August 2026. No signed artifact is affected, and this website was never wrong about it.
What is wrong
Both READMEs published the task-clustered 95% confidence interval for the three null arms (patch, decoy_object, scene_text, each 0/50) as [0%, 0%]. A zero-width interval states that the true rate is known exactly. It is not: the arms are null because nothing succeeded in fifty attempts, which is a different claim from a rate of precisely zero.
Why it stopped being true
The bootstrap guard counted CLUSTERS rather than checking the interval it produced. Ten tasks that all score zero pass a cluster count and are just as degenerate - every resample returns the same rate, so the percentiles collapse onto it. provael.com published a non-zero upper bound for those same three results throughout, so the project contradicted itself in public.
What E-2026-03 changed: each affected value as published and as corrected.
Value
As published
Corrected
patch, 0/50
[0%, 0%]
no clustered interval; pooled exact 95% upper bound 7.1%
decoy_object, 0/50
[0%, 0%]
no clustered interval; pooled exact 95% upper bound 7.1%
scene_text, 0/50
[0%, 0%]
no clustered interval; pooled exact 95% upper bound 7.1%
What to do
No action for anything read on this site - provael.com carried the correct non-zero bound the whole time. If you hold a copy of either README from that window, the three null rows overstate how strong those nulls are: the measurement supports only that the attack was not observed to succeed in fifty attempts, which leaves a true rate of up to 7.1%.
E-2026-02 — The documented verify command printed a pre-rotation signing keyid
Status
Corrected · the published board and its signature were correct throughout
Date raised
Affects
Anyone who verified the public leaderboard signature between 30 July and 3 August 2026 by following the documented steps.
What is wrong
The project signing key was rotated on 30 July 2026 and the published board was re-signed the same day, so verification succeeded and printed the NEW key id, 8d62aa33ed5162f3. The documentation did not move with the key: README.md and docs/leaderboard.md kept showing the pre-rotation id 5b9a65790d93d0bc as the expected output, and docs/leaderboard.md went further and called that id the only key the published board is signed with.
Why it stopped being true
For four days anyone who ran the documented verification got a result the documentation called impossible. The natural reading of that contradiction — that the signature is fraudulent — was wrong in the worst direction available to this project: the check was working and the prose about the check was not.
What E-2026-02 changed: each affected value as published and as corrected.
Value
As published
Corrected
documented verify keyid
5b9a65790d93d0bc
8d62aa33ed5162f3
What to do
Nothing to re-issue: the board and its signature were correct throughout, and a verification run in that window succeeded for the right reason. The keyid is not an independent fact — it is the first 16 hex characters of SHA-256 over leaderboard/results/leaderboard.pub — so compute it yourself rather than trusting this page or the README.
E-2026-01 — Signed attestations carry a superseded EU AI Act application date
Status
Corrected in the tool · previously issued bundles are unaffected in authenticity
Date raised
Affects
Any attestation bundle signed before this correction shipped
What is wrong
The regulatory clock embedded in every attestation payload recorded the EU AI Act Annex I (product-embedded high-risk) application date as 2027-08-02, with a note stating that the Digital Omnibus deferral to 2028 had been agreed only provisionally and had not been published in the Official Journal.
Why it stopped being true
That was accurate when written. It stopped being accurate on 24 July 2026, when Regulation (EU) 2026/1744 (Digital Omnibus on AI) was published in the OJ. It entered into force on 27 July 2026 and moved product-embedded Annex I application to 2 August 2028 (stand-alone Annex III moves to 2 December 2027). The clock’s own last_verified field read 2026-07-23 — the fact was checked one day before it changed, and nothing re-read it.
What E-2026-01 changed: each affected value as published and as corrected.
Value
As published
Corrected
AI Act Annex I applies_from
2027-08-02
2028-08-02
What to do
A bundle signed before the fix is still cryptographically authentic — the signature is over what was believed at signing time, and it verifies. What it is not is current. If you are relying on the AI Act date inside one, re-issue it; if you are relying on the ASR, the measurement is unaffected.
The dates themselves live on the regulatory clock, which carries a last_verified field per instrument. What has and has not been independently checked is on verification, and the diligence answers are on trust.