For each problem domain you've identified, you must identify the metamodel that you want to use for modeling. That is, you must identify the modeling language you want to use to capture formalized knowledge models for each of your domains. In the general case, this language can be any profile of any defined language that can be captured in such a way that it can be transformed.
For example, you may choose to formalize knowledge of a bank without thinking about security of certain transactions or remotely accessible objects. In making this choice a set of assumptions, really you've defined a modeling language for the construction of the bank. You'll have to make the same decisions for each model you've identified.
Note that each such assumption becomes a requirement on some domain on which you depend. If you "assume away" the problem of security, for example, then something, somehow, has to take on this job.
When you arrange multiple mapping functions into a chain, the source and target metamodels have to match, as do the marking models that each mapping in the chain uses. The mapping chain should be able to operate solely from defined models, mapping chains, and marks supplied by the developer. Mapping functions should produce all marks that the subsequent mappings along the chain require as input. This implies that the marking models match up.
The interfaces exposed by the targeted platforms are those you will implement against. For example, your model should look the same no matter which operating system you intend to use, because you're using a defined API. The mapping functions and associated marking models, then, transform to those APIs.