The list of time-splitting methods you can select for a model includes all the time-splitting methods in the system. Some time-splitting methods do not make sense for some targets and our UI still allow these combinations. This is confusing and leads to wrong uses of the system

A possible solution for this is to allow targets to specify a set of time-splitting method interfaces or parent classes so the choices in the time-splitting select menu are limited to the ones that match the specified interfaces.

The important point to discuss is the upgrade path. i.e. what should we do with models in the database whose time-splitting method will be invalid according to these new limitations imposed by the model targets? My best proposal is to disable them and remove the existing time-splitting method value as their state will be incorrect according to the new limitations. This proposal is based on the assumption that most models will not work anyway using incorrect time-splitting methods.

Most (if not all) the time-splitting methods in core already extend different base classes so this issue should be quite simple. A review and classification of the existing time-splitting methods and also potential new time-splitting methods should be part of this issue as one of the riskswe have is that we could limit too much what people can do. For example, if we limit students at risk to time-splitting methods that split the course in parts we won't allow someone to write a new time-splitting method that generates predictions for students at risk targets 34 days after the course start.