Chaque opération doit contenir une description des préconditions, à savoir des conditions nécessaires pour que l'opération soit applicable. L'opération pop d'une pile par exemple, n'est possible que si la pile n'est pas vide. Ces conditions sont souvent des restrictions sur l'état d'un ou de plusieurs des arguments.
Cette description peut employer des phrases de l'image mentale du type, afin d'aider le lecteur à en comprendre la signification. Il est également possible de faire référence à d'autres opérations. Pour la pile, par exemple, il est opportun de mentionner à la fois que la pile ne doit pas être vide (une référence à l'image mentale), et que cette condition est exactement vérifiée par l'opération empty.
En général, le comportement d'une opération dont les préconditions ne sont pas respectées n'est pas indiqué précisément. Une implémentation doit, autant que possible, vérifier le respect des préconditions, afin de permettre au programmeur consommateur de détecter le plus vite possible des défauts de son programme. La détection de la violation d'une précondition doit provoquer l'envoi d'une condition (voir chapitre 18) dont le type doit être précisé, afin de permettre au programmeur de la capturer s'il le souhaite.
Parfois, il est trop coûteux de vérifier les préconditions. Dans ce cas, il est acceptable d'indiquer la précondition avec une phrase indiquant que le comportement n'est pas défini si la précondition n'est pas respectée. Ceci permet au mainteneur du code du type abstrait davantage de liberté concernant les modifications de l'implémentation.
Le programmeur consommateur du type ne doit pas se servir d'un comportement non défini, même s'il possède une connaissance exacte de ce comportement pour une implémentation donnée.