TL;DR: If your green result depends on the clock, a network call, or a model’s opinion, you cannot replay it; Ranex makes the verdict a function of gate, evidence, subject, and approver. Read how the kernel works.
You inherit a green check, then a release breaks. Now you have a hard question. Did the check prove anything, or did the conditions happen to be friendly when it ran?
A verdict must not have a mood. The kernel’s working evaluator takes a gate, evidence, a subject, and an approver. Give it those same inputs and it returns the same verdict, always. That is a narrow promise. It is also the foundation beneath a result you can inspect later.
In this note
- A verdict must not have a mood
- Purity draws a hard boundary
- Check your own verdict path
- Proof is a record you can replay
A verdict must not have a mood
A pure verdict answers from its inputs alone. It does not ask what time it is, call a service, read a model response, or change its answer because a different operator ran it.
That sounds strict because it is. A verdict that reaches outside its inputs is partly a report about the moment it ran. The code could be unchanged while the result moves because a service was down, a credential was present, or a model phrased an answer differently. You are left arguing about atmosphere instead of examining proof.
Ranex states the rule in executable terms. evaluate() is a pure function of (gate, evidence, subject, approver). The repository also names a useful test for the boundary: removing every model credential from the machine must not change a verdict. If credentials can move the outcome, a model is inside the judging path. That is not an assistant helping explain a result. That is an unrecorded decider.
The topology matters here. The model port can propose, criticise, or translate text. The worker port returns a diff from its isolated worktree. The check port produces the outputs that count. None of those model roles can pass a gate. The kernel reads the evidence and applies the rule. Your agent can be inventive where invention belongs; it cannot make the ruler bend.
This does not make a verdict friendly. It makes it legible. When it says FAIL, you can ask which input failed to satisfy the gate. When it says PASS, you can preserve the inputs and ask the same question again later. There is no confidence score to interpret and no model memory to guess at.
Purity draws a hard boundary
Purity does not mean every part of building software is predictable. It means nondeterministic work has a boundary, and the judgment on the other side does not inherit its chaos.
An agent can write different code from the same request. It can take different amounts of time. It can fail before it succeeds. Ranex does not claim otherwise. The determinism ledger separates those facts from the mechanical chain: graph to covering paths, paths to scenario text, test plus code to result, results plus rules to verdict, and journal to full replay. Each left-hand transformation is intended to be a pure function.
Generated code is not the proof. Evidence tied to a subject and rules applied to that evidence are the proof. The approved flow graph is the root of trust in the designed larger loop; graph compilation and the surrounding product flow remain designed rather than built. The current kernel has a working verdict path, not the whole picture around it.
That boundary stops a familiar trick. A worker can say that the diff is correct. A model can say the tests look convincing. Neither statement is a verdict. The kernel needs evidence that satisfies the gate for the precise subject being judged, and it applies the same evaluation rather than trusting a self-report.
It also keeps a hard distinction between what a passing build proves and what it does not. A passing build supports the claim that approved graph behavior has executable tests, those tests ran and passed, and the evidence is pinned to an exact code digest. It does not prove the graph was right, behavior outside that graph, or properties such as performance, accessibility, or security unless separate gates check them. Saying less is not a weakness. It is how the verdict keeps its meaning.
Check your own verdict path
You can inspect whether your own pipeline has this boundary before replacing anything. Start with the green result you least trust. Ask what could change it without changing the commit.
- Can the verdict read the clock, a network response, or a model opinion?
- Can you name the gate, the evidence, the exact subject, and the approver it used?
- Would the same recorded inputs return the same answer on another machine?
- Does evidence from an older subject stop counting after the tree changes?
- Can the person who produced evidence also approve it?
- Can you remove model credentials and get the same verdict?
That list is not a purity contest. It is an incident drill. If one answer is unclear, your next disagreement over a release will be harder because the system did not retain a stable question to ask.
Notice the link between this rule and absence blocks. A pure evaluator is not useful if missing evidence silently becomes success. The evaluator needs stable inputs, and it needs to fail when a required input cannot satisfy a required claim.
Proof is a record you can replay
Purity buys replay, audit, and freedom from a judge’s mood. It does not bless bad evidence; it makes the question of evidence impossible to hide.
Subject-bound evidence is part of that discipline. The same command against a different commit proves nothing about the current one, so stale evidence stops counting. No self-approval is another part: whoever produced the evidence cannot approve it, though approver identity is unauthenticated today, so that check compares unverified strings. These are admission and gate rules around the pure evaluator, not decorations attached after a green result.
The repository’s Status section says the project is pre-release and describes the evaluator as working today. It also says the full governed loop is not all built. Read that as a boundary, not a sales pitch. A small, repeatable verdict path is useful precisely because it does not pretend to settle every question about a system.
When someone challenges a PASS, the useful answer is not “trust the process.” It is “here are the gate, evidence, subject, and approver; run the evaluation again.” If the answer changes, the record or the evaluator changed. Either way, you have something concrete to investigate.
Questions people actually ask
What is a pure-function verdict?
Ranex evaluates a pure-function verdict from gate, evidence, subject, and approver, so the same inputs produce the same verdict.
Why must a software verdict be deterministic?
A deterministic verdict lets an operator replay the same recorded inputs instead of trusting the conditions of one run.
Is AI-generated code deterministic?
Ranex says generated code is not deterministic; determinism describes the process and verdict, not the code an agent writes.
Try it. Break it. Tell me what broke. Read the Ranex repository, then try the credential-removal test on a verdict you rely on.
Disclosure: this post was drafted with AI assistance. Every factual claim traces to the repository’s README or slice records, the same fact gate the product enforces on code. It ships only after Anthony’s own review.
Top comments (0)