Reference
Verdicts & exit codes
One decision path, one process exit.
The Verdict Engine is the one function turning per-gate measurement and authority
into a run outcome — informational, pass,
fail, or blocked. It is the
only verdict path; every consumer renders its typed
VerdictPayload and none
recompute it. The CI exit is a lookup over that verdict — never a second opinion.
A single decision point is what keeps EvalGlass honest. If the CLI, a report, or a sink could each form its own opinion, the green check would stop meaning one thing.
authority active? (can_gate)
no
INFORMATIONAL
evidence · not an active gate
yes
any blocking condition?
authority blocked
no_measured_value
incomplete_measurement
no_approved_threshold
yes
BLOCKED
cannot claim · counted
no
value meets approved threshold?
below
FAIL
validly below threshold
meets
PASS
threshold met
blocked
fail
pass
informational
run verdict = highest-precedence outcome present ·
ci_should_fail = fail or blockedVerdictPayload is rendered by consumers, never recomputed.Precedence
| If any active gate is… | Run verdict | ci_should_fail |
|---|---|---|
| blocked | blocked | true |
| failing (and none blocked) | fail | true |
| passing (and none blocked/failing) | pass | false |
| none active — all informational | informational | false |
The run verdict is the highest-precedence outcome present: blocked > fail > pass > informational.
When an authorized gate still blocks
Reaching can_gate is necessary but not sufficient. Even an authorized gate blocks —
rather than guesses — when the measurement is not whole:
| Condition | Reason recorded |
|---|---|
| No aggregated value to compare. | no_measured_value |
| Some examples were excluded from the math. | incomplete_measurement |
| No approved threshold to compare against. | no_approved_threshold |
| Authority resolved to blocked upstream. | the authority reason (e.g. policy_forbidden) |
The gate rule is evolving experimental
The shipped, installed path compares the metric’s point to the approved
threshold (now, above). An experimental epistemic layer being hardened
in the framework instead decides on the
lower confidence bound — so a
lucky small-sample score does not gate. See Confidence & intervals.
It is not the installed default.
Exit codes
| Verdict | Code | What CI should read it as |
|---|---|---|
| informational | 0 | Evidence only — no active gate ran. Build proceeds. |
| pass | 0 | Active gates met their approved thresholds. Build proceeds. |
| fail | 1 | An active gate was validly below threshold. Build fails. |
| blocked | 1 | An active gate could not be claimed honestly. Build fails. |
| setup / infrastructure error | 2 | The run could not complete — not a quality verdict. |
Exit 0 is not verification · green = a specific approved pass
Exit
0 covers both pass and
informational — a fresh run gates nothing and exits 0 as
informational, never pass. So
exit 0 does not mean quality was checked. Green is reserved for a specific
approved pass; it never means “safe AI.” There is no gate /
approve / certify verb.
The payload re-derives itself
VerdictPayload recomputes its verdict from the gate lists on construction and rejects
a mismatch; ci_should_fail is fixed as “verdict is fail or blocked.” A consumer cannot
hand-set a friendlier verdict — the engine fails closed on tampering.