About Ranex
Deterministic governance for AI agents that build software. Verdicts come from evidence and executable checks, never from model confidence.
Where this started
He was building a hosting control panel at work, letting an AI agent write the code while anime played on the second screen. It was working, until it wasn't.
Then came bugs that shouldn't have existed: the kind you fix in five minutes, except each one ate an hour, then two. The agent kept reporting the tests passed. The code kept not working.
He wasn't losing time to bad code. He was losing time to a report he had no way to check. The agent wasn't lying. It believed the tests it had just written, because it had just written them.
The fix wasn't a better prompt. That's the moment he stopped trusting the report and started asking who was allowed to write the verdict. Smaller tasks, a clear view of what actually changed, and a check outside the loop that had no reason to lie: it never picked up the dart in the first place.
What Ranex is
Ranex is a kernel (ordinary, inspectable code) that stays outside the AI's loop and judges every step of its work. The kernel never asks a model what to do next. Rules an agent can read are suggestions. Rules compiled into code are constraints.
It is make for a nondeterministic compiler: make invokes gcc; nobody asks gcc what to build next. Tools like Replit, Lovable, and Base44 optimize the throw: better model, better prompt, faster loop. Ranex optimizes the scoring.
Ranex never trusts the worker, including its own loop's. It reads the diff on disk, runs the checks, and throws the agent's cheerful self-report straight in the bin. It does not need to control what happens inside the loop, only what is allowed out of it. Containment beats control, and costs far less.
The mission
Make misses visible and cheap, and hits provable. Every verdict is delivered by code, pinned to the exact version of the work it judges. Removing every model credential from the machine must not change a single verdict.
The vision
A person hiring an architect relies on licensure, liability insurance, building codes, and inspectors: an accountability apparatus that exists outside the architect. AI labor has none of that. Ranex is an attempt to build the missing apparatus: the code, the inspector, and the record.
The problem
An AI writing software is a blindfolded dart thrower with a guide shouting coordinates. Two things go wrong, and they are separate problems:
1. The thrower is blind
It cannot perceive whether its own dart landed, so it reports success either way.
2. The guide is bad
The coordinates were wrong or vague before the throw ever happened.
3. The third failure, and the most common
Most tools let the thrower paint the bullseye around the dart after it lands. One actor writes the code, writes the test, and declares success. That is why "all tests pass" from an AI means so little: the target moved to wherever the dart went.
How Ranex works
Three ports around one kernel, and only executable checks produce a verdict
The kernel is code
A verdict is a pure function of gate, evidence, subject, and approver. Same inputs, same verdict, always. Models can propose, critique, and translate. None of them can pass a gate.
Fail-closed gates
Evidence is bound to the exact code version it describes, so stale evidence stops counting automatically. A required claim with no evidence is FAIL, never a default. Whoever produced the evidence can never approve it, though approver identity itself is a plain string today, unauthenticated.
The record
Every verdict lands in an append-only, hash-chained journal, though it doesn't yet detect a rollback or truncation of the journal itself. Evidence is signed and verified against a committed keyring before a record is admitted.
What Ranex does not claim
1. It does not improve aim
Ranex does not make your AI write better code. Not by one degree. It makes misses visible and cheap, and hits provable. Nothing here claims more than that.
2. It does not certify what you never specified
A passing build proves that every behavior on the plan you approved has an executable test, every test ran, and every test passed, pinned to an exact code digest. Anything off that plan is unconstrained: absence of a requirement is absence of a guarantee.
3. It does not promise "correct"
Only the person who owns the target can judge whether the plan was right, and only by using the thing. "Conformant to an approved specification" is real, defensible, and deliverable. "Correct" is not a claim anybody can make.
The founder
Anthony Garces has spent 17 years in software, currently a Senior Principal Lead Architect, and before that four years at Pantheon, where he ran the technical support team and worked platform-level problems on mission-critical sites: caching, load testing, scaling, the failures that only show up in production.
That night with the hosting panel is why Ranex exists. Seventeen years of watching systems fail is why he was the one who noticed: the dangerous failure isn't the loud one, it's the green light that proves nothing. A check that didn't run. A test that was skipped. A report nobody verified. AI coding agents made that failure cheap to produce at scale: the agent reports success whether or not the work is done, and no amount of better prompting fixes a judge that grades its own homework.
So he builds tools that prove things instead of claiming them. Ranex is one of several: Arxic for replayable evidence of behaviour, Leitir so agents read verified source instead of hallucinating it, Oryzn for audit history that can't be rewritten. Same idea each time, aimed at a different corner of the problem.
He also runs Anito, his development company, built on the same premise: your code and credentials are yours on day one, no lock-in. His profile there runs the same seventeen years from the service desk up: Anthony Garces at Anito.
Where it stands
Ranex is pre-release and kernel-only, and the README says exactly that. v0.1.0 was released on 2026-09-03: every tracked blocker closed with commit evidence, and the kernel already gates Ranex's own test suite. The full picture (flow graphs a non-technical owner approves, scenario compilation) is designed, not yet built.
The hardest part to get conceptually right exists. Watch us build the rest, or help.
See it for yourself
The kernel is open source under MIT. Read the code that decides pass or fail, or see how to contribute.