← blog

31 July 2026 · Reverify team · story · living-audits · wphk

Claims decay: why we built Reverify

Your AI was right when it said it. Is it still right?

That question is the entire company. When a system says "PHP 7.4 is a supported runtime" or "this dependency is clean" or "this plugin is tested up to WordPress 6.9", it's making a claim — a statement about the world, true at the moment it was said. And the world keeps moving. Versions reach end-of-life. CVEs publish overnight. APIs drift. Nothing tells you. The claim just quietly turns false, and your system keeps acting on it.

We built Reverify because we own a system that makes thousands of these claims a day — and we watched one of them rot in production.

The problem nobody alerts you about

WP HealthKit grades WordPress plugins. Every grade is a bundle of claims: this version has no known vulnerabilities, this plugin is maintained, this runtime is supported, this API works the way the docs say. A report is generated once, displayed for months, and trusted the whole time. But the underlying facts have shelf lives measured in hours for some classes (vulnerability feeds) and weeks for others (versions, compatibility).

Every monitoring tool checks whether things are up. Nothing checked whether what we believed was still true.

So we built the thing we wanted: submit the claims your output depends on, and let something keep checking them against ground truth — deterministic sources, not other models. When a claim decays, you don't get a silent wrong answer. You get a challenge: signed, quoting the evidence, delivered to your webhook. The original claim is never edited. Attach, never mutate.

Week one, the data argued for us

Within days of going live with our first tenant (ourselves — dogfood or it didn't happen), the system started catching real decay:

And one we didn't see coming: our own production Dockerfile was running node:20 — which went EOL in April. The first claim class Reverify verifies caught a bug in our own infrastructure. There's a lesson in that and we choose to find it flattering.

The rules that make it trustworthy

A verification service you can't trust is worse than nothing — it manufactures confidence. Four rules keep it honest:

  1. Attach, never mutate. Challenges are additive evidence. The original claim and its history stay intact; the world changed, and you can see exactly when and why.
  2. Absence is never contradiction. If the ground-truth source doesn't cover a claim, the verdict is not-covered. A verifier that cries wolf spends its credibility fast — so it doesn't get to.
  3. Every challenge carries quoted evidence. Not "we disagree" — the actual passage, the source, and when it was retrieved. Verifiable by you, not just us.
  4. Measured confidence, labelled honestly. Deterministic checkers produce verified verdicts. Model-assisted review produces verbalised ones, marked as opinion. They render differently. They should.

What "continuous" actually means

Claims carry a decay class. Volatile claims (vulnerability-adjacent) recheck every 6 hours. Versioned claims daily. Stable claims once. The worker drains what's due, checkers route to ground truth — OSV, endoflife.date, WordPress.org, WPVulnerability, Context7 docs — and the registry compounds. Resubmit an identical claim and you get the same record back with its history, not a duplicate.

The result is that a WP HealthKit audit is no longer a snapshot. It's a living document whose beliefs are watched. We call that Living Audits, and it's why Reverify exists at all.

The trust endgame

One more thing, because it matters more than everything above: you shouldn't have to trust us either. Every proof artifact Reverify produces is a signed witness — bound to the artifact's sha256, verifiable offline by anyone with the open-source checker. The closed service proposes; the open checker disposes.

Your AI was right when it said it. Now you can prove whether it still is — without asking us.


Reverify is live in production with WP HealthKit as tenant #1. API docs · Changelog · Join the waitlist for tenant #2.


More from the blog · API docs · Status