Grounding and Context

The first AI Foundations lesson covered the core warning: a language model can write smoothly without proving that its answer is true. Grounding is one of the simplest ways to reduce that risk.

Grounding means giving the model the source material it should rely on. Instead of asking for an answer from general patterns, you supply the relevant policy, notes, requirements, article, table, or example and tell the model how to use it.

Grounding does not make the model perfect. It gives the model a better target. This lesson shows how to choose that target, keep it close to the task, and review the answer without pretending the source did more work than it actually did.

From Guessing To Source Use

Compare these two requests:

Write a summary of our equipment checkout policy for a new team member.

That prompt asks the model to guess what the policy says. It might produce something clear and professional, but the details may be invented.

Now compare:

Use only the equipment checkout policy below. Summarize it for a new team member in plain language. If the policy does not answer a question, say “The policy does not specify that.” Do not add deadlines, exceptions, or approval steps that are not in the source.

The second prompt changes the job. The model still generates text, but the source material tells it what to rely on and what not to invent.

That is grounding.

Why Grounding Works

A model responds from the information available to it. If the prompt gives only a broad request, the model leans on general patterns. Those patterns may be useful for style, structure, or common language, but they are not proof of what your source says.

Grounding changes the center of gravity. It gives the model material to use and instructions for how to use it. The model can still make mistakes, but the task becomes easier to review because the answer has something visible to compare against.

Think of grounding as moving from “write what probably belongs here” to “work from this material and show me where it is incomplete.” That is a better job for AI and a better review path for the person using the output.

What Counts As Grounding Material

Grounding material can be any source the model should use for the task.

Common examples:

• a policy or procedure
• meeting notes
• a product page
• a support ticket
• a requirements list
• a spreadsheet excerpt
• a code comment or README
• a short set of facts you already verified

The source does not have to be long. In many work situations, a short approved excerpt is safer than a large pile of loosely related material.

Good grounding material is:

• relevant to the task
• current enough for the decision
• allowed to be used
• clear about what it does and does not cover
• small enough that the model can attend to it

If the source is missing, stale, confidential, or too broad, the model may still produce a polished answer. The polish is not proof.

Not everything around the task counts as grounding. These are weak substitutes:

• a vague instruction such as “use best practices”
• your intent if it is not written in the prompt
• a link the model cannot actually open or retrieve
• a long conversation where the important source appeared far above the current request
• an old draft when the current version is the one that matters

Good grounding is specific enough that another person could say, “Yes, this is what the output should rely on.”

The Context Window Is Working Space

The context window is the information a model can use in one interaction. Think of it as working space, not permanent understanding.

This matters because prompts often grow:

1. You give background.
2. The model answers.
3. You add corrections.
4. The model revises.
5. More source material gets pasted in.
6. The conversation keeps going.

As the interaction grows, earlier details may become less visible to the model. A long conversation can feel like continuity, but the model may not treat every earlier instruction with equal strength.

When the work matters, do not rely on “I told it that ten messages ago.” Restate the key source, constraint, or review requirement near the current request.

Grounding Reduces Hallucination Risk

A hallucination is a confident answer that is incorrect, invented, or unsupported by the evidence available to the model.

Weak grounding increases hallucination risk because the model has to fill gaps. It may infer a deadline, invent a citation, assume a policy exception, or smooth over missing facts.

Better grounding reduces the number of gaps. It tells the model:

• what source to use
• what source not to use
• what to do when the source is silent
• how to label uncertainty
• what claims need verification

This is why grounded prompts often sound more restrictive. The restrictions are the point. They keep the model from turning missing information into confident language.

A Practical Grounding Pattern

Use this pattern when you want an answer tied to source material.

1. Name The Source

Tell the model what the source is.

Example:

The text below is the current onboarding checklist for new team members.

2. State The Task

Say exactly what you want done with the source.

Example:

Turn it into a one-page manager checklist.

3. Define The Boundary

Tell the model what it may and may not rely on.

Example:

Use only the checklist below. Do not add steps from general HR practice.

4. Require Uncertainty Labels

Tell the model what to do when the source is incomplete.

Example:

If a section is unclear or missing an owner, mark it as “Needs clarification.”

5. Review The Important Claims

After the output is drafted, check anything that would matter if it were wrong.

Example:

Verify names, dates, system names, approval steps, links, and deadlines before sending.

Worked Example: Meeting Notes

Weak prompt:

Write follow-up tasks from the meeting.

Better grounded prompt:

