You were never shown proof.
You were shown a report.
Ranex is the judge outside the loop. It reads the diff on disk, runs checks the AI can't rewrite, and blocks any claim with no evidence.
Open-source kernel · MIT license · v0.1.0 released 2026-09-03
▶ This loop plays automatically — that's the loop, condensed. The agent's cheerful report is thrown away; the verdict comes from checks.
Reports come from the worker. Verdicts come from a judge.
The bullseye gets painted after the dart lands.
Your agent said done. It wrote the tests, the tests passed, you merged. Nobody lied — the agent that wrote the code also wrote the test that graded it, so of course it passed. The target wasn’t there before the throw. It was drawn around wherever the dart landed, and called a bullseye. A better model just paints a straighter circle around the same dart. Watch the difference:
How today's tools score
Self-scoredThe test was written after the code, by the same AI that wrote the code. It always passes — because the target is painted wherever the dart happens to land.
How Ranex scores
Frozen targetThe target is drawn and frozen before the throw, and a miss is recorded honestly — that verdict path runs today. Escalating to you after three misses is the intended design, not built yet.
“All tests pass,” from an AI, means the AI checked its own work. Ranex doesn’t try to make the thrower better — plenty of tools compete on that. It fixes the scoring: target locked first, no self-grading, every point comes with a receipt. Read the full breakdown of painting the bullseye.
Why “all tests passed” is not evidence.
The short explains the problem rather than demonstrating it: why a green report tells you nothing about the work when the actor that did the work is the actor that graded it. Reports come from the worker. Verdicts come from a judge. If you want the demonstration instead of the explanation, run it yourself. Ranex v0.1.0 is source-run — clone it and run.
Only the thumbnail loads before you press play. Watch on YouTube
A judge outside the loop.
Reports come from the worker. Verdicts come from a judge. The judge is ordinary code — no model, no vote, no confidence score. It reads what actually changed on disk, runs tests frozen before the work began, and says pass or fail. Follow the pulse: your idea becomes an approved map, the map becomes a locked target, the AI builds, and the kernel — code, not a model — delivers the verdict.
● The pulse is one attempt travelling the loop — a miss loops back, a pass is merged by the kernel, never by the AI. Take every model credential off the machine and not one verdict changes.
This is the intended governed loop. What ships today is the verdict path — tests freeze, the AI builds, the kernel checks and merges on pass. The map you approve and the three-miss escalation are designed, not built.
Tests freeze before you build
The map becomes tests before any code is written. Any diff that touches a test file fails the gate instantly — the AI that builds can never edit what judges it.
Red, then green — enforced
Every test must fail against the code that doesn't exist yet. A test that already passes before the fix is not a target — it's a circle painted around a dart.
Every behavior needs a receipt, not a percentage
Not "80% of lines covered." Every behavior in the map you approved needs at least one passing test, tied to the exact code it describes, or the build does not clear.
No self-approval
Whoever produced the evidence cannot approve it. One honest limit, stated plainly: approver identity isn't authenticated yet — `--approver` is a plain string, so this check compares names, not verified identities.
I’ve spent 17 years watching systems fail.
Most of that time was spent on the unglamorous end — platform support, incident work, four years at Pantheon on sites where downtime was measured in money. You learn a specific lesson doing that.
The dangerous failure isn’t the loud one. It’s the green light that proves nothing. A check that never ran. A test that was skipped. A report nobody verified.
AI coding agents made that failure cheap to produce at scale. So I build tools that prove things instead of claiming them — Ranex is one of them.
Anthony Garces
Senior Principal Lead Architect · Founder, Anito
- in software
- 17 yrs
- lead architect
- Principal
- 4 years, platform WebOps
- Pantheon
Ranex is v0.1.0, and its README states its limits before it says anything else. I’d rather you evaluate the real thing.
Same problem, different corners of it.
Ranex judges whether work was actually done. These take the same question earlier and later in the chain. All are open source, all are early, and each says where it stands.
Ranex v0.1.0 is out. Here’s what you can check yourself.
Ranex gates Ranex. The kernel runs this repository’s own suite — provisioned, sealed, offline — against a materialisation of the real current commit. Not a demo suite. The one guarding this codebase.
No invented case studies, no client logos, no metric that isn’t in the repository’s own README.
The ideas that shaped this thing.
Ranex came out of specific failures — checks that didn’t run, tests that vanished, green lights that proved nothing. I write those down as I hit them.
Read from the repo, not written for you.
Ranex ships in slices — closed only when the criteria are proven. This list comes straight from the kernel’s own record, so it can’t drift from what landed.
Full changelog- Github webhook receiver v1
SLICE-084the repo's first long-running listener, bounded on purpose — stdlib `http.server` on localhost (TLS is the terminator's job), one endpoint, one delivery at a time, 1 MiB body cap; every delivery proves its `X-Hub-Signature-256` HMAC (GitHub's own published test vector pinned) before a byte is parsed, replays are no-ops, allowlist and closed event grammar journal what they decline; pipeline = fetch → bind → resolve → publish, fetch failure answers 5xx for redelivery; README carries the App creation and ruleset recipes (`ranex/acceptance` pinned to the Ranex App via `integration_id`); kernel unmoved, sealed green at 1795/166
- Github check publisher v1
SLICE-083the `ranex/acceptance` check, published by the Ranex GitHub App on the exact PR head — RS256 JWT on the pinned `cryptography` primitive (minted only; GitHub verifies), installation tokens exchanged and cached, stdlib transport, no new dependency; the conclusion mapping is fail-closed (`success` only from a VERIFIED+PASS record; FAIL → `failure`; absent → `action_required`; rejected → `failure` naming the reader state; API error → `E-GITHUB-API-REFUSED`, one POST, no silent retry), and the arms grep every emitted line for the key, token and webhook secret. `github check publish` one-shot; kernel unmoved, sealed green at 1774/166
- Pr head binding v1
SLICE-082a pull-request head SHA, resolved through the local git object store, derives the exact subject every signed verdict already names — the same tree digest, byte for byte — or refuses (`E-GITHUB-BAD-SHA` / `E-GITHUB-UNFETCHABLE-HEAD` / `E-GITHUB-HEAD-MOVED`); `resolve_acceptance` maps every verdict-reader state to a closed outward outcome where only `VERIFIED` is publishable, absence is named as absence, and every rejection names its state. First slice of the GitHub acceptance loop (`github bind`, pure derivation, no network); kernel unmoved, sealed green at 1754/166
Software you can verify without reading a line of code.
Vision
Anyone can commission working software — and know exactly what was proven about it, not just promised.
AI has given far more people the power to build than ever before. It hasn't given them the power to verify. Until it does, every non-technical builder is one confident "all tests pass!" away from shipping something broken to real customers. I think the verification gap — not the building gap — is the thing actually holding this work back.
Mission
Make "done" mean something: every claim carries evidence, every miss is visible, every hit is provable.
I build the honest scoreboard for AI-built software, with targets locked before the work starts, no self-grading ever, and verdicts delivered by open-source code anyone can inspect. Misses become visible and cheap. Hits become provable. That's the whole job, and I refuse to claim more.
What Ranex doesn't say
It does not improve aim. Not by one degree. It doesn't write better code — it makes a miss visible and cheap, and a hit provable.
"Conformant to an approved specification" is real. "Correct" is not a claim anybody can make. A passing build proves every behavior in the graph you approved has a test, and every test passed, pinned to this exact code. It says nothing about whether the graph was right.
It says nothing about what's off the graph. Unspecified behavior is unconstrained. Performance, accessibility, security — not covered unless you add gates for them.
When a tool promises you both a better thrower and an honest scoreboard, ask which one it actually measured.
Frequently asked questions.
Still have a question? Ask me directly
Take the credentials off the machine. Watch the verdict not change.
That’s the whole test — watch it block on the kernel’s own suite, then run it on whatever you’re using today — not just Ranex. The field notes cover how the kernel decides pass or fail, case by case, as it’s built in the open. No cadence promises, no filler.