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 · pre-release
▶ 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.
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 pre-release and its README says so 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 is pre-release. Here’s what you can check anyway.
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- Approval and intersected grants
SLICE-03217 AugApproval binds closed policy and lifecycle facts; revocation, expiry, canonical use facts, and deterministic least-authority child grants refuse authority expansion. CAS/persistence and the SpecificationEvent atomicity contract remain SLICE-036.
- Real subject bootstrap
SLICE-03517 AugReal Ranex source bootstrap ran from its pinned subject; Arxic's reference-auth-app process gate remains BLOCKED at pinned `135991d9` (Arxic #109).
- Trace integrity
SLICE-03317 AugIndependent trace coverage binds changed source symbols to exact current generated comment/sidecar references and separately verifies protected outcomes; generator interoperation covers Python, TypeScript, and JavaScript.
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.
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.