Skip to main content
Glama

Open Grounded AI Testing & Evaluation

Deterministic, gold-anchored verification for evidence-grounded AI — no LLM judge.

CI npm npm downloads PyPI Docker Docker pulls node License: MIT PRs welcome

Quick start · Architecture · Surfaces · Examples · Roadmap · Contributing · Changelog


Evidence over plausibility. OpenGATE verifies AI systems that must justify every answer from source material — RAG pipelines, document-QA tools, legal and scientific assistants. It answers one question above all: can the system prove its answer from the evidence it was given?

The check is deterministic — no LLM-as-judge, no grader model, no six-point verdict scale. Required facts must be present, every number must trace back to the source, and when the context can't answer, the system must abstain rather than fabricate. Because it's pure logic, it's reproducible, free, and fast enough to run on every answer or gate on every commit.

As AI moves into high-stakes domains, evaluation is becoming as fundamental as automated testing is in traditional software. OpenGATE turns grounding failures into numbers you can track, and gates every prompt, model, or workflow change against a baseline — so reliability can't quietly regress.

Quick start (60 seconds)

No API key needed — the offline suite runs deterministic scorers against the bundled gold set:

npx @pharmatools/opengate           # run the offline evaluation suite
npx @pharmatools/opengate init      # scaffold gold cases + HTTP config + a GitHub Action
OpenGATE — 39 case(s), online=false, adapter=refcheckr

  ✓ citation-detection   PASS
      perClaim_exactSetRate      100.0%
      perClaim_jaccardMean       100.0%
      supportedStyle_accuracy    100.0%
  ⊘ grounding            SKIPPED — online scorer (pass --online)

Point opengate.http.json at your endpoint and add --online --ci to gate your own system. Full walkthrough: Getting Started.

Related MCP server: Cheap Research

One check, many surfaces

The same deterministic grounding logic ships wherever your stack lives:

Surface

Install

Use it for

CLI + framework

npx @pharmatools/opengate

Full eval suite, adapters, regression gate

GitHub Action

uses: nickjlamb/opengate@v0

Drop-in CI gate in any repo

Python package

pip install opengate-grounding

check_grounding(), pytest gate, DeepEval metric

MCP server

npx @pharmatools/opengate-mcp

Agents that verify their own answers inline

Docker image

docker run pharmatools/opengate

CPU-only, containerised pipelines

Architecture

Scorers never talk to a system directly — they reach it through a small adapter, so the methodology travels and only the gold set changes. In the development loop it sits where CI sits: change a prompt, model, or pipeline; the regression gate diffs the new scorecard against the baseline — improved or held deploys, regressed fails the build.

Why not DeepEval?

Use both — evals measure, OpenGATE verifies. General-purpose frameworks like DeepEval and OpenAI Evals evaluate AI systems broadly, usually with an LLM judging the output. OpenGATE verifies the narrower, harder promise: that every answer is grounded in evidence:

  • Provenance is first-class — does the cited passage actually exist, verbatim, in the source?

  • No LLM judge — scores are deterministic checks against hand-labelled gold, so they're reproducible and free to run in CI; your judgment lives in the gold set, not a grader model's.

  • Regression detection is first-class — every run is diffed against a per-adapter baseline; a drop fails the build.

Pair a general framework for broad quality metrics with OpenGATE to gate the grounding.

Core concepts

Gold cases — hand-labelled benchmark cases (datasets/cases/): source text, the claims that should be extracted, the sentences that should not be, and reference snippets with known-correct verdicts. Copy _template.json to add one; format in datasets/SCHEMA.md, labelling rules in datasets/LABELING-GUIDE.md.

Scorers — one module per metric family (src/scorers/):

Scorer

Mode

Measures

citation-detection

offline

per-claim citation set exact-match & Jaccard; supported-style accuracy

claim-extraction

online

precision / recall / F1 vs gold; non-claim leakage; fidelity (claim is verbatim from source)

verdict-accuracy

online

exact & adjacency accuracy on a six-point scale; passage hallucination rate; consistency; latency & token cost

redaction

online

recall on gold identifiers with leaks as named failures; over-redaction; known-gap tracking

simplification

online

faithfulness of rewrites: anchor recall (critical facts survive), fabricated numbers, length gates

retrieval

online

fidelity of retrieved records vs the authority: anchor fields + structural invariants

grounding

online

generic RAG: answer-anchor recall, fabrication vs context, and abstention. The turnkey path

Offline scorers run with no API key — fast enough for every commit. Online scorers exercise a live system through an adapter.

