Skip to main content
Grounding narrows the material a model draws from. It does not check that what came back is actually in that material. That gap is where most reported quality problems in RAG applications live. The endpoint retrieved good sources, the model was given them, and the answer still contained a quotation nobody said (a hallucination) or the title of a resource that does not exist. Retrieval is a platform responsibility. Confirming that a specific sentence is supported by a specific source, before a user reads it, belongs to your application. This guide covers the safeguards that close that gap:
  • a verification step between generation and display
  • a prompt contract that keeps the model inside the provided sources
  • multi-turn handling so the application corrects itself on first challenge
  • an evaluation suite that gives you numbers instead of impressions
New to checking answers against sources? Citations and Verification explains the ideas behind these safeguards in plain language, without code.
The patterns here apply to Grounded Completions, Grounded Responses, and any RAG pipeline you assemble yourself from the Search API. Nothing here is specific to a model, provider, or stack.

Shared Responsibility

Grounded endpoints handle retrieval and attribution. Everything downstream of the response body is application logic. The dividing line is consistent: the platform decides what content reaches the model, and your application decides what text reaches the user.

Failure Modes to Design Against

The examples below use Bezalel Ministries, the fictional organization from the Grounded Completions tutorial, whose five sample documents describe a digital art ministry, its research methodology, and its educational resources. Most of these are plausible, fluent, and adjacent to something true. Retrieval already succeeded, so it cannot catch them; only a comparison between the generated text and the retrieved text can. The ungrounded case is the exception. Retrieval returned nothing at all, the answer came entirely from model knowledge, and the only signal that anything is wrong is a boolean in the response body. It can be the most frequent failure of the set, and it is the cheapest to fix, which is why the checks below start there. How often it happens depends on your content and traffic: a narrow corpus fielding broad questions often returns no sources, while one that covers its question space well rarely does. Measure it against your own publisher rather than assuming a rate, and see Evaluate before you ship for how to count it.
A challenge fails in both directions. Conceding too slowly is the failure builders expect. Conceding too readily is at least as common and more damaging: a model that drops a correct, sourced answer under pushback teaches the user its citations mean nothing. Re-verifying against the sources retrieved for the original turn addresses both.Fabrications cluster around the highest-stakes content: named people, titled works, direct quotations, dates, and numbers. These are what users are most likely to repeat, cite, or act on, so verify them first.

Search, Generate, Verify

The common starting architecture is two steps: call the grounded endpoint, render the result. It has no place to catch the failures above.
Trust-the-model flow: query goes to generate, then straight to display, with no verification step in betweenTrust-the-model flow: query goes to generate, then straight to display, with no verification step in between
Add a third step. Hold the retrieved source text, generate, then check the answer against that text before the user sees it.
Search, generate, verify flow: query goes to retrieve, which keeps the source text, then generate, then check sources_returned. If false, decline plainly. If true, verify spans against the source text. On pass, display. On fail, widen retrieval and retry once; if it still fails, decline plainly.Search, generate, verify flow: query goes to retrieve, which keeps the source text, then generate, then check sources_returned. If false, decline plainly. If true, verify spans against the source text. On pass, display. On fail, widen retrieval and retry once; if it still fails, decline plainly.
You need the source text in hand to verify against. There are two ways to get it.

Option 1: Citations from the grounded endpoints

Set include_citations: true and read citations[].snippets. The endpoint keeps handling retrieval, routing, and tradition.
Simplest to adopt, and enough to verify quotations and titles. The tradeoff: snippets are excerpts, so a supported claim from a part of the document not returned in a snippet will not verify.

Option 2: Run retrieval yourself

Call the Search API directly, then pass the passages into a completion as context.
Each result carries properties.snippet with the passage text and properties.item_title with the source title. You hold the full retrieved text, so verification is exact and you control the prompt completely. The tradeoff is that you take on retrieval tuning, prompt assembly, and citation formatting yourself. Start with option 1. Move to option 2 when verification precision matters more than integration cost, or when you need the retrieved text for anything beyond checking the answer.

Verification Checks

Run these against the retrieved text after generation and before display, in the order given. The order matters: the grounding check is a precondition for the other two.

Check the grounding flag first

Both grounded surfaces report whether retrieval contributed anything: sources_returned in the response body, X-Sources-Returned when streaming. Grounding never fails a request, so a false here still returns a fluent, complete, ungrounded answer. Never treat sources_returned: false as a normal answer. Either label the response as not drawn from your content, or decline. See When no sources are found. Check this before the containment checks below. With no source text to compare against, every quotation and title fails containment automatically, so one ungrounded answer shows up as many “unverified” spans and corrupts both your decision logic and the metrics in Evaluate before you ship.

Check quoted spans

