Verdicts & severity
A check result is designed to be read, not just thresholded.
There are two severity scales, and they are not the same set of values. Mixing them up is the most common way to misread a result.
Per-check severity
Each individual check reports its own CheckSeverity rather than collapsing to a
single scalar:
CheckSeverity | Meaning |
|---|---|
pass | The assertion was tested and holds. |
warn | The claim could not be tested — it is recorded, neither proven nor refuted. |
fail | The assertion was tested and is violated. |
warn is the load-bearing one. It never means “probably wrong”; it
means the engine declined to answer. Cannot check and checked, and
it is wrong are deliberately different values, so that an untested
claim can never be read as a passing one — or as a failing one.
Overall result
The OverallSeverity is a different scale, reported once for the whole
run:
OverallSeverity | Meaning |
|---|---|
NONE | The assertion holds. |
LOW | A soft concern — e.g. a convergence parameter near a limit. |
MEDIUM | A real problem worth a human’s attention. |
HIGH | A hard violation — e.g. dimensional inconsistency or a broken limit. |
It is the worst check, not a hidden average. The scoring model
makes this concrete: overall_score = functional_pass_rate × (1 − severity_penalty),
with penalties NONE = 0, LOW = 0.25, MEDIUM = 0.5, HIGH = 1.0. A
HIGH-severity physical check zeroes the score even when every functional
test passes — physical correctness gates functional correctness.
Provenance
A cards_get call returns the exact card a check resolved against, so a result
is auditable rather than a black box: you can see which principle, which limits,
and which envelopes were applied.