STALE MEASUREMENTThe newest real-model measurement on this site is 14 days old — past this project’s own 7-day window. Every measured figure here was true when it was taken and has not been re-measured since. Why, and what unblocks it
2 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-08-22. docs/errata.md in the product repo is the maintained source. If this page and that document disagree, that document wins.
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.
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.
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.