OurSharedCode › Prompt Engineering Studio › Guides
A model once handed me a summary of a contract that cited clause 14.3. Clause 14.3 did not exist. The document stopped at clause 11, and everything around the citation was accurate — which is what made it dangerous. A wrong answer that looks wrong gets caught. A wrong answer shaped exactly like a right one goes into the report.
Grounding is the standard fix: restrict the model to material you supply and forbid it from drawing on anything else. The idea is right. The one-line version of it that everyone writes first is not enough, and it took me several of these near-misses to work out why.
What almost everyone writes
Use ONLY the information provided below. Do not use outside
knowledge.Four things leak through that. Here they are in the order they cost me the most.
"Below" is doing a lot of work in that sentence. If you paste a document straight after your instructions, the boundary between your words and the source is a blank line, which is not much of a wall. Ask a question at the end and now there is text on both sides with nothing marking which is which.
Delimit the source explicitly and then refer to it by that name for the rest of the prompt:
<source>
{{ the document, pasted verbatim }}
</source>
Answer using only the text inside <source>. Anything not stated
there does not exist for the purposes of this task.
Tags, fences, rows of dashes — the specific marker matters much less than
having one and using its name afterwards. "Only the text inside
<source>" is a checkable instruction in a way that
"the information provided below" is not.
This also blunts the obvious injection: a document that contains the sentence "ignore previous instructions" is now inside a region you have described as data. That is a mitigation and not a fix — if the source is hostile you need more than a prompt — but an undelimited paste has no defence at all.
This is the same failure I wrote about in why your system prompt gets ignored, wearing different clothes. "Use only the source" plus "answer the user's question" is a contradiction the moment the source does not contain the answer. Something has to give, and what gives is the first instruction, because the second one is the visible job.
Grounding needs an escape hatch or it is just a suggestion:
If <source> does not contain the answer, reply exactly:
NOT IN SOURCE
Do not guess, and do not fill the gap from general knowledge.
Answering "NOT IN SOURCE" is a correct and expected outcome, not
a failure.The last sentence is not padding. Without something like it, refusing still reads as under-performing, and a model that has been asked to be helpful will reach for the plausible answer. Give it a defined, blessed way out and the rate of invented clause numbers drops sharply.
Use a fixed literal string rather than free prose for the refusal. "Say
you don't know" produces twelve different phrasings, none of which your
code can match on. NOT IN SOURCE is one string you can test
for.
"Summarise this incident report and recommend next steps" is two jobs. The summary should come entirely from the source. The recommendations cannot — that is the model's judgement, by definition. Ask for both under one grounding instruction and you have told the model to do something impossible, so it quietly relaxes the rule for the whole answer, including the part where you needed it.
Separate them and label them:
Produce two sections.
FROM THE SOURCE — only facts stated in <source>. No inference.
MY READING — your own assessment. Mark it clearly as
interpretation. It may go beyond the source; it may not
contradict it.Now the reader can see which half is which, and so can the model. This one change fixed more of my hallucination problems than any amount of sterner wording, because most of my prompts had this shape and I hadn't noticed.
Even confined to a source, a model restates things, and each restatement is a chance for a number to shift or a hedge to disappear. "Costs rose in several regions" becomes "costs rose sharply across the business" — no invention exactly, just a summary walking away from the text.
Make it show its working:
For each claim you make, quote the sentence from <source> it
comes from, verbatim and in quotation marks. If you cannot quote
a sentence that supports a claim, delete the claim.This costs output length and it is worth it. Quotes are checkable by eye in seconds, and checkable in code with a substring test — if the quoted sentence does not literally appear in the source, you have caught the failure automatically. That is the single strongest thing in this article: it converts trust into a test.
You are a careful analyst. Accuracy matters more than
completeness here.
<source>
{{ document }}
</source>
Answer the user's question using only the text inside <source>.
- Quote the sentence supporting each claim, verbatim.
- If a claim cannot be quoted, delete it.
- If <source> does not answer the question, reply exactly:
NOT IN SOURCE
- Answering NOT IN SOURCE is a correct outcome, not a failure.
- Do not use general knowledge, even where you are confident
it is right.It does not make your source true. A model faithfully summarising an out-of-date policy produces a confident, well-cited wrong answer, and every technique above will have worked perfectly.
It does not fix retrieval. If your pipeline fetched the wrong three paragraphs, grounding restricts the model to the wrong three paragraphs. Most "hallucinations" I have investigated in retrieval systems were the retrieval step failing quietly and the model dutifully working with what it got.
It does not survive a leading question. Ask "why did the Q3 migration fail?" against a source that never says it failed, and the premise is smuggled in past your instructions. Where it matters, ask the model to check the premise before answering it.
And it does not make invention impossible. Nothing does. It moves the rate, and it gives you a shape of output you can verify. If a false statement in your product is expensive, the check belongs in your code — the quote test above, a second call that verifies claims against the source, a human on the sample — not in a sentence in a prompt.
Take your source, and ask a question you know it does not answer. Something adjacent and plausible — a date that isn't there, a name never mentioned.
If you get an answer, your grounding does not work, and no amount of reading the prompt will have told you that. Do this before you ship, do it again after every prompt edit, and keep the failing question as a test case. It takes two minutes and it is the whole game.