It makes sense if you're trying to give the users the ability to pull in attributes on the contract as well attributes on the application. In meaning, you are capturing the journey from application to contract and you want to ensure when you join the contract records, you can also join the application details with those records. It's just a matter of how you are handling the capture of this journey in the fact table.

I would imagine you start populating the fact with that history as soon as the application comes in. This becomes a record without a ContractID. Then when that user does sign a contract, how do you handle the history from that point on? Does it become a new record where there is a ContractID with the ApplicationID? Do you update the previous application record with the ContractID? Or do you just delete the prior records and leave one record per journey with the ContractID and ApplicationID where the Type 2 Dimensions are the only details on that history? Either way, sounds like the history has to be recorded, just a matter of where.

I think for the most part, people track that history in the fact. In meaning, you are capturing every event, state, log that user makes on their journey in the actual fact table. That way you can see a clear history of steps from 0 to N of that user. You may have a date field, customerID field, applicationID field, contractID field, and other attributes with the metrics combined in that record. Where the application dimension may have details on the app and likewise of details of the contract it's respective dimension. Then Type 2 comes into play when details of that application change on the attribute side, not the metric side. Like a name change, martial status change, contract state change, etc.

While this may result in a lot of logs, that's what most are shooting for so they can then roll that history up any way they see fit to meet the needs of the business and how the business may change down the road. For example, going from a detailed history in the data warehouse to a summarized history in the data mart layer where it's easier to analyze and query into the visualization layer like SSRS, Tableau, PowerBI, etc.