A sponsor asks for the migration status, the owners of open work, and whether the plan matches current public guidance. The first two answers live in internal records. The last one needs the public web. Put them into one loose prompt and the response may blend evidence that should have stayed separate.
Know which evidence the answer needs
Grounding is the evidence Copilot uses to build a response. In this lesson, keep three classes distinct:
- Work grounding uses organizational context such as files, mail, and meetings through licensed, work-based chat.
- Web grounding uses public information retrieved through web search.
- Prompt-provided grounding uses text pasted into the prompt.
For each fact, ask whether someone could answer it accurately from public information alone. Private decisions need internal evidence or an internal record supplied in the prompt. An internal note can't establish what a public page says today, and the public web can't tell you what your team decided privately.
Why a citation isn't proof
A citation points to a source. It helps you locate evidence, but the source may not support every nearby sentence. Copilot can misread a genuine document or cite one line while drawing the rest from general knowledge.
Accuracy and provenance answer different questions. Accuracy asks whether the record supports the claim. Provenance asks which evidence Copilot received or used. If you paste notes into a prompt and the response matches them, you have shown accuracy against the supplied text. You haven't shown that Copilot retrieved a work object. Record the result as "prompt-provided evidence."
Selecting a file through the reference flow before sending the prompt gives you evidence that you supplied that source. Comparing an answer with a record afterward gives you accuracy evidence. When the source Copilot used is unclear, write "Not yet checked" for provenance and leave the assumption open.
Select the source, then state the task
Point Copilot to the material you want it to use. In Copilot Chat, the documented routes are to type / and select an available item, or use the Add content workflow shown in your interface. Depending on the subscription, the reference list may include files, people, meetings, and emails.
A reference doesn't explain what to do with the source. Pair /LaunchBrief.docx with a task, output requirements, and a rule for missing information. Also record how the material entered the prompt. A selected source comes through / or Add content and tests a real work object. Supplied text is pasted into the prompt and tests the answer against that text.
Check the selected item before trusting the response. Similar document names are common: "final" beside "final v2," or this quarter's brief beside the previous one. Read the visible title and a line of content. If the person or meeting you need isn't available as a reference, paste the permitted passage and note that you used supplied text. That test says nothing about work-object grounding.
Give every source one job
When several documents describe the same project, decide what each one is allowed to establish. Without that boundary, a requirement in a brief can be reported as completed work.
The brief records what must happen. The readiness checklist records current status. Meeting notes separate confirmed decisions, assigned actions, proposals, and open questions. A stakeholder record can establish a person's stated role, concern, or assigned responsibility. Keep those jobs intact. Someone who coordinates a rollout doesn't automatically own every task in it, and a proposal to delay Canada isn't a confirmed decision.
Ask Copilot to return these categories separately and inspect the original heading or field behind each result. The distinction is especially important for people and meetings, where broad roles and tentative language are easy to overread.
The four verification statuses
Use one vocabulary every time you check an answer, and a claim-to-source ledger to hold it:
- Supported: the checked source directly backs the claim.
- Contradicted: the checked source conflicts with it. Remove or rewrite.
- Not found: you checked the intended source and the fact isn't there.
- Not yet checked: no authoritative source has been inspected yet.
The last two are not interchangeable. "Not found" is a conclusion you earned by looking. "Not yet checked" is an admission you haven't looked, and it's a legitimate result. Leave the gap open until you check it. Don't paper over it with something plausible. When a mixed question spans internal and public facts, run them as separate passes, audit each against its own source, and combine only the claims that survived. Preserve missing information as missing: a pilot review on 15 July does not license "production launches 15 July."
A ledger makes this concrete: one row per claim, each with its evidence class, the source you checked, a status, and a final action. "Finance validation is complete: internal source, 7 July record, Supported, keep." "Production launches 15 July: internal source, Contradicted, remove, because 15 July is a pilot review and the launch date was not decided." "Plan follows current public guidance: public source, no source checked, Not yet checked, omit until checked." The ledger is complete when every claim has a disposition, even the ones still labeled as gaps. An answer with three plainly labeled "Not yet checked" rows is more useful than a confident one that guessed all three.