Any text the answer presents as a quotation must appear in a retrieved source. Pair each opening mark with a closing mark of the same kind (straight with straight, curly with curly), and apply the minimum length after pairing, so a short quote, or one nested inside another, can’t make the wrong marks pair up. Spans shorter than 12 characters, such as a single quoted word, are too short to check meaningfully and are skipped, as is text after a quotation mark that has no partner. Normalize before comparing: collapse whitespace, fold curly quotes to straight, and strip ellipses so a shortened quote still matches.
Against the Bezalel sources, a genuine quotation such as “We never claim more certainty than the evidence warrants” verifies, because that sentence appears verbatim in the research methodology document. A fabricated line attributed to Dr. Thornwell does not, because the documents describe him without ever quoting him. A quote also fails when its parts are real but come from different documents. Check each source separately rather than searching them concatenated, or a sentence stitched from two unrelated documents will verify, which is the fabrication this check exists to catch. Note the granularity you pass in: a list of citation snippets treats each snippet as a source, so a quote spanning two snippets of the same document is flagged. That errs toward a paraphrase or a decline, which is the safe direction here. On failure, pick one:

Check named artifacts

Apply the same containment rule to titles of works, article names, episode names, course names, and product names. This is the check that stops “The Mercy Seat Revealed” from being presented next to a real series name, where its plausibility does the damage. Treat any title the model produces as unverified until it is found in a source. Do not assume a title is safe because the surrounding series or author is real. Apply the same normalization too, and in particular strip punctuation from the edges of the candidate before comparing. Models routinely place the sentence’s closing punctuation inside the quotation marks, so the raw candidate is The Tabernacle and Christ. while the source reads The Tabernacle and Christ, and a correct answer naming a real course fails containment over one period. The same happens with a trailing comma in "Phase Two," the test commission. Skip this and expect false positives on real titles, the failures most likely to erode trust in the check itself.
Containment cannot tell an assertion from a denial. An answer that correctly says the series does not have an episode titled “The Mercy Seat” still puts that title in quotation marks, and the check still flags it.The prompt contract’s rule against putting quotation marks around wording not found in a source keeps these false positives rare. The contract and the verifier work together: the contract shapes the output into something the verifier can judge accurately.

Escalate before declining

A failed check does not always mean the answer is wrong. Sometimes retrieval was too narrow.
  1. Widen retrieval. Raise sources_limit, or lower certainty_threshold on Grounded Responses and certainty on the Search API.
  2. Regenerate once with the broader source set.
  3. If verification still fails, decline plainly.
One retry, not a loop. A model that could not support a claim from five sources rarely supports it from ten, and each attempt adds latency the user waits through. sources_limit accepts 1 to 10, so going from 5 to 10 is the whole of the headroom anyway.

Verify Before You Stream

Streaming publishes each token as it is produced. An unverified quotation is on the user’s screen before any check can run, and retracting it afterward is a worse experience than a slightly slower first token. For anything a user might repeat or act on, buffer. The latency cost is real but bounded, and it is the only approach where nothing unverified is ever displayed.
Streaming has a second failure surface: the stream itself can break mid-answer. Recovery interacts with verification, because a continuation is a fresh generation that also needs checking. See Handling Streaming Failures.

The Prompt Contract

These instructions measurably change behavior. They are rules to encode, not a prompt to copy. Answer only from the provided sources. State that model knowledge outside the sources must not be used, even when it is correct. Without this, the model blends training knowledge with retrieved content and the blend is invisible in the output. Label paraphrase distinctly from quotation. Require quotation marks for verbatim text and explicit framing for paraphrase. This makes your verifier’s job possible: it can only check spans the model marked as quotations. Decline first on attribution and fact-check questions. For “what did X say about Y” or “which resource covers Z,” instruct the model to state up front when it cannot verify something from the sources, rather than assembling a best guess. Declining is the correct answer more often than it feels like it should be. Correct false premises before answering. When a question presupposes something the sources contradict or never establish, the correction comes first. Answering around a false premise implicitly confirms it. Refuse to speak as a real person. No role-play, no “answer as X would,” no first-person voice for a named individual. Offer that person’s sourced material instead.
Prompt instructions are best-effort. They shift behavior substantially but still fail under adversarial phrasing, long conversations, and unusual topics. The prompt reduces how often verification has to catch something; it doesn’t remove the need for it.

Multi-Turn Conversations

