Kelruno · Independent verification for coding agents
Don't let the model grade its own homework.
Kelruno is an independent verification and control layer for AI coding workflows. The agent that builds a change never gives it the final review. Merges and production changes stay behind Human Gates. Every run is judged on execution evidence - not on the model’s own account of what it did.
Pre-release Not generally available. A gated, invite-only Founder Beta is planned.
- Builder execution
- The Builder agent makes the change.
- Independent control
- Checks run; a Reviewer judges the exact SHA.
- Human clearance
- Merge and deploy wait for a person.
The problem
Why self-review is not enough
When one model writes a change, runs its own checks, and then declares the work correct, the review inherits every assumption the author made. A shared blind spot cannot notice itself. A green summary at the end of a transcript is a claim, not evidence.
01
Separate the roles
The Builder, the Verifier, and the final independent Reviewer are different roles with different authority. The agent that builds a change is never its own final reviewer.
02
Record what actually ran
Exit codes, digests, counts, and gate outcomes are recorded and bound to the exact commit. Trusted gates evaluate the candidate as data, not as a story.
03
Keep humans at the boundary
Merge, production deployment, and device changes are Human Gates. Automation prepares the evidence and stops at the gate; it does not pass through it.
Role separation
The Builder is never its own final reviewer
Independence is structural, not a prompt instruction. Each role has a bounded job and bounded authority.
Builder
Makes the change: writes code, runs its own checks, prepares the candidate. A Builder never gives its own work the final review.
Verifier
Runs the candidate’s own gates - tests, preflight checks - and reports exit metadata only. It holds no provider, repository, or infrastructure credentials and cannot approve or publish anything. The Verifier is not the Reviewer: it runs the checks, it does not judge the change.
Independent Reviewer
Reviews an exact commit it did not build, from a different provider/model family where policy requires independent review, with no authority to remediate. A Reviewer that starts fixing stops being independent for that revision.
Review, remediation, and approval target an exact SHA - the precise commit identity. A branch name or a conversation summary is never a substitute.
Human Gates
Human Gates sit outside model authority
Some decisions are not delegated to automation at all.
Merge, production deployment, and physical or network device changes are Human Gates: approvals only a person can give, recorded outside the models’ authority. Automation proceeds up to the gate with the evidence it has gathered. It does not merge, deploy, or mutate devices on its own.
In Kelruno, control means policy, routing, authority boundaries, and Human Gates. It does not mean autonomous production changes.
- Merge - a human merges; automation stops at the review.
- Production deployment - a human deploys; automation prepares the candidate.
- Device mutation - physical and network changes are never automated.
Execution evidence
Judged on execution evidence, not self-report
A model’s description of its own run is an input, never the verdict.
Every run leaves a record made of facts about the run: exit codes, stream digests, byte and line counts, gate outcomes, and the exact commit each fact is bound to. Trusted gates evaluate the candidate as data. Repository-safety controls and the contract validator are deterministic and fail-closed; their verdicts come from mechanical checks, not model judgment.
- Exit codes
- What each gate actually returned.
- Digests and counts
- Stream digests, byte and line counts for what was produced.
- Graded values
- Requested, observed, and effective values kept apart at their real strength.
- Exact-SHA references
- Every evidence item names the precise commit it belongs to.
Requested vs effective
Requested, observed, effective - three different things
A task can ask for a particular model, effort level, sandbox, or approval policy. Kelruno keeps that request separate from what actually happened.
- Requested
- What the task asked for. A request is only a request; it is never promoted into a fact about what ran.
- Observed
- Evidence about the run, recorded at its actual strength. Observations come in grades - accepted by the provider tool, reported by provider metadata, proven by the trusted broker - and a weaker observation is never rounded up to a stronger one.
- Effective
- Reserved for the strongest grade: provider-native, invocation-bound proof of what actually served the run. When a proven effective value differs from the request, the effective value wins in audit and history.
If a requested/effective mismatch cannot be explained, the run is blocked. That is what fail-closed means in practice.
- Requested a request
- What the task asked for: model, effort, sandbox, approval policy. Never recorded as a fact about what ran.
- Observed graded evidence
- Recorded at its actual strength - accepted by the tool, reported by provider metadata, proven by the trusted broker. Never rounded up.
- Effective strongest grade
- Provider-native, invocation-bound proof of what actually served the run. Wins over the request in audit and history.
requested ≠ effective, unexplained → run blocked
Principles
Fail-closed, with bounded authority
When a required condition cannot be proven, Kelruno refuses and stops rather than proceeding with a degraded substitute.
Refuse rather than degrade
Where routing policy requires refusal, there is no silent fallback to another provider, model, or effort level. Unsupported routes refuse; they do not quietly downgrade.
Candidate code never holds supervisor authority
The code under review runs without the authority of the system that supervises it.
The Verifier holds no credentials
No provider, repository, or infrastructure credentials. Review and CI jobs run with read-only tokens.
Mechanical verdicts for safety controls
Repository-safety controls and the contract validator are deterministic, fail-closed, and standard-library-only. Their verdicts do not depend on model judgment.
Where it fits
Where Kelruno sits in an AI coding workflow
Kelruno does not replace your coding agent. It sits between the agent’s output and the decisions that matter.
- Builder Coding agent Makes the change. Never its own final reviewer.
- Verifier Runs the candidate’s checks Reports exit metadata only. Holds no credentials.
- Independent Reviewer Different model family where policy requires Reviews the exact SHA. No remediation authority.
- Human Gate A person decides Merge, deploy, device changes. Outside model authority.
- A coding agent, acting as Builder, prepares a change on a branch.
- The Verifier runs the change’s own checks and records exit metadata - nothing more.
- An independent Reviewer - a different provider/model family where policy requires it - reviews the exact commit. It cannot fix; it can only judge.
- Execution evidence, review, and approval all bind to that exact SHA.
- A human decides at the gate: merge, deploy, or stop.
Availability
Current status: pre-release
Kelruno is not generally available. There is no public self-service signup and no published pricing. A gated, invite-only Founder Beta is planned.
This site describes the principles Kelruno is built on and the capabilities that exist today. It does not promise what is not built.
Contact
Get in touch
Kelruno does not yet publish a public contact address or signup form. When one exists, it will appear here.