||There seems to be a 'tyranny' of predefined purpose in some highly automated CADproducts. For example, a CAD product for architects may provide 'high level" commands fortrimming 'walls'. However, unless the 'wall' types conform to a particular topology, they cannot be trimmed. On the other hand , there are 'low level' commands which can be used totrim more general types of graphic entities. However, unless the graphic entities are tediouslydecomposed into primitive elements, such as line segments and arcs, they also can not betrimmed. A paradox of design automation is that adding higher level functionality to a CADproduct bounds its use within a specific design modeling domain and restricts its use from othermore general domains. On the other hand, more general CAD products are flexible at aprimitive level, but can not be used to provide 'high level' functionality.Although design specific knowledge within a CAD product may prove to be a great utility insome instances, it is typically paid for in terms of pre-conceived constraints on modeling.Artificial Intelligence techniques may provide a way of offering high level functionality with lesspre-conceived constraints; however, it may be fallacious to assume that o particularmodeling domain will not be Imposed on the user. This paper illustrates how a modelingdomain is typically defined with a commercial CAD product . It takes notice of how theassumptions underlying any particular modeling domain may be challenged by design theory.It then cautiously explores a scenario for how the need for a modeling domain may bereconciled in a "thousand flowers bloom" approach.