Snyk for beliefs · Continuous verification for AI claims

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

Claims decay — versions go EOL, CVEs publish, APIs change. Reverify continuously re-verifies your systems’ claims against ground truth and attaches signed, evidence-cited challenges when the world moves on.

clm_8f2k…supportedchecked against OSV · 14:02:11
Scroll
01 The problem

Claims decay.

A claim is a statement your system depends on: X is true now. It is temporal — it rots by design. Keep scrolling and watch one go bad.

clm_8f2k · dependency_clean · volatilesupportedcontradicted

{ "subject": "lodash@4.17.21", "claim": "no known vulnerabilities" }

cadence: every 6hchecker: osvbudget: 500ms
The world moved — CVE published to OSV. Ground truth no longer supports this claim.
chl_51dz · challenge attacheded25519:3j9F…kQ==
“lodash 4.17.21 — vulnerability identified in OSV database.”
source: osv.dev · source_tier: 1 · retrieved_at: 14:07:52 · delivered to your webhook
02 Why claims rot

The world moves. Silently.

/01

Versions go EOL

The runtime you pinned reaches end-of-life and stops receiving patches. Nothing alerts you — the claim just quietly turns false.

/02

CVEs publish

A dependency that was clean at deploy time appears in the OSV database overnight. Your system keeps trusting it until someone checks.

/03

APIs change

Library semantics drift between versions. What the docs said last quarter is not what the docs say now — and your output still cites the old truth.

03 The system

Submit. Watch. Challenge.

Two endpoints, one rule: attach, never mutate. Your claims stay immutable — the evidence accumulates around them.

01

Submit claims

POST the statements your output depends on. Batch up to 100 — verdicts return inline within a 500ms budget, idempotent by design.

# claim the truth your system relies on POST /v1/claims { "type": "dependency_clean", "subject": "lodash@4.17.21", "decay": "volatile" } → 201 { "claim_id": "clm_8f2k…", "verdict": "supported" }
02

We keep checking

Six checkers route every claim to ground truth — OSV, endoflife.date, wp.org, library docs. Volatile claims every 6 hours, versioned daily, stable once.

# decay classes set the cadence volatile → re-verify every 6h versioned → re-verify every 24h stable → verify once
03

Challenges, not silent rot

When ground truth moves, an Ed25519-signed challenge attaches to the claim — quoted evidence, source tier, retrieved-at — pushed to your webhook.

# signed, evidence-cited, delivered { "id": "chl_51dz…", "verdict": "contradicted", "quote": "vulnerability identified…", "signature": "ed25519:3j9F…" }
04 Ground truth

Verified against ground truth,
not other models.

Six checkers live in production. Each one watches a different slice of the world.

01 / 06

osv

osv.dev

Watches the open-source vulnerability database. The moment a CVE touches your dependency, the claim is challenged.

dependency_clean
02 / 06

wpvulnerability

WPVulnerability DB

Tracks disclosed vulnerabilities across the WordPress plugin and theme ecosystem.

plugin_version
03 / 06

endoflife

endoflife.date

Follows end-of-life schedules for runtimes, frameworks and databases — flags the version that quietly stopped being supported.

version_requirement
04 / 06

wporg

WordPress.org

Reads the plugin directory itself: latest versions, tested-up-to, status changes and closures.

plugin_status · tested_up_to
05 / 06

context7

Library docs

Reads current library documentation to check that claimed semantics still match what the docs actually say.

library_semantics
06 / 06

adversarial

Model review

Briefs a model to argue the strongest good-faith counter-argument. It never declares claims incorrect — it labels them Contested.

judgment · contested
supportedcontradictednot-coveredpendingAbsence of evidence is not-covered, never contradicted.
05 In production
6
Checkers live in production
6h
Volatile claim cadence
500ms
Inline verdict budget
100
Claims per batch
60/min
Rate limit per key
24h
Challenge redelivery window
06 Open core

The closed service proposes.
The open checker disposes.

Witnesses are signed witness/v1 packets — artifact-bound by sha256, verifiable by anyone with the open-source @reverify/checker. No trust in us required.

R1Attach, never mutate.
R2Unsigned witnesses are invalid, full stop.
R3Every challenge carries quoted evidence.
R4Inspectability is the product.
wit_51dz… — reverify/witness/v1
{
  "type": "reverify/witness/v1",
  "id": "wit_51dz…",
  "claim_id": "clm_8f2k…",
  "artifact_sha256": "9c2f…",
  "checks": ["signature", "artifact-hash",
    "schema", "taint-path", "version-range"],
  "verdict": "valid-structural",
  "signature": "ed25519:3j9F…kQ=="
}
$ npx @reverify/checker verify --witness wit.json --artifact plugin.zip
✓ valid-structural — verified independently
07 Tenant #1

Powering Living Audits at WP HealthKit.

WP HealthKit grades WordPress plugins & themes. Every grade is a bundle of claims about the world — this version is clean, this plugin is maintained, this runtime is supported — and claims rot.

So their audits don’t go stale. Reverify re-verifies every claim behind every grade, and when the world moves, a signed challenge lands and the audit updates itself. Evidence attached, never mutated.

WP HealthKit — first tenant, live in production
tenant: wphk · claims streamLive
Illustrated stream — the shape of the live feed
08 Early access

Be tenant #2.

Reverify is live in production at api.reverify.co.uk, dogfooding with its first tenant. Join the list for tenant #2 and beyond.

Magic link — no passwordrvf_live_… keysFree tier for OSS planned