We published a claim that says our file search is broken

Today quox.ai/facts started carrying something most companies would bury: a public claim about our own product that says it does not work everywhere yet.

The claim is about file search. It reads VERIFIED on our dev install, and it reads REVIEW on a fresh clean virtual machine, with a plain-language reason attached: file search passes on our dev install but is not yet proven on fresh clean-VM installs, where it currently fails. We did not soften it. We published it because it is true.

Why a limitation gets published at all

The usual pattern is simple. A feature works in the demo, so the website says it works. The gap between "works in the demo" and "works on your machine" is left for the customer to discover.

We decided that gap is exactly the thing worth being honest about.

So the status on each claim is not written by a person who wants it to look good.

It is computed from the proof engine's own run records: a claim only reads VERIFIED when the matrix shows it passing, on its current checks, on more than one day, on the instance class the claim covers. file search passes that bar on dev. On a clean VM it does not, so the claim cannot say VERIFIED there, and it does not.

The part that cannot be gamed

There is a rule underneath this that we care about more than any single claim. If a claim has an open finding that materially bears on whether it is true, it is not allowed to read VERIFIED, full stop. The finding forces the status down and prints the reason in public.

That is what you are seeing on the file search claim. The clean-VM failure is an open material finding, so the integrity gate holds the claim at REVIEW. No one can mark it VERIFIED while that finding is open, not by editing a file, not by wanting it badly enough. The machine refuses.

This is the opposite of a trust-me badge. You do not have to trust the status. You can recompute it from the evidence we ship next to it.

Three claims, three honest shapes

The first three computed claims are deliberately different shapes, because honesty is not only about success:

• One is a straightforward success: the check that watches our own evidence chain is itself proven, on our dev box and on throwaway clean VMs across several days.
• One is a success with a scar: a vault health check that failed on the matrix, got fixed, and now passes. The record of it being red is kept, not erased. You can see it was broken and see when it was repaired.
• One is a live limitation: file search, VERIFIED on dev, REVIEW on clean VMs, with the gap stated.

A registry that only ever shows green is a brochure. A registry that shows a scar and an open gap is evidence.

How to check it yourself

Everything above is on one page. Read the human version at quox.ai/facts, or fetch the machine version at quox.ai/facts.json and read the computed status and reason for each claim. The witness receipt at quox.ai/facts.receipt.json lets you confirm the page has not been quietly edited since it was signed.

This is what we mean by a trust layer. You do not take our word for what the product does. You check, and the awkward parts are in the checkable set on purpose.

If you want the longer argument for building this way, it is on our verifiable AI operations page.