Use only the meeting notes below. Create follow-up tasks with owner, action, due date, and source sentence. If the notes do not name an owner or due date, write “Unassigned” or “No date stated” instead of guessing.

Why the second version is stronger:

• it says which source to use
• it gives the output shape
• it prevents invented owners and dates
• it makes missing information visible
• it leaves reviewable evidence in the output

That last point matters. Grounded output should make review easier, not just sound more confident.

Worked Example: Policy Excerpt

Weak prompt:

Explain the new expense rule to the team.

This prompt leaves too much open. The model does not know which rule is current, which audience needs the explanation, or which details must be left out.

Better grounded prompt:

Use only the policy excerpt below. Write a short team announcement that explains what changed, what employees need to do, and what is still unclear. If the excerpt does not specify a deadline, approver, amount, or exception, write “Not specified in the excerpt.” Do not add examples that are not supported by the text.

Why this is stronger:

• it names the source and limits the answer to that source
• it asks for a specific communication shape
• it identifies the kinds of details that are easy to invent
• it turns missing information into visible gaps
• it keeps a person responsible for deciding whether the announcement is ready

The model can help turn approved material into clearer language. It should not quietly turn an unfinished policy into a finished instruction.

When You Can Ground Less

Not every AI task needs a heavy source packet.

You can often ground less when the task is low-stakes, creative, temporary, or clearly separated from facts. Brainstorming meeting titles, suggesting alternate wording for a sentence, or listing possible agenda structures may not need a formal source excerpt.

Even then, give the model enough context to be useful:

• the audience
• the tone
• the purpose
• any hard constraints
• anything it must avoid

The question is not “How much context can I paste?” The question is “What information does the model need to do this specific job without guessing about the important parts?”

Common Grounding Mistakes

Too Much Source Material

More context is not always better. If you paste ten documents for a simple question, the model may mix details that should stay separate.

Better: provide the smallest source set that can answer the question.

Hidden Source Assumptions

The model cannot rely on a document you did not provide unless it has tool access to retrieve it.

Better: paste the relevant excerpt or give the model a verified retrieval path.

Old Context Treated As Current

A model may continue using earlier information after the task has changed.

Better: restate the current source and say whether earlier context should be ignored.

Unsupported Specifics

Specific names, dates, links, titles, and numbers can look trustworthy even when invented.

Better: require the model to quote or cite the source line for important details, then verify the details yourself.

Grounding On Conflicting Sources

Sometimes two sources disagree. The model may smooth over the conflict because a clean answer feels more helpful.

Better: tell the model to preserve the disagreement. Ask it to list what each source says, identify the conflict, and mark the decision as needing an owner instead of choosing a winner.

Practice: Troubleshoot A Weak Context Packet

This practice is about diagnosing the prompt and source packet before blaming the model. The model can still make mistakes, but in this scenario the first failure is the job it was given.

Scenario

A team lead is preparing a short internal announcement for a fictional workspace tool called Northstar Notes. The team wants to reduce confusion about when notes should be shared after a meeting.

The lead gives an AI assistant this vague prompt:

Write a friendly announcement telling everyone the new meeting-note process. Keep it short and confident.

The AI returns this draft:

Starting Monday, all meeting notes must be posted in Northstar Notes within 24 hours. Project leads are responsible for posting action items, and managers will review compliance every Friday. Use the new template for every meeting, including informal check-ins.

It sounds useful, but the team lead notices that some details may not be supported.

Source Notes Available

Source A - draft process note, updated this week:

Teams should use Northstar Notes for project meetings where decisions, risks, or action items are discussed. Notes should be shared promptly after the meeting. The note owner is the meeting organizer unless the group chooses someone else during the meeting. The process note does not set a deadline and does not say who audits compliance.

Source B - older rollout note, status unknown:

During the pilot, the operations group asked project leads to post notes within 24 hours for weekly planning meetings. A manager reviewed the first two weeks of pilot usage.

Source C - message from the team lead:

I only need an announcement for the project team. Please avoid policy language unless the source actually supports it. If the notes disagree, I want the conflict shown rather than hidden.

What Is Missing Or Conflicting

Before rewriting the answer, diagnose the context problem.

• The prompt did not name the source of truth.
• The prompt asked for confidence, which encouraged unsupported certainty.
• Source A is current but incomplete: it says “promptly” but gives no deadline.
• Source B may be stale and should not outrank Source A without confirmation.
• The draft invented a Monday start date, a 24-hour rule for all meetings, manager review, and template use.
• The team lead’s audience and boundary were known, but the prompt did not include them.

The right fix is not “the model is bad.” The right fix is to give the model a better job: separate confirmed facts, conflicts, and unknowns before drafting the announcement.

