Also, think modular. Nothing says a single monolithic built-on application that includes every case type that your production application uses must exist.

As you build your application you should be on the lookout for ways to simplify it. Two independent built-on applications that adhere to the Separation of Concerns principle would be easier to maintain and deploy than a single, twice-as-large, monolithic built-on application.

You should do the same for Data classes. Ask yourself what Data classes could be used by other applications within the organization/enterprise and what Data classes strictly pertain to the application you are building. Regarding enterprise-shareable Data classes, you need to decide whether to have the enterprise COE take ownership of them, or have the application you are building maintain ownership.

Using one ruleset for the application rule, its workpool class, and its application-level data classes helps to keep code modular. The same is true for using a different ruleset for each case type.  If  later you find that certain cases types are small and unlikely to be reused by other applications go ahead and merge them into the single ruleset to simplify maintenance.

Should the situation arise where an application similar to the one you have constructed is desired, by having used a modular approach, you would already possess the building blocks to construct it.  Every building block you have developed may not be needed by the new application, or a new building block might be needed. A modular approach is more flexible than asking a monolithic framework to contort itself in support of every future requirement. You would always be maintaining two layers at the same time, never free just to extend "sideways" within the same application.