Ok let me try and answer some of your questions:

1. Amongst other objects there is a Dim application and contract as well as a Fact application (granularity is 1 record per application) and contract (1 record per contract). Fact Application contains the ApplicationID while Fact Contract contains both the ApplicationID and ContractID.
2. The fact application will start being populated as soon as the application comes in
3. When a contract is signed it will be tracked in the fact contract table. So a fact table to represent each business process at the lowest grain available.
4. As the various things change on on the app or the contract such as the status then this will be tracked in the dimension as a type 2 and also a new record added to the fact table 
5. There is a bridge table to marry up the application & contracts to the customer dimension to resolve the M2M relationship
6. You are absolutely correct in stating an accumulating snapshot table. That is certainly the plan along with the existing fact tables mentioned above. An application and status moves through it's own stages during the process independent of each other and can overlap and iterate back to previous statuses etc.