Now you can verify our facts, not just read them

We've published machine-readable facts about Quox at quox.ai/facts.json for a while now: platform counts, protocol status, each line carrying a source and an as-of date. The idea was simple. Instead of asking you to trust a marketing page, give you a file you could fetch, diff against our claims, and check for yourself.

That was step one. It still had a gap, though: nothing stopped the file from changing quietly between the moment we wrote a claim and the moment you checked it. You could read facts.json, but you couldn't prove that the copy in front of you was the one we actually stood behind.

Today we closed that gap. facts.json now has a witness receipt, published alongside it at facts.receipt.json.

What we built

The receipt is small and does three things. First, it carries the SHA-256 content hash of facts.json at the moment we published it, so you can tell if a single byte has changed. Second, that hash becomes an entry in an append-only WARD hash chain, the same witnessing model we use elsewhere in Quox for evidence bundles and run history.

Each new entry links back to the one before it, so the chain records a history, not just a snapshot. Third, the current tip of that chain is signed with an Ed25519 key we control, so the whole thing can be checked without calling home to us.

We didn't build this because a receipt was owed to anyone. We built it because we kept noticing the same pattern in our own drafts: we'd write "Quox does X" and then have no way to hand the reader anything better than our word.

Given that WARD already exists for exactly this kind of tamper-evident witnessing, wiring it up to our own facts page felt like the obvious next step, not a new feature. If we're going to ask people to build governed, evidence-producing agent systems, our own claims about our own product should be checkable the same way.

How you'd actually check it

The steps are plain enough to do by hand, and that's the point. Fetch facts.json and facts.receipt.json. Recompute the SHA-256 hash of the facts.json bytes you received and compare it to the hash recorded in the receipt. If they match, you have the exact file we witnessed.

Then look at the receipt's place in the WARD chain: each entry references the prior one, so you can confirm this entry sits where it claims to sit and hasn't been quietly inserted or reordered. Finally, verify the Ed25519 signature on the chain's current tip against our published public key. None of this requires a live connection to us at the moment of checking.

You can do it offline, on a plane, a year from now, and still get an answer.

We'd rather describe that process in plain prose than hide it behind a "trust our verified badge" button, because the whole exercise is pointless if verification itself requires trusting us.

What this doesn't do

We want to be honest about the shape of what a receipt actually proves, because it's narrower than it might sound. A receipt proves that the file you fetched is the file we witnessed, unchanged since. That's it. It does not prove that the claims written inside facts.json are true.

If a line in facts.json says a protocol is a certain status as of a certain date, the receipt only tells you that line hasn't been silently edited since we signed it. Whether the line was accurate when we wrote it, and whether it's still accurate now, is a separate question entirely, and it's one the receipt can't answer for us.

That burden stays where it belongs: on the sources and as-of dates inside facts.json itself. A witnessed false claim is still a false claim, just one you can prove we made on a specific day.

We think that's the right place to draw the line. Cryptographic integrity and factual accuracy are different problems, and conflating them is how a lot of "verified" claims end up meaning less than they sound like they mean. We're not claiming to have solved the second problem. We're just no longer asking you to take the first one on faith.

Why bother

Marketing pages assert. That's more or less their job description, and it's why people are right to read them sceptically. We'd rather you not have to extend us that kind of trust by default. If you want to know whether a claim about Quox changed since last week, you can check the chain instead of asking us and hoping we remember accurately.

If you're citing us somewhere and want to point to something firmer than a screenshot, you now have a file with a hash, a chain position, and a signature behind it.

This isn't a large feature. It's a small, quiet piece of infrastructure sitting under a page most people skim past. But it's the same instinct behind everything else we're building: don't ask people to believe you, give them something they can check. If you want the mechanics behind the chain itself, the write-up is at WARD.

If you just want to see the facts and check them yourself right now, they're at quox.ai/facts.json, and the same data is rendered as a readable page at quox.ai/facts for anyone (or any answer engine) that cites pages rather than fetching raw JSON.