Grounding Checklist

Use this checklist when an AI answer needs to reflect real source material: a policy, notes, a document, a ticket, a requirement, or a verified set of facts.

Grounding does not need to make every prompt long. It needs to make the important source, boundary, and review path visible.

Before You Ask

• Identify the source of truth.
• Confirm the source is allowed to be used in the prompt.
• Choose the smallest excerpt that can answer the question.
• Remove private, sensitive, or irrelevant details.
• Decide what the model should do if the source is incomplete.
• Decide who will review the output before it becomes a message, decision, or workflow step.

Quick source decision:

Context Inventory

Use this pass before pasting source material. The goal is to make the model’s working packet explicit, focused, and reviewable.

If you have more than one source, label each one before the prompt starts:

• Source A - approved process note, reviewed 2026-06-15
• Source B - meeting notes, draft, owner not confirmed
• Source C - open questions from the project tracker

Do not make the model infer which source is authoritative. If one source outranks another, say that directly.

Source Quality Checks

Grounding works only as well as the source packet. Before you ask for an answer, check:

• Relevance: does this source actually answer the request?
• Completeness: are definitions, exceptions, examples, or constraints missing?
• Currency: is the source still current enough for this use?
• Authority: is this the approved source, a draft, or one person’s notes?
• Specificity: does it include the names, dates, numbers, steps, or criteria the output needs?
• Conflict: does another source disagree with it?
• Sensitivity: does it include details that should be removed, substituted, or routed elsewhere?

Use a short quality label in the prompt when the source is imperfect:

• Source quality: approved but narrow. Do not generalize beyond the excerpt.
• Source quality: draft notes. Treat missing owners and dates as unknown.
• Source quality: conflicting sources. Preserve the conflict and list what needs confirmation.

Known-Unknowns

Write down the gaps before the model writes around them.

A grounded answer can be useful even when it says “not stated.” That is often the most important result.

Prompt Setup

Include these pieces in the prompt:

• Source label: what the material is.
• Task: what you want done with it.
• Boundary: what the model may and may not rely on.
• Output shape: bullets, summary, table, draft message, checklist, or JSON.
• Uncertainty rule: how to mark missing, unclear, or unsupported details.

Useful sentence:

Use only the source below. If the source does not answer something, say so instead of guessing.

Grounding Prompt Patterns

Use these patterns as starting points. Keep the wording plain and add only the details the task needs.

Single-Source Summary

Use only Source A. Summarize the main points for [audience].
For each bullet, include a short source note showing where the point came from.
If the source does not answer something important, add it under "Not stated."

Extraction With Unknowns

Use only Source A. Extract [fields].
If a field is missing, write "Not stated."
Do not infer owners, dates, amounts, steps, or requirements from general knowledge.

Decision Aid

Use only the sources below. Create a decision aid with:
- confirmed facts
- unresolved questions
- risks if the source is wrong or incomplete
- recommended next check
Do not make the decision for me unless the source includes explicit decision criteria.

Conflicting Sources

Compare Source A and Source B.
List agreements, conflicts, and missing information.
Do not merge conflicting details into one clean answer.
For each conflict, name the source that says it and the question a human should resolve.

Draft Message From Source

Use only the approved facts below to draft a message for [audience].
Do not add dates, promises, owners, exceptions, links, or next steps unless they appear in the source.
Mark any missing detail as "[confirm before sending]."

Copyable prompt scaffold:

Source label:
[What this material is and where it came from]

Task:
[What you want the model to do with the source]

Boundary:
Use only the source below. Do not add facts, steps, names, dates, exceptions, or recommendations
that are not supported by the source.

Output shape:
[Bullets / table / draft message / checklist / questions / JSON]

Uncertainty rule:
If the source is missing, unclear, or conflicting, label the item as "Needs clarification" and say
what is missing.

Review focus:
Mark names, dates, links, numbers, owners, requirements, and recommendations for human review.

Evidence trail:
For each important claim, include the source label or source sentence it came from.

Decide How Much To Ground

Use tighter grounding when the output could affect a person, customer, requirement, workflow, approval, cost, schedule, or public message.

Use lighter context when the task is exploratory, low-stakes, or creative and the output will not be treated as factual without review.

If you are unsure, ground more tightly for the first pass. You can loosen later after you understand which details matter.

Context Window Check

Before you run the prompt, ask:

• Is the relevant source close to the actual request?
• Did the conversation include older details that should now be ignored?
• Is the source short enough that the model can focus on it?
• Are the instructions clearer than the background material?
• Would another person know what the answer should rely on?

If the answer is no, tighten the source and restate the task.

Troubleshooting Weak Context

When an AI answer is polished but wrong, diagnose the context packet before assuming the model alone is the problem.

Use this sequence:

