Christopher Betances — founder of verification-first recursive self-improvement

Author: Christopher Betances
Status: Independent research
Hardware: One laptop, 8 GB GPU
Publications: 135
Christopher Betances · solo, self-funded, one laptop

I build AI systems that falsify their own claims, keep a permanent record of every failure, and carry that record forward. The system runs on a laptop with an 8 GB consumer GPU. It has no funding, no team, and no cloud compute.

The argument below is short, and every number in it is published with the command that produces it.

I. The bottleneck is not capability

A self-improving system improves only as fast as it can tell a real improvement from a convincing one. If it cannot kill its own bad claims, then more intelligence, more compute and more data all feed the same loop: generate, believe, repeat. The failure does not get recorded, so the system re-proposes the same broken claim next cycle, at full confidence, because nothing remembers that it already failed.

The binding constraint is therefore not how smart the generator is. It is the fidelity of the verifier that the loop is closed on. A loop closed on a weak verifier converges on whatever that verifier likes — which, optimised against hard enough, is nonsense.

$r^{*} > p_{gen}$ The loop improves only while the verifier's precision exceeds the generator's power to fool it. Where this inverts, self-improvement becomes self-confirmation — and the system cannot tell the difference from the inside.

This is the measurable form of a claim usually made as philosophy. It replaces "is the system improving?" — unanswerable without ground truth — with "how often does the system's own verdict change when its measurement gets harder to game?" That question has an answer. Mine is below.

II. What I built, and what it survived

16,217verdicts recorded
7,864measured claims
4,627of those refuted
99.9%carry a kill condition

Every verdict in that ledger records four things: the claim, the measurement that would refute it, the value actually measured, and the outcome. 99.9% of the rows carry their refutation threshold — the condition that would have killed the claim, registered before the answer was known. That is the rare part; most published research reports outcomes without it.

The counts above are the honest ones, not the flattering ones. Of the 16,217 rows, half are templates auto-registered from a document and never measured. The 7,864 that were actually measured are the substance, and 59% of those were refuted — refutations outnumber confirmations by 1.47×. An operator that chooses what to test, and kills most of what it tests, is doing work rather than confirming itself.

III. The finding I did not expect

277 of the 324 checks were run more than once. Across those re-runs there were 79 verdict transitions — cases where a claim's verdict moved once the measurement was repeated or hardened. Split by direction:

DirectionEventsWhat it means
Hardening38A claim I had CONFIRMED turned out REFUTED once the check was made harder to game. The instrument caught the instrument.
Loosening38A claim I had REFUTED came back CONFIRMED. The instrument was wrong in the other direction.
Net0The ratchet does not drift.

I am reporting the zero because it is what the measurement says. A net-positive ratchet would be a number that flatters its owner, which is the exact failure mode this whole body of work exists to catch. A net-zero ratchet means the ledger is a live instrument with error in both directions, still being calibrated — not a record that only accumulates agreement with itself. The zero is the finding.

IV. What I am and am not claiming

Not claiming: that I invented recursive self-improvement, which predates this work by sixty years. Not claiming AGI, superintelligence, or unbounded improvement. Not claiming peer review, funding, adoption, or institutional affiliation. Not claiming the labels in my datasets are ground truth — they are produced by my own instruments, and every dataset card says so.

Claiming: that a verification-first loop can be built and run by one person on consumer hardware; that its failure record can be made pre-registered and permanent; and that the resulting instrument can be measured rather than asserted. The specific contribution is documented on the thesis page.

V. Check it

You do not have to take any of the above on trust. Every figure on this site is listed in the claims register with its artifact and the command that derives it, and the whole register re-verifies with one command:

python3 _forest/_inventory/verify_claims.py

Five claims are currently marked UNVERIFIED because their supporting data is not published. They are listed as open problems rather than quietly dropped. That is the standard the rest of this site is held to.

Boundary. This is the independent work of one person, published without peer review. The instruments are real and re-runnable; the claims are mine and are marked with their confidence. Where I could not verify something, the page says so.