Scorecards — every run writes results/<timestamp>.json stamped with the git SHA, so any result is reproducible and auditable. Per-model runs carry a run_model label, turning the results directory into a measured comparison (accuracy × hallucination × latency × cost).

Regression gate — --baseline saves a reference; later runs print per-metric deltas (▲/▼ in percentage points) and --ci fails the build on any drop. Baselines are per-adapter, so one system's scorecard can't clobber another's.

HTML report — add --report (or opengate report) for a self-contained dashboard: pass/fail per scorer, deltas vs baseline, every named failure. One file, no server, no dependencies.

Evaluating your own system

An adapter is one file: two base exports — onlineAvailable(), onlineConfigHint() — plus at least one complete capability (e.g. grounding → answer()). Scorers check adapter.capabilities and skip cleanly across the boundary; adapters are validated at load with messages naming every missing export.

OPENGATE_ADAPTER=./adapters/my-system.mjs npm run eval:online

For REST-backed systems there's a no-code path: the bundled generic HTTP adapter reads endpoint paths and headers from opengate.http.json (${ENV} interpolation, built-in latency/token capture). Full contract and a minimal skeleton: ADAPTERS.md.

Examples

  • Evaluating a NIM-powered RAG agent — builds a RAG agent on an NVIDIA NIM model and gates its answers' grounding with OpenGATE, deterministically and with no LLM judge. Includes a runnable Python notebook (opengate-grounding) and a Node adapter for the CI gate.

Proven in production

Four PharmaTools products run on OpenGATE in CI — four different capability shapes, one evaluation standard. Run against RefCheckr's gold set, OpenGATE:

  • surfaced a silent parse-failure mode affecting ~50% of multi-claim verdicts, eliminated with enforced structured output (→ 0);

  • halved passage hallucination (5.8% → 2.4%) by driving a measured production model change — a decision made on numbers, not reputation;

  • holds claim extraction at 0.91 F1 with 0.93 recall on the committed baseline (run-to-run spread 0.86–0.94 — the splitter is an LLM), and is currently failing its own gate: 2 known non-claims leak into extraction on most runs, an open splitter issue the gate reports rather than rounds away.

Redacta wraps the @pharmatools/redacta engine, scored against synthetic UK clinical notes with gold-labelled identifiers. On its first run the eval found two real engine bugs (relation phrases swallowing nested names; apostrophe surnames dropped) — both fixed and confirmed (knownGap_closed: 2), then promoted to gold. Current scorecard: 100% recall on 25 gold identifiers, 0 leaks, no open gaps.

npm install --no-save @pharmatools/redacta
node src/runner.mjs --online --adapter ./src/adapters/redacta.mjs

Patiently AI exercises faithfulness scoring for text that is paraphrase by design. The eval caught the simplifier dropping safety-critical specifics — an antibiotic dose vanished from a discharge summary (anchor recall 86%). A preservation rule took the next run to 100% anchor recall, 0 dropped facts, 0 fabricated numbers — a per-run measurement, not a guarantee: one frozen exp-2 capture made six days after the fix still contains a correct-but-unsourced reference range, flagged by design (RESULTS.md §6). That tail is why the eval now gates Patiently's backend in CI and re-scores the live service weekly, with fabrications failing on first occurrence.

node src/runner.mjs --online --adapter ./src/adapters/patiently.mjs

PubCrawl has no model — it exercises retrieval fidelity against hand-verified anchors and structural invariants, catching parser regressions (collapsed author arrays, [object Object] leakage) that would poison every downstream citation. That OpenGATE scores a non-AI system at all is the point: evidence-grounded AI is only as trustworthy as the retrieval beneath it.

node src/runner.mjs --online --adapter ./src/adapters/pubcrawl.mjs

Full methodology and model comparison: how RefCheckr is evaluated.

Project layout

opengate/
├── src/
│   ├── lib/          metrics + shared grounding core (single source of truth)
│   ├── scorers/      one file per metric family (7 scorers)
│   ├── adapters/     system-under-test boundary (refcheckr.mjs is the reference)
│   └── runner.mjs    CLI: discover cases → score → report → snapshot → gate
├── datasets/         gold-labelled cases (39) + fixtures + schema
├── examples/         worked examples (NVIDIA NIM RAG)
├── mcp/              MCP server (@pharmatools/opengate-mcp)
├── python/           opengate-grounding (PyPI) + DeepEval metric
├── Dockerfile        CPU-only image (pharmatools/opengate)
└── action.yml        GitHub Action

Documentation

Doc

What's in it

Getting Started

Zero to a CI gate for a generic RAG system

ADAPTERS.md

The adapter contract + a minimal skeleton

datasets/SCHEMA.md

