The parts of the judge outside your loop

A verdict is a pure function of (gate, evidence, subject, approver). Same inputs, same verdict, always.

A non-blocking gate is decoration, so the kernel refuses to construct one at all.

Removing every model credential from the machine must not change a single verdict — a stated invariant, not a preference.

ranex task delegate runs a real agent in a dispatched worktree, in an environment built from empty that refuses to start holding the signing key; a wall-clock bound kills the whole process group. The worker returns a diff, never a verdict.

ranex task fanout runs a bounded pool of workers, one worktree each, and the journal chain verifies after concurrent runs — but it is prototype scope: no A/B/C approval or child-grant admission yet, so it is not approved mutation authority in production.

ranex task merge publishes a judged candidate only through ordered journalled checks — ancestry, merge-range, digest/evidence, and CAS each refuse red-first. Workers never merge; the kernel does, as a checked fast-forward.

Intake to an owner-approved flow graph, mechanical compilation to scenarios and frozen contract tests — the human decides what the software should do; the kernel decides whether it happened. Designed, not built, and the README says so.

A required claim with no satisfying evidence is FAIL — never a default, never a skip. On a fresh clone the gate fails by design, naming exactly the missing claim.

The same command run against a different commit proves nothing about this one. Stale evidence stops counting automatically.

Ed25519 signatures verified against a committed public keyring before a record is admitted. The verifier holds only public keys and cannot forge.

The committed catalog declares the argv that satisfies a claim, and the kernel compares its digest — so a signed record of `true` no longer satisfies "tests executed".

A record that fails verification is reported as refused, never as "no evidence" — because an attack and an unfinished task are not the same event.

The command runs against a materialisation of the subject commit — every blob checked against the object id the tree carries. Not your working tree.

Locks are re-derived clean and byte-compared, only SHA-256-addressed wheels enter the store, and a human approves the named package delta before a gated run.

Signed structured outcomes are judged against a frozen suite manifest. An undeclared skip, xfail, xpass, error, or missing test ID blocks the gate; a zero exit code alone does not satisfy the gate.

The kernel already judges this repository's own suite — 943 frozen test IDs, run provisioned, sealed, and offline against the real current commit.

An approved, hash-correct wheel still chooses its own exit code. Recorded in the repo as a passing security test that states the boundary — not smoothed over.

Whoever produced the evidence cannot record the approval — producer and approver are never the same actor, on every evaluation, with no exception path. The caveat that ships with this claim every time: approver identity is unauthenticated today, so this check compares unverified strings.

A separate keyless invocation judges the worker's emission — producing a CANDIDATE that names its missing claims, never a PASS. The stamp stays a human's, out-of-band.

The task that implements a scenario should never author or judge its own test: tests frozen before BUILD, red-then-green enforced, edge coverage as a gate rather than a metric. That general rule depends on flow-graph and scenario compilation, and the README lists both as designed, not built.

SQLite triggers prohibit ordinary updates and deletes; the hash chain detects out-of-band row edits.

One command recomputes the hash chain end to end, so an auditor does not have to trust the machine that wrote it.

An internally consistent earlier prefix still verifies after later rows are removed. A stated limit in the README, assigned — not hidden.