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. Do not take the claim on faith. Test the build, inspect the gates, and help us find where it fails.
This post is the instruction manual for the last part of that sentence. If you think a UNI claim is wrong, overstated, or improperly evidenced, here is exactly how to file a challenge, what we do with it, and how the ledger records the outcome (win or lose for us).
What counts as a UNI claim
A "UNI claim" is any assertion we publish on /transparency, in a lab caption, in the preprint, in the Cell Lab benchmark table, or in a blog post, that is testable in principle. It has three parts: (a) the statement itself, (b) the evidence class we tag it with, and (c) the falsifier that would disprove it. If any of those three is missing, it is not yet a UNI claim, it is a work note, and the correct pushback is "publish the falsifier or retract it."
The taxonomy of evidence classes comes from active-inference practice around structured skepticism (Class E, see Parr, Pezzulo, Friston, 2022, MIT Press). We use: A empirical-in-session, B code or inspection, C configuration or integration, E expert citation, F falsifier present, U unverified. Every published claim carries at least one class letter and, where the class is F, a link to the falsifier text.
How to file a challenge
Send an email to Michael.Polzin@SolutionWright.com with the subject line "UNI Pushback:" followed by a short handle for the claim. In the body, include the following five fields. The template is copy-and-pasteable.
- The claim, verbatim. Quote the exact sentence or table row, with its URL and the date you saw it.
- The evidence class we assigned (A, B, C, E, F, or U), and whether you accept that class label.
- Your specific objection. One of: the class is wrong (we said B when it should be U), the falsifier is missing or not real, the citation does not say what we claim it says, the runtime behavior disagrees with the code path we cited, the reasoning does not follow, or the claim is out of scope for the evidence.
- The evidence you are bringing. Paper, log, screenshot, replication of a lab episode, alternative citation, anything checkable.
- What outcome would satisfy you. Retract, downgrade the class (for example from B to U), rewrite with a narrower scope, publish a public correction, or open a falsification run.
You do not need credentials. A high-school student who read the Precision Lab caption and can point to a mismatch between our stated behavior and what the lab actually does has filed a legitimate challenge (Class C configuration or integration).
What we do with it
Every challenge is assigned a Pushback ID within one business day and added to the public ledger as an OPEN item. The ledger row records: the challenge ID, the claim under dispute, the submitter (anonymized on request), the date, and the initial evidence class dispute. From there the process has four possible endings, and all four end in a written entry.
- Concede. We agree the challenge is right. We retract or rewrite the claim, mark the ledger row RESOLVED-CONCEDED, and cite the challenger. This has happened before, and the ledger keeps every instance.
- Downgrade. The claim survives but at a weaker evidence class. For example, a claim we tagged (Class B) becomes (Class U) until the runtime observation is done. The public page is updated in place, and the ledger row is marked RESOLVED-DOWNGRADED with the reasoning.
- Defend with new evidence. The claim stands, and we publish the additional evidence the challenge asked for (a new lab run, a code path walk-through, a fresh citation). Ledger row: RESOLVED-DEFENDED, with the added evidence linked.
- Unresolved, held open. We cannot yet concede or defend. The challenge stays OPEN, the disputed claim gets an inline "under active challenge" banner, and we commit a target date for adjudication. This is the honest outcome for hard, expensive-to-test claims, and it is preferred over premature closure.
What we do not do: reject a challenge for tone, credentials, or affiliation. The math of active inference (Class E) is indifferent to whether a signal came from a friendly or hostile source. A rude challenger with a real falsifier is worth more than a polite one without.
How the ledger records adjudicated pushback
The ledger is append-only, and every state transition is a new row rather than an edit. A single challenge therefore leaves a trail: OPEN, then IN-ADJUDICATION, then one of the four resolutions above. The row schema is documented in how we log honesty in the UNI ledger, and the write path is inspected as a Class C configuration or integration artifact.
Two properties matter. One, we cannot silently disappear a losing entry: the CONCEDED and DOWNGRADED states are the highest-signal rows we publish, and we surface them on the transparency page. Two, an OPEN row with no adjudication date is itself a public embarrassment, which is the pressure that keeps the queue moving.
What is out of scope
Challenges that are not really about a UNI claim (personal disagreements, requests to endorse or attack a third party, demands to change vocabulary for reasons unrelated to accuracy) get logged as "not a claim challenge" and closed with a short note. If you are unsure whether your objection qualifies, send it anyway. We would rather triage a borderline case than miss a real one.