How can buyers detect answer leakage in generated routing evaluations?

**What counts as answer leakage?**

Leakage occurs when the agent can recover the expected outcome from information that bypasses the intended decision. A request identifier that encodes its target queue, or an agent-visible note containing the evaluator's answer, can invalidate the task.

**Where should buyers look?**

Inspect filenames, record ordering, template phrases, metadata and tool responses as well as the main request text. A retrieval index can expose evaluator annotations even when those annotations are absent from the initial prompt.

**Can split design also create leakage?**

Yes. Closely related requests or shared template families across training and evaluation splits can let the agent recognise a pattern without resolving the business context. Buyers can ask for grouping rules that keep related generated cases together and for a description of remaining shared structures.

**What is a useful diagnostic?**

Remove the business evidence and test whether a simple baseline still predicts destinations from incidental fields. Unexpected success warrants inspection. It does not automatically prove leakage, but it identifies shortcuts that need explanation before the evaluation supports a purchasing or deployment decision.