A brief describes what is wanted. It almost never describes what is not wanted, and the silence gets filled in by whoever is designing. Someone assumes the system must keep working through the loss of an entire data centre; someone else assumes it must support a second country next year; a third person builds an extension point for a feature nobody has asked for. Each assumption is defensible on its own and each one adds structure, cost and a place for the design to break. A non-goal is a written statement that a plausible capability is deliberately outside this design: this release does not survive the loss of a region, does not support offline use, does not keep more than ninety days of history, does not serve customers outside one time zone. Non-goals are useful precisely because they are contestable. Writing one down invites the person who disagrees to say so now, while changing the design is cheap, rather than in a review after the work is done. They also age: a non-goal is a claim about the current period, and it deserves to be revisited when the business changes. After this Concept you can write the short list of capabilities your design is deliberately not providing, and name the structure each non-goal has saved you from building.
This concept addresses scope management in AI agent product design through explicit negative specification: documenting non-goals alongside feature descriptions. The underlying principle is that a sy…