Most AI feature specs describe what the feature does. Very few describe what it deliberately does not do, and that omission is where a surprising amount of trouble starts.
A language model will attempt almost anything it is asked. If your support assistant is not told that legal questions are out of scope, it will answer legal questions, fluently and with unearned confidence. Users do not read your roadmap. They read what the interface lets them type, and they treat a plausible answer as a supported one.
A short non-goals list changes that in three concrete ways.
It gives the prompt something to enforce. "Decline requests about X and point to Y instead" is a testable instruction. "Be helpful but careful" is not.
It gives the eval suite a category. Add test cases for each non-goal, and check that the feature declines gracefully and routes people somewhere useful. Teams that only test the happy path discover their boundaries from user screenshots.
It gives the team a shared answer. When someone asks "can we just let it also handle refunds?", you have a written starting point for the conversation: what was ruled out, why, and what would have to be true to revisit it.
A useful non-goals list is short and specific. Aim for five or six items, each with a reason: not "medical advice" alone, but "medical advice, because we cannot verify outputs and the cost of a wrong answer is high." Put the list in the README next to the feature, link it from the prompt's change history, and review it whenever scope changes.
The goal is not to make the feature timid. It is to make its edges visible, so that when it says no, it says no on purpose.