Choose a grounding gate

The Grounding gate decides how the Grounding check reads an answer against the reference_materials you send. It changes nothing else: safety, agent checks and scores work the same under either gate. Pick it by what your application produces.

What to set — find your application

Your application	Grounding gate	Send with each answer	Also turn on
RAG / question answering — a support bot, a knowledge-base assistant, search with an answer	Strict (default)	The retrieved passages as reference_materials	—
Document review — checking an invoice against a contract and an order, a clinical summary against lab reports, a filing against statements	Document review	Every document as its own reference_materials item, with a title (# INVOICE INV-2041)	is_aggregator=True on the final step of a multi-agent review
Coding agent — edits, refactors, fixes in a repository	No gate needed	Nothing for grounding	kind="tool_use", expected_tools, allowed_tools — the agent checks
Code-review agent — "list the bad practices, with file references"	Strict, if you send code	The files and tool outputs the agent read, as reference_materials	kind="tool_use", expected_tools, allowed_tools
Chat assistant without sources	No gate needed	Nothing for grounding	—

If you're not sure, keep Strict. It is the stricter of the two: nothing passes that the sources don't support.

What each gate does

	Strict (default)	Document review
The question it answers	Is every claim supported by the sources?	Is any claim proven wrong by the documents?
A claim the sources confirm	Pass	Pass
A claim not in the sources	Fail	Warning — lowers the score, doesn't fail
A claim proven wrong (wrong figure, wrong calculation)	Fail	Fail
A figure attributed to the wrong document ("the purchase order says $189" when only the invoice does)	Not checked — the figure is in the sources	Fail — each figure is read against the document the claim names
A figure computed from the documents ("a $560.00 overcharge")	Pass when it follows exactly from their figures	Pass when it follows exactly from their figures
Introductions and closing remarks	Not counted	Not counted
Conclusions and judgements ("Brightline should withhold the overcharge")	Counted — they must be supported	Not counted

Only a claim proven wrong counts as misinformation in Safety, under either gate. A claim that is not in the sources lowers the grounding score; it is not misinformation.

Three verdicts

Every claim gets one verdict, and each one tells you what to do:

Verdict	Meaning	What to do
Supported	The sources back it	Nothing
Not in the sources	Nothing in the sources backs it, and nothing proves it wrong. The claim shows the closest passage	Check retrieval (was the right document sent?) or tell the model to stay within the sources
Wrong	The sources say something different: a figure in no source, from another document, or a wrong calculation	Fix the prompt or the step that produced it

Both gates score grounding the same way: the share of claims that are supported. They differ in what fails the check: Strict fails on anything not supported; Document review fails only on Wrong and shows claims not in the sources as a warning.

Figures are compared by value, not spelling: "20th Feb, 2026", "February 20, 2026" and "2026/02/20" are one date, and "$3.1 million", "USD 3.1M" and "$3,100,000" are one amount. A date written without its year ("Feb 20") matches that day in any year the sources give. A rounded amount ("$1.3 million") must be in the sources; it is never accepted as computed from them.

The same claims under each gate

An invoice-review report, checked against an invoice, a purchase order and a supply agreement:

Claim	Strict	Document review
"The invoice bills toner at $189.00 per unit."	✓ Pass	✓ Pass — found in the invoice
"The purchase order prices toner at $189.00."	Not reliably caught — Strict checks that a figure is in the sources, not which document it belongs to	✗ Wrong document — the purchase order says $175.00
"The overcharge is $560.00."	✓ Pass — (189 − 175) × 40	✓ Pass — computed
"The invoice shortens the payment period."	✗ Fail if not confirmed word for word	◐ Not in the sources — lowers the score, doesn't fail
"Brightline should pay $11,920.00 by 17 April 2026."	✓ Pass — both figures follow from the documents	✓ Pass
"In the realm of commercial transactions, compliance is paramount."	Not counted	Not counted

The second row is the difference that matters: only Document review catches a figure taken from the wrong document. If your answers name documents for their figures, use Document review.

A support bot answering from retrieved help articles:

Claim	Strict	Document review
"Refunds take 5 business days." (the article says 5)	✓ Pass	✓ Pass
"Refunds are also available after 90 days." (the articles don't say so)	✗ Fail	◐ Not in the sources — lowers the score, doesn't fail

Here Strict is the right gate: an answer that goes beyond the articles is the failure you want to see.

Coding and code-review agents

A coding agent is judged by what it did, not by how its last message reads. Send kind="tool_use" with expected_tools (the minimal tools the task needs; names only match any arguments) and allowed_tools. The run is then scored on Execution, Efficiency and Safety, and checked for Tool correctness, Step efficiency, No loops and Within policy. No grounding gate is involved.

Step efficiency counts wasted calls, not calls. A call is wasted when it failed, repeats an earlier call exactly, or comes after the golden's last expected tool (for example a second finish). Mark a failed call with error in tools_called. The ADK plugin does this for you, and tool_calls_from_messages does it from LangGraph messages; a failure is never guessed from a tool's output text. Exploring is not waste: listing bash and finish in expected_tools says which tools the task needs, not how many calls.

It also measures the run against the calls the task should take. Set max_steps when you know the effort, and a run over it fails. Without it, the task's own history is the yardstick: once a task (the same final prompt in the experiment) has three earlier runs, the median of their calls is its usual. A run with twice or more its usual calls fails, so a refactor that usually takes 6 calls and now takes 12 is caught as a regression. Efficiency is the share of calls not wasted, scaled down when a run takes more than the expected calls.

For a code review, you can also check its findings against the code: send the files and tool outputs the agent read as reference_materials and keep Strict. Every finding must then be supported by code the agent saw. Don't use Document review for code: it treats a review's findings ("this module lacks input validation") as conclusions and leaves them out of the count.

Not checked yet for code reviews: whether a cited file, function or line exists, whether a judgement is right, and whether the review covered everything the task asked. These need the task's expectations, which are on the roadmap.

Switch the gate

1. Open the experiment's Overview tab and find Grounding gate.
2. Choose Strict or Document review. It works in Observe, and on A/B experiments while they are draft or paused.
3. The checks re-read every answer already in at once. Claims keep how they were scored, so send answers again to have them scored under the new gate's rules (for example, Document review's per-document figure reading).