When one is combining mapping functions by executing them in sequence, the sequence of transformation steps will only succeed if all models produced as outputs by a mapping are well-formed with regard to the associated mapping function. It's desirable to anticipate possible violations up front and to inform the modeler about them. This requires a holistic view of the sequence of mapping functions to be applied, which results in a back-propagation of constraints of mapping functions further down the sequence to verification steps that take place before the mapping sequence is started.
A constraint may take the form of a naming convention or a limitation on the values of a certain element of the target metamodel. Inheritance rules also qualify as constraints; for example, Java allows only single implementation inheritance. Such constraints should be checked as early as possible in the mapping chain, which will in turn enable the modelers to avoid extra effort and errors later in the process of mapping models.
Looking at this another way, this means that constraints in target metamodels should be propagated back up the metamodel chain as far as possible. The issue here is not to force the application expert (for instance, a banker) to be aware of implementation technology restrictions; the issue, rather, is to find a place in the process where the restriction can be resolved. Only when it can't be resolved should the expert be aware of the restriction. Ideally, the tools for creating and editing the source models enforce these constraints. If this isn't possible, at least automatic model verification which the modeler would have to trigger explicitly should be supported.
A subtler form of constraint comes about when assumptions are not met by a dependent domain. For example, if the Bank assumes the existence of a Security domain that protects specific operations, but the developers of the Bank model only provide for identity verification, then there is missing functionality in the system.