Why Ranex exists
The agent kept reporting success. The bugs kept turning up. Ranex puts a check outside the loop that produced both the code and the report.
Where this started
Anthony was building a hosting control panel at work with an AI coding agent. The agent kept reporting that the tests passed, but ordinary bugs kept turning up. Fixes that should have taken minutes consumed hours.
The same agent had written the code, written its tests, and declared the result a success. Its report could not tell him whether the work met the requirement or whether the tests repeated the mistake.
Ranex grew out of that problem. Freeze the checks before the work starts. Read what changed on disk. Require evidence for the exact commit. Let code outside the agent's loop decide whether the work can pass.
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 ordinary gate evaluation uses an unauthenticated approver name. Signed approval verification is available in the task-merge path.
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 an early, source-run kernel. The CLI and verification mechanisms are available today. External-harness delegation is a prototype, operator setup is required, and strict-local confinement needs a qualified Linux host.
Run the checks, inspect the evidence, or help close a gap.
See it for yourself
The kernel is open source under MIT. Read the code that decides pass or fail, or see how to contribute.