The trust model

Verified is not correct

Most tools ship the first thing that runs. Code that compiles and passes its own tests is verified — but verified is not the same as correct. A test suite can pass and still miss the bug it was supposed to catch.

Zevron treats that gap as the whole problem. It marks a unit trusted only when it has evidence the code is right, not merely evidence that it runs.

The trusted bar

A unit earns trusted only when all of the following hold:

• it passes the funnel — lint and types (T0), visible tests (T1), then hidden and property tests against real execution in a sandbox (T2–T3)
• it survives the Crucible — adversaries attacking edge cases, the spec, and security
• mutation testing proves the tests have teeth: a mutation score ≥ 0.80

The mutation gate is the key. A high score means that when Zevron deliberately breaks the code, the tests notice. Tests that can't tell — a low score — are not a trusted oracle, no matter how many of them pass.

The held-out Ledger

The Ledger is a benchmark Zevron never trains against. It is the held-out oracle: the place silently-wrong code gets caught, because the unit's own tests can never see their own blind spots.

An honest refusal

This is import.csv. It passed all twelve of its own tests. The held-out hidden suite still caught a silent off-by-one in malformed-row recovery, and its mutation score came in at 0.61 — below the gate.

The verdict is not trusted, and the unit is returned to the forge. Zevron will not claim code is right when it can't prove it. The refusal is the feature.

See it yourself

Run the evidence for any unit and read the verdict for yourself:

For the full output and flags, see zevron trust.