I work a lot with subcontractors.
If the above are a separate systems, and you pay based on milestone being reached, then I expect at each milestone the finished product, that passes "confidence test" (i.e. no bugs with straight forward expected functionality, but may find bugs if trying to break the system).
In this case if they walk away after you have paid for System A - you do have System A completed.
If the milestones are checkpoints of the one bigger system, then I treat them in a bit more relaxed way, more like "are we on track or are we late", and would expect functionality to be done, but perhaps may have more bugs as the proper testing may happen when the whole system is finished.
If I know the subcontractor, I may build in my past experience with them into milestone definition. If I have not worked with them before, then I would be more strict on milestone deliveries.
I would rather be more strict with the contract, and then I could be (if I wish) more relaxed when deciding whether the milestone is reached or not, or even pay up at the milestone with some kind of temporary "waiver" if everything was not delivered to the expected/defined standard.
At milestone 1, do you expect System A to look pretty much like the mockups provided, or do you accept that the contractor still needs to do quite a bit more to move elements around and make it pretty?
As I said, I would expect the finished system. But you could break this into two milestones 1a and 1b, where 1b would be "make it pretty" or have "make it pretty" included in milestone 3 or even as a separate milestone at the end. It should be defined somewhere though!
