TL;DR: If the same actor produces the evidence and approves it, you do not have verification. You have agreement. The accountability apparatus starts outside the worker.
Your agent hands over a diff, a test it wrote, and a green summary. You are tired, the deadline is loud, and every line looks plausible. Who is left to say the proof counts?
In this note
- Why production and approval must split
- How a test stops becoming a moving target
- A separation-of-duties checklist
- What the current limit is
The producer cannot approve its own proof
That is the rule. Whoever produced evidence cannot approve it. The README calls it one of the rules that makes a verdict trustworthy, and the reason is not subtle: one actor can write code, write the test around that code, and declare success. The target then follows the dart.
Picture the merge you need to ship. An agent chooses the behavior, changes the implementation, changes the assertion, runs the command, and reports green. Nothing in that chain required a lie. The agent can be sincere. The result can still establish nothing beyond internal consistency.
That is the third failure described in the README’s “The problem” section: the person making the change gets to paint the bullseye afterward. A green check is only useful when the thing it measured was not arranged by the party being measured.
Competence does not dissolve a conflict of interest. A stronger model changes the quality of the work. It does not turn self-approval into independent approval. Give the producer perfect recall, flawless code generation, and a complete map of your repository — the boundary still matters because the roles did not change.
This is why the rule survives the fantasy of perfect AI. The question is not whether a producer is clever enough to check itself. The question is whether your release process asks it to be the witness, the judge, and the beneficiary of the same claim. Would you accept that shape from a person?
Freeze the target before the work starts
Separation cannot begin at the final approval button. It has to reach back to the test. Ranex describes tests frozen before BUILD, generated in COMPILE, digested, and read-only to implementers. A test file changed by the implementation diff fails the gate.
That gives you a sequence worth copying even if you never run Ranex:
- State the behavior before the implementation begins.
- Turn that behavior into an executable test before the producer can shape it.
- Show that the test fails against the pre-implementation tree.
- Keep the implementer from authoring or judging that test.
- Let a separate approval step decide whether the resulting evidence counts.
The red-then-green step matters. A test that already passes before the behavior exists is not a target. It is an alibi. The no-self-approval rule matters beside it. A producer who can rewrite the test until it passes has moved the target even if the final command is real.
The intended build loop draws the boundary again. A worker returns a diff. The kernel reads the diff on disk and runs checks; the worker summary is discarded. Workers do not merge. The README is explicit that models can propose, criticize, or translate, but cannot pass a gate.
That full governed loop is designed, not built. Ranex is pre-release. What works today includes the narrower kernel rule: evaluation is a pure function of gate, evidence, subject, and approver, and no self-approval is listed as working behavior. Keep that distinction intact. A design is not evidence just because it is a good design.
Check the separation before you trust green
You do not need to replace your stack to ask this question. Take a recent agent-assisted change and trace the roles, not the tools.
- Who produced the evidence for the claim?
- Who approved that evidence?
- Could the implementer author or edit the test that judged the change?
- Did the test fail before the implementation existed?
- Did someone inspect the artifact on disk rather than accept the worker summary?
- Can the producer publish the result without a separate decision?
If one actor owns every answer, your process has a green light but no independent basis for it. That is not an accusation. It is a missing control. You can fix it with role separation, frozen tests, and a reviewer who has authority to refuse the claim.
Do this with agent sessions too. “Different prompt” is not a different approver when the same session can revise the evidence until it likes the result. Name the producer. Name the approver. Preserve the boundary.
The current limit is identity, not the rule
Here is the part you should not skip. Ranex compares producer and approver values, but the approver identity is unauthenticated today. --approver is a plain string. A producer can name someone else as the approver.
Evidence signing establishes that the holder of a registered private key signed an evidence record. It does not establish who approved it. The no-self-approval comparison therefore works on unauthenticated strings. The README lists that as a known gap, plainly.
So do not turn this post into a larger claim than the repository supports. The working rule blocks matching producer and approver values. It does not solve identity. The stamp stays a human’s, out of band, in the intended loop — and authenticating that human remains unfinished work.
That stated limit is useful to you. It tells you where to inspect your own process next: a separation rule without trustworthy identities has a hole at the label. Keep the rule. Do not pretend the label closes the hole.
The separate approver protects a bounded claim, not a promise that everything is right. A gate verdict has its own narrow meaning — and that is why the approval boundary matters.
Questions people actually ask
What is the no-self-approval rule?
Ranex no-self-approval means whoever produced evidence cannot approve it.
Why does no self-approval still matter with better AI?
Separation of duties still separates production from approval when the producer is more capable.
Is approver identity authenticated in Ranex today?
Ranex does not authenticate approver identity today because --approver is a plain string.
Try it. Break it. Tell me what broke. Read the MIT-licensed repository, then trace one change through your own approval path.
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)