Grounding

AI grounding ties each material claim in a generated answer to evidence a person or system can inspect. Finding a document is not enough. The cited passage must support the claim, come from the right record, and be available to the right user. Google Cloud scores support from 0 to 1 and treats a partly supported claim as ungrounded. A June 2024 study found unsupported sentences across three datasets and four model families, including answers that contained the correct result. Google DeepMind’s benchmark uses 1,719 examples and documents up to 32,000 tokens. For a service firm, grounding means using the current record, checking the exact evidence for this client and task, keeping permissions intact, and stopping when the evidence is missing or conflicts.

What is the difference between grounding and RAG?

Retrieval-augmented generation, or RAG, brings outside information into the model’s current request. Grounding asks whether the finished answer stays supported by that information.

Retrieval can work while the answer still fails. A search may find the right contract clause. The model can then add a 30-day notice rule that the clause never says. The system used RAG. The extra rule is ungrounded.

Google Cloud calls RAG one common grounding technique. It also lists web search, maps, managed RAG, Elasticsearch, custom search APIs, and other web indexes. The source can change. The question stays the same: can each material claim be traced to evidence that supports it?

Fine-tuning solves another problem. It teaches a model patterns for a task, such as a format or tone. It does not fetch today’s signed scope or show which sentence supports a price. Context engineering chooses the instructions, records, tools, and history in the request. Grounding checks whether the evidence in that context survives into the answer.

What does a grounded answer look like in service delivery?

Start with a client change request. The coordinator asks whether the work is included in the current agreement. A grounded system fetches the signed scope and approved changes for that client, identifies the controlling clause, and cites the version it used. If two approved records conflict, the system says so and routes the decision.

An old proposal in a shared drive is the counterexample. Its wording may match the question, so retrieval may return it. The model may quote it accurately. The signed agreement still owns the current scope.

Source authority comes first. Contract scope belongs to the signed agreement and approved changes. Current account status belongs to the live client record. A service standard belongs to the approved operating procedure. A public search result may be right for a law or product release. It is a poor source for a promise made to one client.

The source needs a date, owner, and permission rule too. Without them, AI can repeat stale information cleanly. AWS says in its grounding and RAG guidance that a grounded response is only as reliable as the document, database, or API behind it. AWS also calls for source checks, traceability, and access control.

Why is a citation not enough?

A citation makes a claim inspectable. It does not show that the passage supports every part of the sentence.

Google Cloud’s grounding check gives a clear example: “Google was founded by Larry Page and Sergey Brin in 1975.” The founders are right. The year is wrong. Because the evidence supports only part of the sentence, Google treats the whole claim as ungrounded.

The API returns an overall support score from 0 to 1. It can also score each claim and return the text chunks linked to it. The useful unit for review is the claim beside its evidence. A vendor’s score is less important than having that pair to inspect.

Retrieval checks cannot end the process. A June 2024 NAACL Findings study tested retrieved answers across three datasets and four model families. It found ungrounded sentences, including inside responses that contained the correct answer. A correct conclusion can sit next to an unsupported reason, date, exception, or recommendation.

Google DeepMind’s FACTS Grounding benchmark contains 1,719 examples with source documents up to 32,000 tokens. It asks for both a useful answer and traceable support. A vague refusal can avoid a false claim without doing the work, so usefulness and support need separate checks.

What else can fail in a grounded answer?

Claim support is one check. The rest of the evidence path still needs an owner.

Check	Question	Failure it catches
Source authority	Is this the record that owns the fact?	An old proposal outranks the signed agreement
Retrieval	Did the system fetch the right passage and version?	The current rule never reaches the model
Claim support	Does the evidence support the whole material claim?	A correct clause gets an invented exception
Relevance and permission	Does this evidence answer this user’s question, and may they see it?	Another client’s record supports the answer
Refusal	Does the workflow stop when evidence is missing or conflicts?	The model fills the gap with plausible prose

Support and relevance are different. An answer may quote a true fact about the wrong client. Permission is different again. Evidence from a forbidden record can be accurate and still create a security failure.

Date and completeness matter. A January policy can support the exact words written in August and still be out of date. One clause can be accurate while an approved amendment changes the result. Grounding makes the trail visible. The firm still decides which record controls.

NIST’s July 2024 Generative AI Profile recommends checking retrieval-data provenance and groundedness, reviewing generated sources and citations during testing and monitoring, and reassessing risk after retrieval or fine-tuning changes. Add a new knowledge source and you have a new system state to test.

How should a service firm test grounding?

Pick one delivery decision with a clear source of truth. A change-order question, refund decision, proposal price, or compliance statement is easier to test than a broad company chatbot.

Collect five real cases. Include a normal case, an old source beside a current one, two conflicting sources, a missing record, and a record the test user cannot access. For each case, write the expected source, the material claims the answer may make, and the point where it must refuse or ask for approval.

Test the chain in two parts. First, inspect retrieval. Confirm the client, version, date, and permission. Second, compare each material claim with the retrieved passages. This shows whether the system missed the source or the answer went beyond it.

Save the cases as an eval. Run them when a source, index, prompt, model, tool, or workflow changes. Log the question, passages, source versions, answer, support result, and final human decision. A score without that record is hard to diagnose when the same failure returns.

The process owner decides which record is authoritative and when it changes. The implementation owner keeps access rules, retrieval logs, and tests. The reviewer owns the approval point for claims whose consequences cannot be cheaply reversed. A model setting cannot assign these duties.

Where does grounding sit on the Delivery Model Ladder?

Grounding belongs mainly at Stage 2, Augmented, on the Delivery Model Ladder. The workflow retrieves approved evidence, keeps the citations, checks support, and sends exceptions to a named person. The evidence path becomes part of delivery.

At Stage 1, Enhanced, a person may open the right contract, paste it into chat, and check the answer by hand. That can improve individual work. The source choice and review method still live in the person’s head.

At Stage 3, AI-native, the system can fetch current records, apply the user’s permissions, score claim support, and route weak evidence without waiting for a person to assemble the packet. More of the chain runs automatically. Source ownership and testing remain human responsibilities.

That checking work sits inside the Production Gap. Output can arrive in seconds while people spend the recovered time tracing claims, finding newer records, and fixing answers that used the wrong source. Grounding reduces that work only when evidence and checking travel with the deliverable.

When is grounding not enough?

Grounding stops at the source boundary. A bad source stays bad. Missing clauses, conflicting policies, and forbidden documents still need an owner. A supported answer can also require judgment about whether it is wise, fair, or safe to act on.

Before one real workflow moves, ask five questions: Which record owns the fact? Which passage did the system retrieve? Does it support the whole claim? Could this user receive it? What happens when evidence is missing or conflicts? If one answer is unclear, keep a person in the decision.