Blog

What a deterministic verdict is — and what it is not

A verdict is deterministic when the same diff and the same evidence produce the same answer, every time, with no model in the loop. That property is what makes a verdict worth gating a merge on.

2026-08-18 · Sathwik R

A deterministic verdict means this: given the same diff and the same signed evidence, the decision is the same answer every time — computable by anyone, disputable by no one, with no model anywhere in the loop. Relay's two standing invariants follow directly: no model output is ever an input to a verdict, and Relay never says "safe to merge."

Those two sentences do more work than they appear to.

Why keep model output away from the verdict?

Because the whole exercise is grading work a model produced. If a model also graded it, you would have an opinion checking an opinion — eloquent, plausible, and unfalsifiable. The circularity is subtle in practice: it arrives as "the agent summarized the test results," or "the reviewer bot said the coverage looks fine." The moment any generated text can move the decision, the decision inherits the properties of generated text.

So the verdict path consumes only measured things: the diff, the coverage report of a real test run, Ed25519 signatures over the evidence, a snapshot hash binding the evidence to the exact tree it describes. An agent can *drive* the loop — run the commands, write the missing test, re-run — but nothing it says is an input. Anything it could fabricate, the verdict ignores; anything the verdict consumes, it could not fabricate.

What does a PASS actually assert?

Something narrow, and precisely that: every changed executable line has coverage evidence from a test run that was measured, signed, and bound to this exact diff — and the signatures and snapshot check out. The reason arrives with the verdict:

"state": "PASS",
"reason": "4 / 4 changed line(s) executed for \"add a percentage
           discount to invoice totals\"; signed evidence valid;
           required checks passed."

What does a PASS not assert?

That the code is correct. That the tests are good tests. That the design is sound. That you should merge. A test can execute every changed line and still assert the wrong thing — verification tells you the change was *exercised*, not that it is *right*.

This is why Relay refuses the phrase "safe to merge," and a test in our suite asserts the phrase is absent even inside a negation — an agent matching on substrings would find it and misread it. A tool that measures one thing precisely and then claims a broader blessing has converted its measurement into marketing. The narrowness is the value: when the verdict says PASS, you know exactly what was established, and everything it does not establish stays visibly yours to judge.

Is a deterministic gate compatible with LLM review?

Fully — they answer different questions. A reviewer (human or model) asks "is this a good change?" — a judgement, and worth having. The gate asks "did anything execute these lines?" — a fact. Judgements improve with smarter models; facts do not need one. Teams that conflate the two end up either gating merges on an opinion, or treating an opinion as if it were a fact. Keep the judgement in review, keep the fact in the gate, and let each do what it is for.

The gate's mechanics — receipts, snapshot binding, the agent loop — are in the docs. The property to hold onto is the one in the title: same inputs, same answer, no model in the loop.