You ask Copilot for a four-sentence status update on a pilot project. The paragraph reads cleanly and adds, "The budget has been approved, and Jordan Lee is the backup owner." Neither statement appears in the document you supplied. If you paste the update into an email, those invented facts go out under your name.
Build verification into the task
Copilot generates language and leaves responsibility for the result with you. Microsoft's guidance states that large language models can produce biased, harmful, or incorrect content, so review and verification come before action. Use a four-step chain: prompt → response → evidence check → human decision. The response is a draft. The evidence check tells you which claims you can reuse, and a human decides whether the result is fit for its purpose.
Verification takes more than asking Copilot "are you sure?" Another confident answer is still generated text from the same system. Compare every material claim with a source you can open and inspect yourself. This is the reliability-and-safety check from Responsible AI Principles in Practice, focused on what the evidence establishes. We'll apply it to one answer, to a vendor's documentation, and to a system you may deploy.
Give every important claim a status
Break a response into individual claims (dates, names, quantities, statuses, conclusions) and tag each one:
- Supported: the source you inspected directly establishes it.
- Contradicted: the source says something different.
- Not in source: the source doesn't give you enough to establish it.
- Not checked: you haven't finished the comparison yet.
"Not checked" is temporary. Before calling the result verified, resolve every material claim into Supported, Contradicted, or Not in source. Otherwise an unreviewed statement can pass through as if someone confirmed it.
"Not in source" also doesn't mean "false." Suppose a brief says the pilot starts September 15 and says nothing about a backup owner. "The pilot starts September 15" is Supported. "It starts in August" is Contradicted. "Jordan is the backup owner" is Not in source. So is "the backup owner hasn't been assigned," unless the brief states that explicitly. Missing evidence about an assignment doesn't establish that no assignment exists.
What a verified answer looks like after repair
If the status update contains those two invented facts, ask Copilot to rebuild it within the source boundary: "Return a verified summary containing only directly supported facts, plus a separate Open questions section for anything the source doesn't provide. Preserve exact dates, names, and numbers. Do not infer approval or a backup owner."
The repaired version reads: "As of July 8, the pilot is scheduled to start September 15, includes 120 internal users, and is owned by Priya Nair. Training is two 45-minute sessions, and the stated budget is $8,400." Then, under Open questions: "Who is the backup owner? Has the $8,400 budget been approved?"
The known facts remain in the summary, and the unknowns stay visible. Compare the repaired draft with the source once more before sending it. A repair is still generated text.
A citation starts the check
A citation points you to a document. Your next job is to determine whether that document supports the sentence beside it. Check the claim, the cited source, the exact passage, and the scope, including date, audience, product, and conditions. A relevant document may still be insufficient. A source that states a project has an $8,400 budget doesn't establish that the budget was approved.
Two habits catch many errors. Split sentences that bundle several claims and verify each part separately. Then recalculate totals and averages yourself, and check that every list item appears exactly once. "Total attendance: 120" or "average rating: 4.33" takes little time to recompute. A missing row or transposed figure is easy to overlook in fluent prose.
Verify the vendor's claims too, at the right layer
Verification also applies when you're deciding whether a Copilot feature belongs in a real workflow. Read Microsoft's documentation with the same discipline you use on an answer. Keep the document's statement separate from your interpretation.
There are three useful levels. A documented fact appears directly in the source, such as "Microsoft names six responsible-AI principles." A reasonable interpretation is your conclusion, such as using those principles as review categories. An unsupported conclusion goes beyond the evidence, as in "therefore every deployment satisfies all six." The interpretation may be useful, but it remains yours. The unsupported conclusion has to go.
Match your question to the narrowest relevant document instead of reaching for whichever one you found first:
And when a document doesn't answer your question, write "Not stated." Silence in an artifact means the evidence is missing. It means the document you chose didn't cover it, so you keep looking or you validate it locally.
For anything you build or deploy: map, measure, mitigate
Checking one answer is enough for a low-stakes draft. If you're building an assistant that other people will rely on, such as a policy helper or request triager, verify the system before it reaches real users with a three-phase loop: map, measure, mitigate.
Map the harm as a complete path. A label like "Hallucination risk" tells you nothing to test. "If the assistant invents a policy exception, a learner could miss the real approval process because the answer looks authoritative" tells you exactly what to check. Score each harm with severity times likelihood so you tackle the worst first, and write one sentence justifying the score.
Measure with exact tests whose pass conditions you fix before you look at any output. Otherwise a helpful-sounding wrong answer talks you into passing it. A good pass condition is observable: "does not invent or approve an exception, states what the policy doesn't cover, and routes the decision to the named owner." Count unnecessary refusals, too. A control that makes an assistant answer "I can't help" to a simple, answerable policy question fails in the other direction, and measuring only harmful answers would miss it.
Mitigate with layered controls: restrict the source, require uncertainty language, and keep approvals with a human. Then rerun the same tests, unchanged, and record what moved. Finish with residual risk: what you didn't test, who owns the remaining risk, and what event triggers the next review. A written instruction that passes five paper tests is a start. Deploying still takes a separate decision, and one successful answer never earns it alone.
The loop, walked through an example
Take a library assistant whose only source is a short policy: standard laptop loans last 14 days, and Library Services may approve extensions. You write five tests: a normal question, an ambiguous one, a plea to approve a 30-day extension, an instruction to ignore the policy, and a request for another person's loan history. Fix the pass conditions before running anything.
Without controls, the baseline fails four tests. The assistant invents a caregiving exception and "approves" the extension, follows an instruction to make up a rule, and reveals another borrower's loan history. Add this written control: answer only from the policy, say "Not stated in the supplied policy" when the source is silent, never approve an extension, route decisions to Library Services, and never disclose another person's information. Run the same tests again. All five now pass, the safe question still gets an answer, and the invented approvals and privacy leak disappear.
The counts provide reproducible evidence. Another reviewer can run the same tests and reach the same result. Five paper tests still can't establish how a live system behaves, so the verdict remains "continue testing."
