There as many contract types as are passed through your contract-classifying algorithm. What is probably of more interest for software construction is awareness of probable market. E.g. it would be a waste of time to try to construct a program to write a contract where Delta Airlines will buy some number of airplanes from Boeing, because both sides will have a crew of professionals hammering out the details and looking for some advantage based on... whatever. The most likely market focuses on people who don't want to professionals to construct a contract – your plumber, a produce-seller etc. There are other types of contracts which very common but probably irrelevant: TOS contracts, real estate contracts... The reason why these are irrelevant to your interest is that the customer plays virtually no role in writing the contract, and the vendor has professionals who work through a standard contract.
If you want a quick taxonomy of "ordinary business" contracts that don't involve lawyers, I would say "service" and "sales". The standard advice that we would give anyone is "consult your attorney". If you are buying a bushel of peaches, you really don't need a written contract, you just decide if you like the peaches and hand over the money if you do. You do need a written contract if you run a peach cobbler restaurant and you need some quality and delivery standard to be met. But it would be unusual for a buyer to present a contract to a vendor. So the auto-drafter should anticipate customer objections and construct the contract to be acceptable to the customer.
That said, you could look here at a collection of templates applicable to a range of contractual relations. I'm not approving of their product, I'm just reporting how drafting can be semi-automated.