1. Replay the prompt: what did the prompt actually ask the model to do?
2. List the missing context: audience, source status, source priority, constraints, output shape, and review owner.
3. Mark unsupported claims: dates, owners, deadlines, requirements, exceptions, links, numbers, and workflow steps that do not appear in the source.
4. Check source authority: approved source, draft source, older note, personal memory, or unknown status.
5. Preserve conflicts: show the disagreement instead of blending sources into one rule.
6. Rewrite the context packet: source labels, source priority, boundary, uncertainty rule, conflict rule, output shape, and human review focus.
7. Ask for a repaired answer: require confirmed facts, unsupported removals, unresolved questions, and the revised output.

Diagnosis prompts:

Before rewriting, diagnose the source packet. List:
- what the prompt failed to specify
- which claims in the answer are unsupported
- which sources conflict or have unknown authority
- what a human must confirm before this can be used
Then produce a revised answer that uses only supported claims.

Do not blame the model first. Identify whether the failure came from missing source material,
unclear authority, conflicting notes, hidden assumptions, or an overconfident output request.

Troubleshooting signs:

Use this quick repair scaffold:

Source priority:
[Which source is current, approved, draft, stale, or unknown]

Boundary:
Use only the sources below. Do not add unsupported dates, owners, requirements, exceptions, links,
numbers, approval steps, or recommendations.

Conflict rule:
If sources disagree, list each version and the question a human should resolve.

Output shape:
Confirmed facts:
Unsupported or removed claims:
Questions to resolve:
Revised answer:
Human review note:

Evidence Trail

Ask for enough traceability to make review fast. The answer does not need formal citations every time, but it should make important claims easy to check.

Good evidence trails include:

• source labels beside important claims
• short quoted phrases for exact policy or requirement language
• row numbers, section names, or bullet names when the source has structure
• a separate “Not stated” or “Needs clarification” list
• a “Used source” note when multiple sources are available

Use this simple review table when the output will be shared or acted on:

Evidence trail warning signs:

• the answer says “based on the source” but does not show which source
• the answer includes exact numbers, dates, or owners without a visible anchor
• the answer turns an absence into a recommendation
• the answer treats a draft note as approved guidance

Output Review

After the model answers:

• Mark names, dates, links, numbers, requirements, owners, and recommendations.
• Check important claims against the source.
• Look for details that sound plausible but do not appear in the source.
• Replace unsupported specifics with “Needs verification” or remove them.
• Keep human review before sending, publishing, deciding, or changing a workflow.

Red flags:

• citations, links, numbers, or policy exceptions that were not in the source
• confident language where the source is silent
• a recommendation that hides unresolved tradeoffs
• a summary that merges conflicting sources into one clean answer
• a workflow step that assumes approval, ownership, or timing not provided

Use this trigger/action map when reviewing:

Decision labels:

• Use: important claims are supported and review is complete.
• Revise: useful draft, but unsupported details must be removed or marked.
• Verify further: important claims need another source or owner confirmation.
• Escalate: the output depends on authority, risk, or policy beyond the source packet.
• Do not use: the answer is too unsupported, mixed, or risky to repair quickly.

Worked Micro-Example

Scenario: a team lead has rough onboarding notes for a fictional internal tool called LIW Desk. The notes say:

New team members should request access before their first scheduled support shift. The support lead reviews the request and sends the setup link after approval. Training is required before a person handles live requests. The notes do not name the training owner or the access-request deadline.

Weak prompt:

Summarize the onboarding notes for managers.

Grounded prompt:

Use only Source A, the draft LIW Desk onboarding notes below. Create a manager checklist with columns for task, owner, timing, and source support. If the notes do not name an owner or timing, write “Not stated.” Do not add common onboarding steps that are not in the notes. End with questions a human should resolve before sharing the checklist.

Possible grounded output:

Questions to resolve:

• Who owns the required training?
• Is there a specific deadline for submitting the access request?
• Are these notes approved or still draft?

Review pass:

• Check every owner and timing value against Source A.
• Keep “not stated” for the training owner because the notes do not name one.
• Remove any extra onboarding step that came from general expectation instead of the source.
• Ask the source owner to confirm the draft before sharing the checklist.

Why this is better: the answer gives managers a useful draft while preserving the source gaps that matter before anyone acts on it.

Copyable Mini-Checklist

Use this plain-text version in notes, tickets, or prompts:

• Source included.
• Source label, date, owner, and status captured when available.
• Source quality checked.
• Unsupported details forbidden.
• Missing information rule stated.
• Known-unknowns listed before drafting.
• Source is focused and relevant.
• Conflicts preserved instead of smoothed over.
• Evidence trail requested for important claims.
• Dates, numbers, owners, links, and requirements reviewed.
• Trigger/action review completed.
• Important claims checked before use.
• Review owner named before sharing.

Grounding improves the draft. Review decides whether the draft is ready to use.