What Ranex cannot yet prove
Every vendor in this category profits from the buyer believing the green check. A product whose entire premise is that claims require evidence is bound by its own logic to publish its own unproven claims — or it refutes itself the first time someone checks.
A judge that hides its own blind spots isn't one.
This list is taken directly from the kernel repository's own README, section "Known gaps — stated plainly." Nothing below is softened, and nothing below is invented — the kernel is MIT-licensed, so every line here is checkable against the source.
The confinement controller is same-uid trusted infrastructure
“The bound command runs inside a qualified strict-local session — Landlock, seccomp, cgroup, an environment allowlisted to LC_ALL/TZ, no inherited file descriptors — and evidence is signed only after that confinement result validates, fail-closed. The standing limit, stated plainly: the controller subprocess that invokes the session still runs as the same user. The model credential still sits in a network-open loop.”
What this means: A worker cannot steal the signing key mid-run, which closed a real risk (RISK-06). But the process that supervises confinement is not itself sandboxed from the machine it runs on — it is trusted, not proven. If you hand a worker a model API key, use one that is scoped and spend-limited, because that credential is reachable over the network for the run’s duration.
Approver identity is unauthenticated
“--approver is a plain string, so a producer can name anyone as their approver. Evidence signing proves only that the holder of the registered private key signed the record; it proves nothing about who approved it. No-self-approval compares those unauthenticated strings.”
What this means: Whoever produced the evidence cannot record the approval — that rule is enforced on every evaluation, with no exception path. But today it is enforced over names, not verified people. Nothing stops a producer from typing a different name into --approver. This caveat ships every time the no-self-approval claim does; it never ships alone.
The journal does not detect rollback or truncation
“Concurrent appenders are serialised before they read the previous link, and ranex journal verify recomputes the chain. But an internally consistent earlier prefix still verifies after later rows are removed.”
What this means: The journal is append-only and hash-chained — ordinary edits and deletes are refused by database triggers, and tampering with any row already written is caught. What is not yet caught: someone truncating the journal file back to an earlier point and deleting everything after it. A shorter, internally consistent history still passes verification. This gap is unassigned in the kernel repo’s own tracking.
The suite manifest freezes test IDs, not test bodies
“The suite manifest freezes test IDs, not test bodies. Identified by two independent adversarial reviews (2026-08-06); no prototype has been opened for this authenticity gap, so production hardening for it remains unstarted.”
What this means: Freezing test IDs stops a swap-in of a different test under the same name from going unnoticed by ID — but it does not yet stop someone from editing what a frozen test actually checks while its ID stays the same. Every hardening idea has to be proven red-first in a scratch prototype before it becomes production code; this one has not been started.
evidence.json is overwritten, not appended
“Identified by the same two independent adversarial reviews (2026-08-06). No prototype has been opened; production hardening remains unstarted.”
What this means: The journal itself is append-only and hash-chained. The working evidence file that feeds it is not — a later write can replace an earlier one rather than being added alongside it. The permanent record is protected; the file that populates it, today, is not yet held to the same standard.
Network is denied only during provisioning
“Identified by the same two independent adversarial reviews (2026-08-06). No prototype has been opened; production hardening remains unstarted.”
What this means: Dependency provisioning is network-denied by design, so a fetched package can’t phone home during that step. Outside of provisioning, network access is not yet cut off for every step that runs — including the step where a worker holds a model credential.
No flow graph, no scenario compilation, no budget, no escalation
“Those are designed, not built. Worker dispatch left this list — ranex task dispatch|judge|merge|delegate|fanout ran a real model end to end, and the kernel publishes the judged candidate through ordered journalled checks. The free-prompt fanout grammar remains prototype-only until its governed CLI exit is qualified.”
What this means: The chain the README draws — idea → flow graph → covering paths → scenarios → contract tests → gates → verdict — has a working verdict path at its right-hand end. Everything to the left of tests (turning an owner’s approval into frozen, generated tests) is architecture, not code. Bounded worker fanout runs today as a prototype only; it is not approved mutation authority in production.
Ask any AI coding tool the same four questions
Including this one. The gap list above is what a real answer to those questions looks like, in writing, before you asked.
Read the four questionsRanex is pre-release.
A working verdict path, and a list of exactly what it doesn't cover yet. Read the code that decides pass or fail, or watch it refuse a claim with no evidence.