Trust Model
Claim Boundary
What a green result is allowed to mean.
Every Scorecard answers one careful question: given the supplied evidence, authority records, metrics, thresholds, calibration, baselines, and data policy, what can EvalGlass honestly say? It never answers “is this output right?” — that judgement stays with you. The cardinal rule of the framework states the limit directly:
What a green result does and does not say
| It says | It does not say |
|---|---|
| The metrics that were validly measured met the thresholds the host approved, on the evidence supplied. | The output is correct, complete, or fit for your domain. That remains a human and host judgement. |
| No active gate was below its approved threshold or left unmeasurable. | That any gate was active at all — a fresh install gates nothing and reports informational. |
| The run produced a typed, reproducible record you can inspect. | That the result is comparable to a previous run, unless provenance says so. |
The boundary is built from filters, not optimism
“Green” is not a single switch. A claim only survives if it passes every filter below; failing any one narrows what the result may assert. This is why a passing-looking number can still be informational — it never reached the gate.
| Filter | The question it asks | If it is not met |
|---|---|---|
| Measurement | Was the metric actually measured — scored and valid? | The value is excluded; it cannot back a claim, and it is never read as 0.0. |
| Authority | Is the metric allowed to gate — validated dataset, approved threshold, calibrated judge, permitted policy? | The metric stays informational: evidence, not enforcement. |
| Comparability | If a regression is claimed, do the run fingerprints match on gating dimensions? | The comparison is not_comparable; no regression claim is made. |
| Verdict | Did the single Verdict Engine resolve the active gates? | This is the only place a run outcome is decided — no consumer recomputes it. |
No verb makes a run pass
EvalGlass now ships as a plugin, but that delivery surface changes nothing here: the plugin exposes no command, skill, or flag that gates, approves, certifies, or makes a run pass. The absence of that verb is deliberate — it is the boundary made operational. A run is informational until a gate is active, and activating a gate is not an action the plugin performs.
metric_status: gating,
threshold_approval: approved, dataset status: validated. The
promoting-a-gate skill can walk you through the edit and even type it at your
direction, but it never grants the authority — see Promote a Gate.
Why this matters more than coverage
An evaluation you cannot trust is worse than none, because it launders a guess into a green check. EvalGlass would rather report informational or blocked than imply a confidence it did not earn. Honest measurement over broad weak coverage is the trade the whole framework is built around.
Concretely, the product claim a Scorecard stands behind is narrow and explicit:
the product claim
Given the supplied evidence, authority records, metrics, thresholds,
calibration, baselines, and data policy, EvalGlass can honestly emit
this Scorecard and verdict.
Anything beyond that sentence — “the model is good”, “the agent is correct”, “the release is safe” — is your inference, and the docs will keep pointing back to this boundary so it stays visible.