Which request variations should a generated routing pack cover?

Use this checklist to request generated variation that exercises distinct intake behaviours rather than producing many equivalent versions of the same message.

- Abbreviations that require domain context to interpret. - Forwarded threads containing superseded instructions. - Attachments carrying the only usable request reference. - Transcribed calls with uncertain words marked explicitly. - Messages that withdraw an earlier requested action. - Shared inbox submissions with unclear requester authority. - Channel metadata that conflicts with message content.

Each variation should have an operational purpose. A forwarded thread can test whether the agent identifies the latest instruction; a withdrawal can test whether it stops an assignment that has not yet been accepted. Merely changing greetings or sentence order provides a different kind of coverage.

Buyers can ask for a variation manifest connecting each family to the intended challenge and expected behaviour. Where an attachment is necessary, its contents should be included in a supported generated format, or the task should explicitly test the consequence of its absence.

The pack should distinguish intentional ambiguity from generation mistakes. Otherwise, developers cannot tell whether an agent sensibly requested clarification or failed a task that was supposed to be fully resolvable.