An answer can be clear, polite, and wrong in exactly the place that matters. A support assistant might quote the right product description and then add a delivery promise that the source never made.
I treat generation and validation as separate responsibilities. The model proposes a response. The application decides whether that response satisfies the evidence and product rules required for delivery.
Identify the claims that create risk
Not every sentence needs the same treatment. A greeting has little factual content. A price, product identifier, warranty condition, or link can directly influence a customer’s decision.
I begin by identifying those concrete claims. The validator then compares them with the retrieved sources or authoritative structured data. It should preserve relationships: finding the number 49 in a source is not enough to support a price of €49 for the selected product.
Currency, variant, quantity, date, and market can all change the meaning of a value. A useful check asks whether the complete claim is supported in the relevant context.
Keep links tied to trusted source records
A model can produce a plausible URL that does not exist. It can also produce a real URL that points to the wrong product. I prefer links selected from verified source records rather than paths assembled from generated text.
The link check needs an explicit normalization policy. Comparing only domains would accept many incorrect destinations. Comparing raw strings without handling legitimate formatting differences can reject valid links.
If the application fetches a generated URL to validate it, that fetch introduces its own security boundary. In many cases, matching against a controlled source catalog is simpler than allowing arbitrary network requests from the validator.
Use deterministic checks where the domain permits
Structured product identifiers and known prices are good candidates for deterministic validation. Open-ended policy paraphrases are harder: matching keywords cannot prove that a sentence preserves the original conditions.
A model-based verifier can help inspect semantic claims, but it introduces another fallible component. I would calibrate it against human-reviewed examples and keep high-impact rules explicit. Asking the same generation model whether it was correct is weak evidence on its own.
A possible result structure is:
{
"decision": "needs_revision",
"unsupported_claims": ["delivery_by_requested_date"],
"allowed_source_ids": ["shipping-policy-v3"],
"next_action": "ask_for_postcode"
}This is an illustrative contract. The important part is that failure produces an actionable state instead of a generic Boolean that downstream code can ignore.
Plan what happens when validation fails
The application may regenerate once using narrower evidence, remove an unsupported claim, ask for missing information, or hand the conversation to a person. That choice should depend on the reason for failure.
Retries need a limit. Repeatedly generating until a response passes can increase cost while selecting for weaknesses in the validator. Every attempt should remain within the request’s time and spending budget.
Streaming also changes the design. Text already shown to the customer cannot be made unseen. If the product promises validation before delivery, high-impact claims need to be buffered or generated from approved structured fields before they are released.
Keep evidence validation separate from instruction trust
A retrieved document can contain useful facts and malicious instructions. Passing an evidence check does not give that document authority to change tool permissions or system behavior. OWASP’s prompt injection guidance is a useful reference for this separate trust boundary.
I want validation failures to become evaluation cases. Each unsupported promise or incorrect link describes a concrete behavior the system should recognize next time, and a regression check the team can run before changing the pipeline.
Updated 25 September 2026.