Single-turn correctness does not survive into a conversation on its own. Re-check on challenge. When a user pushes back with “are you sure?” or “that doesn’t sound right,” re-run verification for the challenged answer against the sources retrieved for that original turn. Correct on the first challenge if the answer does not hold, and hold it if it does. A model that concedes only after repeated pressure, or abandons a verified answer the instant a user objects, is responding to social pressure rather than to the sources.
Do not let the challenge turn drive retrieval. This is an easy way to break the pattern above while appearing to follow it.Retrieval keys on the latest user message, and “Are you sure? I read something different” contains nothing to retrieve on. Send it as-is and retrieval comes back empty, sources_returned is false, and your grounding check discards a correctly verified answer and declines. The safeguard destroys a good answer on the first pushback, which is worse than the behavior it was added to prevent.Either reuse the sources you already stored for the original turn, or carry the original question’s terms into the challenge turn so retrieval has something to work with:
This is also why the next point is not optional bookkeeping.
Keep retrieved sources addressable across turns. Store the sources retrieved for each turn, keyed to that turn. Follow-ups like “which source says that?” already have an answer in hand and shouldn’t trigger a fresh search that returns different sources than the ones the answer came from. Cap conversation length. Set an explicit limit on turns or total characters and trim from the oldest turns. Unbounded history eventually exceeds request limits, which surfaces as request validation errors that appear only in long conversations and look unrelated to their cause. Account for your own long turns. Verified answers with quotations and citations are longer than typical assistant messages. History trimmed by turn count alone can still exceed limits when your replies are large, so trim by size as well.

Putting It Together

The verification step sits between generation and display, with one escalation and a plain decline as the floor. unverified_titles / unverifiedTitles applies the containment rule from Check named artifacts to titles extracted from the answer.
Show unverified answers with their sources, but without saying the quotations were checked: one was too short to check, or had no closing mark. Surface unsupported and ungrounded as plain statements that the answer could not be confirmed from your content. An honest decline costs one interaction. A fabricated quotation that a user repeats elsewhere costs considerably more.

Evaluate Before You Ship

Verification tells you whether one answer holds up. Evaluation tells you whether your application does. For the ideas behind measuring answer quality, see Evaluating RAG quality and Metrics and Evaluation. Build a scenario suite covering each category below. A few dozen scenarios is enough to be useful; the categories matter more than the count. Then automate the scoring. Two metrics carry most of the value, both objective and neither needing human grading: Report them separately, and exclude ungrounded answers from the second count. Every span in an ungrounded answer fails containment, so folding the two together inflates your fabrication count and sends you optimizing a number that isn’t measuring what you think. Don’t assume which one will dominate. Builders tend to worry most about invented quotations, the failure that gets reported and does the most damage per occurrence. Check whether confident answers to questions your content never covered are the more frequent problem for you, because the two call for different work: closing the ungrounded gap is mostly a decline path and a content-coverage question, while fabricated spans need the verifier. Which one leads is a property of your corpus and your users, not of grounded completions. In one measured run against a small five-document publisher, answers displayed while ungrounded outnumbered answers containing an unverified span by roughly four to one. That is one corpus and a small sample: treat it as an illustration of why you should measure, not as a number to expect. Run both before and after every prompt or retrieval change so you have numbers rather than impressions. Finally, turn every reported failure into a permanent test case. When a user reports a bad answer, add that exact conversation to the suite before fixing it. This is what stops the same class of failure from returning three releases later.

When Grounding Looks Wrong

Most “the answer ignored my content” reports come down to retrieval finding nothing useful, not to the model. Check these before changing your prompt.

No sources returned

The response reports sources_returned: false, or the answer reads like general knowledge.
  • Confirm the content is uploaded to the right publisher. Publisher names are case-sensitive (“MyPublisher” ≠ “mypublisher”), so check the exact name in Gloo AI Studio against your code and .env file.
  • Confirm the content is indexed. In Studio, open your publisher and check that documents show “Completed” status (not “Pending”). Wait 5-10 minutes after upload before testing.
  • Ask questions your documents can answer. A query can miss your content entirely: asking “What is the pricing?” when you only uploaded a user guide returns nothing to ground on.
  • Widen retrieval. sources_limit defaults to 3 and accepts 1 to 10; try 5-10 for complex queries. More sources give broader coverage, at the cost of a larger prompt. On Grounded Responses you can also lower certainty_threshold. See Escalate before declining.

Answers seem generic

  • Check sources_returned first. If it is false, work through the list above.
  • Use more specific queries that match the language of your content.
  • Review the content in Studio to confirm it covers the question and is indexed.

Content quality limits retrieval

Retrieval can only find what the indexed text contains:
  • Scanned PDFs may have poor OCR.
  • Very short documents (under 100 words) may not be retrieved.
  • Highly technical jargon may need more context around it.
For how to prepare content before upload, see Preparing Content for Ingestion.

Summary

Next steps

Grounded Completions

RAG on the chat-completions shape, with routing, citations, and sources_returned.

Grounded Responses

The same grounding on the Responses API, with certainty_threshold.

Search API

Standalone retrieval when you want to hold the source text yourself.

Handling Streaming Failures

Retry, continuation, and partial-output UX for interrupted streams.