Your AI says done.
Make it prove it.
The agent that wrote the code also wrote the success report. Ranex puts a judge outside that loop: checks bound to your commit, signed evidence, and a gate that blocks when proof is missing.
Open source · MIT licensed · Pre-release kernel
“All tests passed.”
Does not count as evidenceA required check has no evidence. Absence blocks.
Illustrative inputs. Inspect the recorded checks and receipts ↗
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-scoredA test written around the implementation can repeat its mistake. The run passes, but the original requirement still has not been checked.
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 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 delivers the verdict. The kernel is code, not a model.
● 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
No self-approval compares the producer and approver. Ordinary gate evaluate --approver uses an unauthenticated name; signed approver verification exists only in the task-merge approval path.
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 an early kernel with published limits and commands you can run yourself. I’d rather you evaluate the real thing.
Tools for work you can check.
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.
The kernel is available. 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.
Notes from building the judge.
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.
What changed in the kernel.
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- SLICE-086
SLICE-086Automatic signed-evidence evaluation](docs/slices/done/SLICE-086-automatic-evidence-evaluation.md): `github listen --evaluate-evidence` judges fresh evidence without executing PR code.
- Github webhook receiver v1
SLICE-084 - Github check publisher v1
SLICE-083
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
Read what passed. Learn what broke.
I publish the checks, failures, and decisions behind Ranex as I build it. Read the field notes if you want to see how an independent verdict holds up against real AI work.
Subscribe on the next page. Unsubscribe whenever you like.