Improved Context Packet

Use a packet like this before asking for the revised announcement:

Task:
Draft a short internal announcement for the project team about using Northstar Notes for meeting
notes.

Sources:
Source A is the current draft process note. Treat it as the main source.
Source B is an older rollout note with unknown status. Use it only to identify possible conflicts or
questions.
Source C is the team lead's instruction for audience and tone.

Boundary:
Use only the sources below. Do not add dates, deadlines, audit steps, template requirements,
owners, or meeting types unless a source supports them. Do not turn draft notes into approved
policy.

Conflict rule:
If Source A and Source B disagree, preserve the conflict and list the question a human should
resolve. Do not blend them into one clean rule.

Output shape:
1. Confirmed points for the announcement.
2. Do-not-say list for unsupported details.
3. Questions to resolve.
4. Revised announcement, no more than 120 words.

Learner Task

Write the revised answer the AI should produce from that improved packet.

Your answer should include:

• confirmed points from the source packet
• unsupported details to remove
• conflicts or missing context to resolve
• a short announcement that avoids invented deadlines, owners, audits, and start dates
• a human review note before sending

Sample Answer

Confirmed points:

• Northstar Notes is for project meetings where decisions, risks, or action items are discussed.
• Notes should be shared promptly after the meeting.
• The meeting organizer owns the note unless the group chooses someone else during the meeting.
• The announcement is for the project team.

Unsupported details to remove:

• Monday start date.
• A 24-hour deadline for all meetings.
• Project leads as the default action-item posting owners.
• Friday manager compliance review.
• Required use of a new template.
• Coverage for informal check-ins.

Conflicts and questions:

• Source B mentions a 24-hour pilot expectation for weekly planning meetings, but Source A does not set a deadline. Confirm whether any deadline remains active.
• Source B mentions manager review during the pilot, but Source A does not include an audit step. Confirm whether review is still required.
• Confirm whether there is an approved template before naming one.

Revised announcement:

For project meetings where decisions, risks, or action items are discussed, use Northstar Notes to capture and share the notes promptly after the meeting. The meeting organizer owns the notes unless the group chooses another owner during the meeting. The current process note does not set a specific sharing deadline, audit step, or template requirement, so those details should be confirmed before we treat them as team rules.

Human review note:

• Ask the process owner to confirm deadline, template, and review expectations before sending if the announcement needs to be more directive.

Rubric

Your answer is strong if it:

• diagnoses missing context before rewriting the announcement
• treats Source A as current and Source B as lower-authority or uncertain
• preserves the 24-hour and manager-review conflicts instead of smoothing them over
• removes unsupported dates, owners, audits, templates, and meeting types
• labels unknowns without treating them as model failures
• produces a usable announcement that is accurate but not overconfident
• names what a human should verify before the message is sent

Common Mistakes

• Rewriting the announcement directly without first naming what was wrong with the context packet.
• Keeping the 24-hour deadline because it sounds practical.
• Treating the older pilot note as equal to the current process note.
• Saying “the AI hallucinated” without explaining which missing prompt boundaries made the error easier.
• Adding a template, audit owner, or start date to make the announcement feel complete.
• Hiding the conflict so the final answer sounds cleaner.

Self-Check Questions

1. Which unsupported claim in the AI draft would create the most operational confusion if sent?
2. What should the prompt say when one source is current and another source has unknown status?
3. Why is “keep it short and confident” risky when the source packet has gaps?
4. What should the answer do when the source says “promptly” but does not define a deadline?

Completion Evidence

You have completed this practice when you can show:

• a diagnosis of the weak prompt and missing context
• a corrected context packet with source priority, boundary, conflict rule, and output shape
• a revised answer that separates confirmed facts from unknowns
• a review note naming the details a human must confirm before sending

Quick Reference

Use grounding when the answer needs to reflect real material. Keep the source focused, put it near the task, and say what the model should do when the source is silent.

Use lighter context when the task is exploratory or low-stakes. Even then, name the audience, purpose, and constraints.

Before relying on the output, compare important claims back to the source. Grounding improves the draft. Review decides whether it is ready.

Use the Grounding Checklist when you need a copyable setup and review pass.

Compact Exercise

Rewrite this weak prompt:

Summarize the new travel rules for employees.

Make it grounded by adding:

• what source material the model should use
• what output shape you want
• what the model should do when the source does not answer something
• what details need human verification before the summary is shared

The goal is not a longer prompt for its own sake. The goal is a prompt that makes guessing harder and review easier.