Checks

Checks are the gates that run before anything is trusted

Every check starts from evidence and records who decided it. When several checks are folded into one, the strictest verdict wins.

Install Excellent Read the rulebook

Verdict precedenceStrictest first

MISMATCH 01
FAIL 02
UNKNOWN 03
NOT_RUN 04
PENDING 05
PASS 06

When several checks are folded into one, the strictest wins. PASS is last.

“Done” is a claim an agent makes about its own work. A verdict is what happens when something else goes and looks.

Evidence, authority, verdicts

A verification weighs the evidence and who decided it, then resolves to exactly one verdict

Every check starts from evidence: Git, tests, browser checks, CI, APIs, databases, deployments, another model, or a person. It is not all worth the same. Evidence carries a type, where it came from, how independent it is, whether it can change, and how fresh it is, and those together decide what it can establish.

Every check records the authority of whatever decided it: a machine that re-ran something (deterministic), a person (human), a model (semantic), or a result imported from elsewhere. Only deterministic checks and people can carry a result to a pass. A new kind of authority is untrusted until it is deliberately added.

A verification resolves to exactly one of six verdicts. When several checks are folded into one, the strictest wins, and one unresolved check is enough to sink an otherwise clean set. An empty set is NOT_RUN. It is never a pass.

A receipt records the verdict with the evidence it read and the policy it was judged under, signed and append-only. A fail followed by a repair and a pass leaves both on the record.

Claims and evidence How verification decides

Tests, lint, build, browser and deploy checks

Run the focused proof for each change.

Required gates, named per task

Name the checks a task must pass before its result counts.

Candidate comparisons

Compare agent configurations on held-out tasks across quality and cost before you promote anything.

Regressions stay visible

Kept in view instead of averaged away.

Result states

A check returns one of four plain results, in words you can act on

Checks and results

Verified
The claim held.
Returned
Sent back with the unmet check, the observed and expected result, the evidence and the next action.
Needs a decision
A person decides.
Not checked
The check could not run. It stays visible in the count.

Verdicts

A signed receipt says one of six verdicts, and only one of them is a pass

PASS
Every obligation holds, at or above the authority floor.
MISMATCH
An independent record was consulted and contradicted the claim. This is an accusation.
FAIL
Conclusive, and short of a pass, with no independent contradiction demonstrated. A refusal to certify.
UNKNOWN
No finding. Coverage was partial or integrity did not hold. A human is asked to fix an instrument.
NOT_RUN
Nothing was looked at.
PENDING
Too early to tell, with a deadline. It can never expire into PASS.

MISMATCH > FAIL > UNKNOWN > NOT_RUN > PENDING > PASS

PASS is last.

Authority

Four kinds of authority can decide a check, and only two can carry it to a pass

deterministic
A machine re-ran something and observed the outcome.
human
A person looked.
semantic
A model judged.
imported
The result came from somewhere else.

Only deterministic and human can carry a set to PASS. A PASS also needs a deterministic proof that the evidence is intact.

Model judgment

A model can say no, but it can never say yes on its own

A model's judgment counts as evidence. It can move a verdict down, where a cited conflict becomes FAIL, or route it to a person. It can never move one up. A judgment that cites nothing resolves to UNKNOWN. So the most an injected instruction can reach is a human review.

The six routes a model's judgment can take
Route	Taken when
`unknown_uncited`	The judgment cited nothing.
`uncalibrated_model_needs_review`	No calibration on record.
`unknown_model_reported`	The model said it did not know.
`cited_conflict_exception`	A cited contradiction (resolves to FAIL).
`high_consequence_support_needs_human`	Supports the claim, but the stakes are high.
`cited_support_needs_review`	Supports the claim, a person still reviews.

Against gaming

Six rails keep an agent from gaming its own verification

No learned component sits in a gate decision.

01
An agent cannot verify its own work.
At least one actor who never claimed the task must verify it.
02
An agent cannot verify code it wrote.
Even if someone else claimed the task, and even after a rebase.
03
The verifier must not share the worker's execution boundary.
04
A producer's account of what changed is not evidence.
Only an independently observed diff is admitted.
05
The baseline is captured before the work starts.
Without it, a before-and-after check says UNKNOWN.
06
An obligation that cannot fail is refused.

Retries

A re-run is a new attempt, so both results stay on the record

Retry limits
Where	Attempts
Semantic judgment per check	2 attempts
Verification API executor	3
Connector queue	3
Webhook delivery	6, backing off 1m, 5m, 25m, 2h05, 10h25

Flaky tests are not modelled, by design. There is no quarantine and no “re-run until green”. A test that passes and fails on the same input produces two receipts that disagree, and that disagreement is the finding. Flake handling belongs in your test runner.

Limits

What this does not claim

Independence today is process-distinct on one machine. A verifier in a separate boundary, under the same operator, is structurally separated from the producer. It is not an adversarial third party. Read a receipt for what it is: tamper-evident proof of what was bound and checked together, by a process that could not also have written the code.

Install

Run a check on real work: install Excellent and hand your agent one task

curl -fsSL https://excellent.so/install.sh | sh

See a real receipt