You see a little badge next to someone's name — a checkmark, a "verified" pill, a green dot — and your brain quietly files them under real. We do it dozens of times a day without thinking. But here's a question worth sitting with for a second: when a system shows you that badge, what exactly is it telling you, and how does it know?

Most of the time the honest answer is: it doesn't really know — it's repeating something a company decided. A platform badge usually means "we, the platform, chose to vouch for this account." That can be fine. But it's a very different thing from "here is a piece of evidence you can check yourself." The first asks you to trust the platform. The second hands you the proof.

NAOMS is built around the second kind. So it's worth getting clear, from first principles, on what a verifiable claim actually is — because once you can see the parts, you can never quite un-see the difference between a badge that's backed by math and a badge that's backed by a logo.

Three things we mush together

When we talk about "verification", we're usually blending three separate ideas. Pulling them apart is most of the work.

1. The claim. A claim is just a statement someone makes about themselves: "this email address is mine", "I control the GitHub account @mujo", "I'm over 18". On its own, a claim is only words. Anyone can say anything. A claim is not evidence — it's the thing that needs evidence.

2. The proof. A proof is the checkable evidence that backs a claim. Crucially, a good proof is something you (or your software) can verify without taking anyone's word for it. "I own @mujo on GitHub" becomes verifiable when there's a way to confirm it that doesn't route through trusting me: for example, the account posts a specific value that only its real owner could have placed there, and anyone can go look.

3. Trust in the checker. Even with a claim and a proof, someone has to do the checking and report the result. A badge is really a checker saying "I looked, and the proof held up" — and its value depends entirely on whether the check was real.

A lot of online "verification" quietly collapses all three into step 3 — "trust us, we checked" — and never shows you the proof. The interesting design question is how much of the work you can push down into step 2, where you can confirm it, so you have to trust the checker as little as possible.

What makes a claim verifiable (and not just asserted)

A claim is verifiable when there's a concrete, repeatable procedure that connects the claim to evidence anyone can re-run. Three properties tend to show up in every good example.

It points at something only the real owner could produce. Proving control of an email means receiving a one-time value sent to that address — you can only show it if you can actually read that inbox. Proving control of a GitHub account means placing a specific token in a place only the account owner can write to. The proof leans on a capability the impostor doesn't have.

The check is re-runnable by anyone, not just the issuer. This is the line between "verifiable" and "vouched-for." If the only way to confirm the claim is to ask the company that issued the badge, you haven't verified anything — you've relocated your trust. A genuinely verifiable claim leaves behind evidence a third party can inspect independently.

Failure is visible, not silent. A good verification can come back false. If a check can only ever say "yes" — if it never meaningfully fails — it isn't checking anything. The possibility of a red answer is what makes a green one mean something.

A concrete shape: proving you control an account

Here's the pattern in its most common form, and the one NAOMS spent real effort on.

Say you want to prove you control a public account — a GitHub profile, a Mastodon account, a domain you own. The procedure looks like this:

1. The system gives you a unique value to publish — a small, unpredictable string tied to your identity.
2. You place that value somewhere only the account's real owner can write: a GitHub gist, a Mastodon bio, a DNS TXT record on your domain, a Bluesky post.
3. Anyone can now fetch that public location and check that the expected value is there.
4. If it matches, the claim "I control this account" is backed by a proof anyone can re-run by simply looking — no trusting the platform, no trusting NAOMS.

That last point is the whole game. The proof lives out in the open, at a location only the true owner could have written to. The checker isn't asking you to believe it; it's pointing at evidence you can confirm with your own eyes.

In NAOMS this family of checks is called greencheck, and over the project's verification work it grew to cover quite a range of these "prove you control a public thing" patterns — GitHub gists, GitLab snippets, DNS TXT records, Bluesky's AT Protocol, Mastodon and the wider Fediverse, and more — eventually around eighteen verification types built up over several rounds of work.

A note on timing: this is a concept piece, and the greencheck expansion it gestures at actually landed slightly later — the bulk of those verification methods came together in early April 2026. The idea of a verifiable claim is timeless; the shipped feature set is dated to early April 2026, and you should read it as "as of April 2026." There are no private records retained for this week, so nothing here is a quoted feeling or private moment — it's an explainer grounded in the public history of the work.

Why "trust the math, not the badge" is more than a slogan

The deeper reason to care about this distinction is that the two kinds of badge fail in completely different ways.

A vouched-for badge fails when the voucher is wrong, compromised, bought, or simply changes its mind. You have no independent recourse, because you never had the evidence — only the claim that evidence existed.

A verifiable badge fails loudly and locally. If the proof stops matching — the gist is deleted, the DNS record changes, the post comes down — the check goes red, and you can see why, because the evidence was always public. You were never asked to trust a logo. You were handed a procedure.

This connects to something NAOMS treats as foundational (its Honesty axiom): a system shouldn't quietly assert things it can't back. A green checkmark that's really just "we decided to trust this" is a small dishonesty. A green checkmark that means "here is the public proof, go look" is the system keeping its word.

Fellow travelers

This way of thinking — the proof should be checkable by anyone, the issuer shouldn't be a required middleman — is not ours alone, and it's worth honoring the people who pushed it.

• KERI takes the idea to its logical end for identity itself: instead of a registry vouching for who you are, your identifier is self-certifying and your key history lives in an append-only, hash-chained log anyone can audit. Its standout idea, pre-rotation — committing at birth to the hash of your next key, so a stolen key can't be used to seize the identity — is a beautiful example of "the math makes the guarantee, not the authority." What we took: the instinct that verification should rest on evidence a third party can re-check, not on a trusted issuer. What we did differently (and why): NAOMS's greencheck is deliberately humbler in scope — it verifies claims about external accounts you already have (your GitHub, your domain) rather than replacing the whole identity-and-key-rotation stack. That's a fit-to-context choice: we wanted "prove you own this handle" to be something a newcomer can understand in one sitting, not a new identity protocol to learn.

The point isn't that one approach wins. It's that a whole community of people independently arrived at the same north star: don't make me trust you when you could just show me.

The one sentence to remember

A claim is something you say; a proof is evidence anyone can re-check; a verifiable claim is one where the proof — not a company's say-so — is what turns the badge green.

Next time you see a checkmark, you can ask the only question that matters: can I see the proof, or am I just being asked to trust the checker?

Written by AI agents from real project logs; owned and edited by Mujo.