Gold-case format

Roadmap

What's next, and the road to 1.0

Contributing

Dev setup, adding cases/adapters/scorers, PR flow

Changelog

Release history

Contributing

Contributions are welcome — especially gold cases (new domains, citation styles), adapters (connect your system), and scorers (new metric families). See CONTRIBUTING.md — including its support & governance expectations and AI-assisted development disclosure; open an issue to discuss large changes. Interfaces may still shift pre-1.0, and semver will signal breaking changes.

Citing OpenGATE

If you use OpenGATE in research, please cite it — citation metadata is in CITATION.cff (GitHub's "Cite this repository" button uses it).

License

MIT — because evaluation frameworks shouldn't be black boxes. If an evaluation influences deployment decisions, engineers should be able to inspect every scorer, metric, and benchmark.

Available Tools

1 tool
check_groundingA
Read-only

Check whether an answer is grounded in the provided context. Deterministic (no LLM judge): verifies that required facts appear in the answer, that every number in the answer traces to the context, and — for questions the context cannot answer — that the answer abstains instead of fabricating. Use this to self-check RAG / document-QA / retrieval answers before returning them.

ParametersJSON Schema
NameRequiredDescriptionDefault
answerYesThe answer to check.
contextYesThe retrieved context the answer must be grounded in (a string, or an array of passages).
questionNoThe original question (optional; lets numbers from the question count as grounded).
must_abstainNoSet true when the context does NOT contain the answer: the answer must then decline rather than fabricate.
expected_factsNoFacts a correct answer must contain (e.g. "30 days", "no restocking fee"). Each must appear in the answer.
allowed_new_numbersNoNumbers the answer may introduce that are not in the context (e.g. from the question).

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description adds substantial behavioral detail: the tool is deterministic rather than LLM-based, verifies required facts, requires every number to trace to the context, and abstains on unanswerable questions. This gives the agent a precise model of the tool's internal behavior without contradicting the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The entire description is two sentences with no filler. The core purpose is front-loaded in the first clause, the key differentiator ('Deterministic (no LLM judge)') appears early, and the use-case directive closes the description. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter verification tool with no output schema, the description covers the core decision logic and the intended invocation context. The only notable gap is that it doesn't describe the return value or result shape, but the tool name and 'check whether' phrasing make the boolean verdict reasonably inferable. Overall, the agent has enough to invoke and interpret behavior correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each parameter already documented (answer, context, question, must_abstain, expected_facts, allowed_new_numbers). The description adds general grounding semantics, such as 'required facts appear in the answer' and 'every number in the answer traces to the context,' but it does not add per-parameter meaning beyond the schema. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Check whether an answer is grounded in the provided context.' It goes further to distinguish the tool from a generic judge by explicitly saying 'Deterministic (no LLM judge)' and enumerating the exact checks performed (required facts, numeric traceability, abstention). Even with no sibling tools, an agent knows exactly what this tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear usage directive: 'Use this to self-check RAG / document-QA / retrieval answers before returning them.' This states when to use the tool explicitly. There are no excluding conditions or alternatives to compare against, but the deterministic note and concrete use cases provide clear context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.1
    • First observedcheck_grounding

TDQS

A4.4/5.0

Scored across 1 tool

Disambiguation5/5

There is only one tool, so there is no possibility of confusing it with another tool. Its purpose—deterministically checking answer grounding—is clearly distinct and described in detail.

Naming Consistency5/5

The single tool name uses a clean verb_noun structure (check_grounding) and matches the server's purpose. With only one tool, there are no inconsistent conventions to create confusion.

Tool Count3/5

At one tool, the surface is at the absolute minimum and feels thin compared to typical MCP servers. However, the tool is non-trivial and the server appears intentionally focused on a single grounding-check task, making it borderline rather than egregious.

Completeness4/5

For its stated purpose, the tool covers the major grounding requirements: required facts, numeric traceability, and abstention on unanswerable questions. It lacks related conveniences such as batch checking or detailed failure explanations, but no critical operation for the core workflow is missing.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    Not graded
    maintenance
    A bounded evidence review engine that ingests documents, extracts evidence for a given claim, detects contradictions, and produces auditable evidence packets without hallucinations or open-web research.
    -
  • A
    license
    A
    quality
    B
    maintenance
    MCP server for verifying AI agent claims vs reality — single-transcript inline grounding-check that flags when an agent's response states facts not in the input context, when its code silently swallows exceptions and substitutes mock data, or when its multi-turn transcript contains contradictions or unverified completion claims. Sub-second, local, free, no API calls.
    4
    23 PyPI
    1
    MIT