Trust Model

System Boundary

Where each responsibility lives.

EvalGlass splits work into four layers with hard edges: the Evaluation Core decides meaning and performs no effects, the Runtime Harness performs the effects, the EvalGlass Skill installs at integration time, and the host owns domain truth. Keeping these apart is what lets one — and only one — place decide a verdict.

Most of the trust properties on the other pages reduce to this boundary. Meaning never touches the filesystem; effects never invent meaning; the installer never grants authority; and domain judgement never leaks into the managed framework. The diagram shows how a run crosses these edges without blurring them.

Who owns what

LayerOwnsMust not own
Evaluation Core Contracts, score states, aggregation, provenance, authority resolution, the Verdict Engine, JSON shapes. Any I/O, network, subprocess, clock, randomness, model call, or domain knowledge.
Runtime Harness CLI, config, ports/adapters, replay, judge collection, persistence, reports, exit mapping. New score meanings, ad-hoc verdicts, hidden authority.
EvalGlass Skill Discovery, vendoring, manifest/lock, scaffolds, CI snippets, the confirmation checklist. Runtime execution, metric authority, automatic gating, silent host edits.
Host-owned truth Examples, references, rubrics, thresholds, calibration, baselines, evaluator code, approvals. Managed framework internals.

Why the edges are load-bearing

Because the Core is effect-free, a metric cannot quietly read a file or call a model to inflate a score — it only ever receives typed data. Because the Harness owns effects but not meaning, a report or adapter can render a verdict but never decide one. The result is a single, auditable path from evidence to outcome, which is exactly what the Claim Boundary depends on.

Next steps