Test useful refusals, not just successful answers

Write questions the sources cannot answer

Include requests for future release dates, private account facts and unsupported product behavior when those are outside the pilot. Use harmless fictional examples rather than personal data. Record the expected boundary before testing. If every evaluation question has an answer somewhere in the corpus, you will learn little about how the assistant behaves when the real reader asks something the documentation never covered.

Define a helpful limit

The response should explain what it can establish from the available material and what remains unknown. It can point to an official contact or relevant article without pretending that a transaction occurred. A blunt refusal to every difficult question may avoid some errors but still fail the reader task. Review whether the suggested next step is appropriate, reachable and within the public information scope.

Watch for invented certainty

An assistant may supply a confident estimate or an unsupported assurance because that sounds more helpful than uncertainty. Treat fabricated dates, account status or guarantees as failures, not creative completion. A statement that no information was found is different from a statement that a feature does not exist. Require that distinction in the review record so absence of evidence does not become a false product claim.

Keep the boundary visible after changes

Source additions, prompt changes or new integrations can alter refusal behavior. Retain a few important out-of-scope cases in every regression run. If the assistant starts claiming to act on accounts or disclosing material outside the intended collection, stop the affected public use and investigate. Do not bury a critical boundary failure inside an average satisfaction score or wait for more traffic to decide whether it matters.

• Include a request for an unpublished future date and a harmless fictional account action to test two different kinds of useful limit.