Don't trust my freshness. Check me.
A claimset is a small JSON file that says, for every load-bearing fact you published: this exact sentence appeared at this exact URL on this date, and after this date do not assume it still does. A verifier re-fetches the source and tells you whether that is still true.
Content that goes stale does not break. That is the whole difficulty.
A link checker tells you a URL still resolves. It does not tell you that the page behind it now says 60 days where it used to say four months — the link is fine, the citation is fine, and your published guide is now wrong. Nothing on the internet checks whether a cited source still says the thing.
Every freshness signal in common use is self-attested: a badge, a date the CMS wrote, a summary the publisher wrote about their own site. A self-attested claim is a request for trust, not a piece of information. The measured fate of the best-known one is instructive — 97% of published files never received a single request.
claimset is the opposite move. It publishes the falsifiable version: here is my sentence, here is the URL I took it from, here is the date I checked, here is the date I stop vouching for it. Go and check. If I am wrong, the tool that catches me is the one I shipped.
{
"claimset": "1",
"publisher": "Example Shop",
"contact": "https://example.com/corrections",
"claims": [
{
"claim_id": "refund-window-30-days",
"assertion": "You must request a refund within 30 days of delivery.",
"source_url": "https://example.com/refunds",
"checked_on": "2026-08-15",
"expires_on": "2027-02-15"
}
]
}Conventionally claims.json, committed next to the content it backs. Five required fields per claim. Unknown fields are rejected rather than ignored, so a typo cannot silently disable a check. Full spec →
$ claimset verify demo.claims.json --today 2026-08-15
claimset 0.1.0: demo.claims.json (4 claims, as of 2026-08-15)
PASS support-reply-two-days source still says it
DRIFT refund-window-60-days the source matches the first 62% of this assertion, then diverges
you claim : "you must request a refund within 60 days of delivery."
page says : "you must request a refund within 30 days of delivery. support replies within 2 business days."
EXPIRED old-refund-window expired on 2026-01-10; re-verify and re-date it
WEAK shipping-is-free 2 significant word(s), 0 number(s); need 4+ significant words, or a number plus 2+ significant words
PASS 1 DRIFT 1 EXPIRED 1 WEAK 1
FAIL: 3 claim(s) need attention. Fix the page, fix the claim, or re-verify and re-date it.
$ echo $?
1Real output from the reference verifier against a local fixture page, no network involved. Note the first line: the claim says two business days, the page says 2 business days, and that is a PASS — written numbers are normalised on both sides, because false alarms are how a checker dies. Note the last: free shipping is refused as too vague to falsify before anything is fetched, because a green result that matched by luck is worse than no result.
This site publishes its own claimset at /claims.json. Every source in it is a page this site serves, so you can verify the whole register against this origin without depending on anyone else:
curl -O https://claimset.org/claims.json
claimset verify claims.jsonIf one of those claims has drifted, the verifier will say so, and this page will be wrong in public. That is the design.
The format and the reference verifier are free, MIT licensed, and stay that way. They are the whole product today.
Planned: hosted re-verification on a schedule, and signed freshness attestations for publishers who want a third party to hold the receipts. Nothing to sign up for yet, and nothing about it changes the format — a file that verifies locally will always verify locally.