Run the demonstration
Missing evidence.
Blocked work.
Start with a fresh checkout. Ask the gate for a verdict before you give it evidence. It fails and names the missing claim. Then run the checks and inspect what changes.
Watch the refusal happen first. It takes 58 seconds.
One unedited session against the clone below: the suite passes green, the kernel is asked about that same commit, and it refuses. The steps after this are the same commands, written out so you can produce the verdict yourself.
Captured with a real terminal session: every character on screen was produced by the commands shown. The test run is sped up so it fits in a minute; nothing is cut, and the verdict plays at full speed.
A small, real repository, not a demo built to fail on cue
This is the actual kernel, the one that also gates itself. No separate toy repo, nothing staged.
Run the suite directly. Green. This is the report everyone already trusts.
uv run creates the environment and installs pinned dependencies on its own. No separate setup step.
tests/e2e is left out of this command on purpose: it carries host-qualification checks gated on delegated cgroup controllers, and the kernel README says plainly that the real-operator e2e test skips without them. Run it too if your host supports it: uv run --frozen pytest -q, the full suite, no flag.
One command points the kernel at the same commit
The kernel never reads the exit code above. It reads the diff on disk and looks for evidence bound to this exact commit, signed by a registered producer. There is none. Nothing in Step 2 produced any.
--approver reviewer_alice
The subject digest is a hash of your own HEAD, so yours will differ from the one shown above. This is the exact output captured verifying this page against a fresh clone. Absence blocks: a required claim with no satisfying evidence is FAIL, never a default and never a skip, and the exit code is nonzero so nothing downstream can miss it.
What just happened
Step 2's green run and Step 3's FAIL are not in tension. Nothing lied. Pytest ran and reported honestly on what it saw. The kernel asked a different question: not "did a test suite exit zero somewhere," but "is there evidence, bound to this exact commit and signed by a registered producer, that the required claims were satisfied?" A plain pytest -q run, on its own, produces none of that: it was never routed through the kernel's own evidence path. That gap between a report and a verdict is the whole point of this page.
Model API key removed. Rerun. Same verdict.
Take every model credential off the machine and not one verdict changes. This command evaluates a gate, and nowhere in that path does it call a model, so removing the credentials should be a no-op. Verified: it is.
python -m ranex.cli.main gate evaluate HEAD --approver reviewer_alice
What this does, and doesn't, prove
It proves the mechanism: the kernel is code, not a model, judging evidence bound to a commit, and that removing every model credential from the machine changed nothing about the verdict, because the verdict never touched a model.
It does not prove Ranex writes better code, or catches more bugs, or that any code in this repository is correct. Ranex does not improve aim, not by one degree. "Conformant to an approved specification" is a real claim; "correct" is not one anybody can make.
It also doesn't show the full intended loop (flow graph, scenario compilation, and the human approval gate around them are designed, not built yet. What you just watched is the verdict path: the part of Ranex that exists today and already gates the kernel's own suite. The rest of what it can't yet prove is listed, not hidden, on the gap list.
Ranex is pre-release.
A working verdict path, an open-source kernel under MIT, and a gap list that says exactly what isn't built yet.