The working paper uses the special elements Mandates:, Expects: as well as Requires: to types, albeit [structure.specifications] defines them only for functions, for example [structure.specifications] sub-bullet (3.4):

Expects: the conditions (sometimes termed preconditions) that the function assumes to hold whenever it is called.

Examples for such usages on types are (from N4800):

• [char.traits.typedefs] for types int_type and state_type

• [pair.astuple] for tuple_element<I, pair<T1, T2>>::type

• [tuple.helper] for tuple_element<I, tuple<Types...>>::type

• [tuple.traits] for uses_allocator<tuple<Types...>, Alloc>

• Table 62 — "Container requirements" for type XX::value_type

• Table 65 — "Allocator-aware container requirements" for type allocator_type

• Table 69 — "Associative container requirements" for types X::value_type and X::key_compare

• Table 70 — "Unordered associative container requirements" for types X::value_type and X::key_equal

Instead of replacing these elements usages for these places by extra wording to reach the same effects I recommend to update instead [structure.specifications] to ensure that requirement-expressing elements are defined in a way that it also allows to express requirements imposed on types by these elements to standardize "existing practice".

Considering details, it seems obvious that Mandates:, Expects: as well as Requires: are "suitable" to be defined for types (With the acceptance of P1463R1 there are now also Mandates: for types such as Table 65 — "Allocator-aware container requirements" for type allocator_type).

For Constraints: the meaning would not be so clear: Should it mean that there is conditionally a type defined or not? According to the submitters knowledge there are currently no known examples for Constraints: to specify constraint on types, therefore I'm suggesting to restrict this extension to Mandates:, Expects:, and Requires: alone.