Define the approved source of truth
Verification starts by naming what actually governs the answer: the current policy document, official product documentation, technical specification, contract clause, schema definition, source code, or test evidence the response is supposed to reflect. Without a named source, a "verified" answer is really just a plausibility read.
The source also has to be the right version. A policy that changed last quarter, a deprecated API spec, or an outdated contract clause can make an answer look supported when it is actually citing something that no longer applies.
A source name is not the same as evidence. An answer that references "the security policy" or "section 4.2" without the underlying text being checked is asserted, not verified. Treat any citation you have not compared against the real document as unverified, and treat a citation that cannot be located at all as a fabricated reference.
Check each material claim against the source
Break the response into the individual claims a user or downstream system could act on: instructions, numeric values, dates, eligibility rules, and promises. Generic framing does not need line-by-line checking; the claims that drive a decision do.
For each claim, check whether the source directly supports it, directly contradicts it, is silent on it, or supports only part of it. Silence and partial support are the cases teams miss most often, because the answer still reads as confident even when the source never addressed the specific condition.
Prioritize claims by impact: security and access rules, compliance obligations, monetary values, dates and deadlines, and any restriction or promise the reader could rely on immediately. A minor wording gap in a low-impact sentence matters far less than one unsupported instruction in a high-impact one.
Route the response before release
Allow the response when its material claims are sufficiently supported for the audit performed and no material contradiction or dangerous omission is identified. Critical or regulated work may still require normal testing, professional review, or human approval before release.
Route to review when a claim is missing supporting evidence, only partially supported, or depends on a condition the source does not clearly state. Review is for genuine uncertainty, not for claims that already contradict the source outright.
Block when the response contradicts the approved source on a material point or asserts something risky with no supporting evidence at all. Keep the source comparison, the decision, and the next step as an audit trail so the same claim is not re-litigated the next time it appears.