A claim with no test that could disprove it is marketing, not engineering.
That is the whole rule, and it is older than us. Karl Popper drew the line in 1934 (Class E): a statement only counts as scientific if there is some observation that, if it occurred, would force you to give the statement up. Anything else is a story you tell about the world, not a description of it. We borrowed the rule for the agency because, after watching enough vendors sell unfalsifiable promises, we got tired of being one of the people listening.
So here is how we apply it. Every non-trivial claim on this site has an evidence class beside it (A, B, C, E, F, or U), and where the claim is about something we built or run, it also has a published falsifier — a specific observation that, if it occurred, would force us to retract. The falsifier lives in the same place the claim does. You should not have to ask us for it.
Three current examples.
Claim one: the receipts page on our site is generated from the same data the work itself produced. (Class C) The falsifier is straightforward — if the dashboard at our receipts endpoint shows numbers that do not match the upstream logs, or shows numbers when the upstream collector is down, the claim is wrong and we owe a correction. The plumbing is described in /six-receipts; the underlying posture is in the /trust-receipts-standard.
Claim two: a lead submitted through the workshop form reaches a human within one business day. (Class C) The falsifier is the obvious one — if you submit a lead and no human replies, the claim is wrong. We log timestamps on both sides of the pipeline so the gap is auditable. That is also why the intake path is one of the things listed on /standard/what-we-do-not-claim: we do not claim a response time we cannot evidence.
Claim three: we will tell you what we are not sure about. (Class C) The falsifier here is meta but real — if a SolutionWright post on this site makes a strong claim with no evidence class, no source link, and no failure mode, that post violates our own standard and should be flagged. We have given readers a place to do that, and we treat the corrections as we would treat any production bug.
What the falsifier rule rules out is the language pattern most prevalent in this industry right now: the unfalsifiable superlative. "Most advanced." "Truly intelligent." "Indistinguishable from human." None of those sentences name a test that could fail. None of them, then, are engineering claims. We do not write them about our own work, and we are wary of partners who write them about theirs.
Dr. Alianna J. Maren has been writing in a related direction from a different angle. Her tummy-churning piece argues, in our one-line frame, that the field is pouring enormous capital into one architectural bet while neglecting the human verification step that would catch the resulting errors. (Class E) We read it as adjacent to our posture: if a vendor's output cannot be checked by a human against a falsifier, the output is a bet dressed as a fact, and bets do not belong in a delivery pipeline.
The blessed line, for anyone who has not seen it yet, is this: UNI is a working hypothesis on an attainable path toward General Natural Intelligence — a natural, active-inference approach whose evidence is growing, evidence-classed, and tested in the open. Don't take the claim on faith; test the build, inspect the gates, and help us find where it fails. That sentence is engineered the same way every other claim on this site is. The phrase "evidence-classed" is the falsifier hook. The phrase "tested in the open" is the receipt.
If you want to see this applied to a project of your own, the place to start is the /workshop. Bring a real outcome you are trying to verify and we will write the falsifier with you, on the same page as the claim, before any work begins.
- /workshop — bring a claim, leave with a test.
- /six-receipts — what we publish about our own work.
- /trust-receipts-standard — the posture in full.
- /standard/what-we-do-not-claim — the things we will not say.