Trust Model

Claim Boundary

What a green result is allowed to mean.

A green or non-failing EvalGlass result is a bounded claim about what was measured — not evidence that the output is correct or the system is safe. The boundary is the most important idea in EvalGlass: read past it and the number starts lying.

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:

The cardinal rule A green or non-failing EvalGlass result must never imply more evidence, authority, comparability, calibration, or safety than the run actually has.

What a green result does and does not say

It saysIt 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.

FilterThe question it asksIf it is not met
MeasurementWas the metric actually measured — scored and valid?The value is excluded; it cannot back a claim, and it is never read as 0.0.
AuthorityIs the metric allowed to gate — validated dataset, approved threshold, calibrated judge, permitted policy?The metric stays informational: evidence, not enforcement.
ComparabilityIf a regression is claimed, do the run fingerprints match on gating dimensions?The comparison is not_comparable; no regression claim is made.
VerdictDid 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.

A gate is a host YAML edit, not a verb To make a metric gate you edit host-owned records — 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.

Next steps