Recall

When we are the ones who were wrong

A verifier that cannot describe how it recalls its own findings is asking to be trusted rather than checked. This is the protocol that runs when a methodology flaw or benchmark scoring error is found on our side. It is operational, not aspirational: the clocks are automated and the business-hours limits are real.

Last updated 13 September 2026 · Protocol v9.3

  1. Automated status hold — within 4 hours

    The platform API toggles every affected notary record to REVIEW REQUIRED via an automated kill-switch. Anyone who checks a held manifest at /verify sees the hold immediately. This step needs no human on a weekend; that is why it is automated and why the earlier “4-hour manual root-cause analysis” promise was withdrawn (audit finding #41).

  2. Customer written notification — within 24 business hours

    Formal notice to the client CDAO or VP Data: what was found, which bundles are affected, what the hold means for any decision taken on them, and what happens next.

  3. Re-evaluation and root-cause analysis — within 5 business days

    The test battery is re-run at zero charge. A formal RCA and an updated, re-signed audit bundle are delivered. The new bundle references the recalled one; the recalled one is never edited or deleted.

What triggers a recall

What does not trigger a recall

Reporting a suspected flaw

Customers, reviewers and third parties can report a suspected method flaw to [email protected]. We acknowledge within 2 business days. If a report from outside EvalQA leads to a recall, we credit the reporter in the RCA if they wish.

Where holds are visible

Only in the notary and in the customer’s own notification. We do not publish a list of held manifests, because a held manifest is customer-identifying to anyone who already holds the bundle and meaningless to anyone who does not.

Check a manifest → Independence Charter