EvalGlass
← Trust

Our covenant

We won't manufacture trust. Not in a result, not on this page.

EvalGlass exists to give you one honest, narrow signal: a green run claims only what it actually checked. That rule binds this website too. If we'd refuse to let a scorecard overstate a run, we won't let our marketing overstate the project — and where a promise can be a build gate, we've made it one.

The rule, extended to ourselves

No false confidence is what the product is built around. A green or non-failing result never implies more evidence, authority, calibration, comparability, or safety than the run earned — a pass is a bounded, auditable claim, not a verdict on whether your output is correct.

We hold the site to the same standard. It states the full product vision, and the four-state badge shows exactly how far the code has actually reached — vision-forward, never false-confident. A capability marked next or experimental is built in the framework but not yet in the version the plugin installs, and nothing marked so is ever shown running as if it shipped. We will not manufacture product maturity any more than Core manufactures a green result. The ahead-of-code register keeps that promise auditable.

Where each product stands

The honest availability picture, stated plainly — the same discipline we apply to a run's verdict, applied to the products themselves. Each badge is the offer axis, separate from the capability maturity of what's inside.

See the three products → · Capability roadmap →

The verb we don't ship

The strongest honesty signal isn't a sentence on this page — it's a command that doesn't exist.

You operate EvalGlass through your coding agent with a small verb surface — /evalglass setup, connect, run, view, explain, compare, baseline, ci. There is deliberately no gate, approve, certify, pass, verify or validate verb — and that absence is the identity, not an omission. The plugin is a typist and a reader, never a participant: it asks, the host validates, and a single Verdict Engine decides. So a fresh run is informational, never "passing"; activating a gate is a host YAML edit you own. A tool that could quietly make its own result pass would be exactly the false confidence EvalGlass refuses — so that verb is not written, and CI keeps it that way. check-agent-verbs Where the claim stops →

What we refuse — and how it's enforced

The product refuses false confidence with a mechanical deny-list that fails the build if a fabricated trust signal slips in. We hold our marketing to the same bar. Where a refusal can be a build gate, it is — and we name the gate. Where it's still only our word, we say so, rather than imply an enforcement we don't have.

check-name the build fails if we break it  ·  our word a promise, not yet a gate

Dated, and yours to audit

A commitment you can't audit over time isn't a commitment. Every change to this page is a public git commit, so its history is dated and inspectable — you can see when it last changed and judge whether the rest of the site kept up. The date below is checked against the page's own git-derived metadata in CI, so it can't silently rot.

Last substantive change: · how we work →

And if any claim on this site overstates reality — a feature shown as shipped that isn't, a signal the project hasn't earned — open an issue. We treat an overclaim on the website as the same class of bug as an overclaim in a scorecard.

This page only earns trust if the whole site obeys it.

A charter is just more prose unless every other page holds to it. So the test isn't whether this page sounds honest — it's whether you can find a single claim across the site that the project hasn't actually earned. If you can, that's the bug. Tell us.

Related

Trust model
the six structural promises that keep an evaluation honest
What a green result does not mean
the exact boundary of a passing run
Governance
how the project is run and how to take part