As a practical detail, I'm wondering if it always makes sense to wrap your predictor in a simple if-then based predictor. If your learned model makes bad predictions in certain specific cases, you can "cheat" with Boolean logic. This could also be useful when the business has a special case that doesn't follow the main patterns.
The if-then predictor is called an expert system and it is a kind of model. Combining multiple models is called ensemble model. Here, this is how the idea can sound smart, not like cheating. ;-)
On a more serious note - as always, it depends. On the logic, on the company processes and skills, how frequently will the logic change, visibility into the decision making, ... It may be a good idea or you may bring in a lot of manual work.
This is almost always a very bad idea because the if/then condition you describe is business logic - as in, how do you recognize the business situation when you want to decline a prediction, and how does that change?
It is very complex because most of the time there is no simple rule such as a threshold on the confidence score of the prediction. In practice it might be more like, “if the user has more than 7 items in their cart and if the user is not a returning customer that filled out personal data and the value of their cart is greater than $100 and they have not put a new item in the cart for 2 minutes, and the confidence score of the predictor is less than 0.4, THEN don’t show the next recommended item, just display a checkout link.”
And the number of items, the cart value limit, the time since last item-add, etc., will all be hotly debated by product management and changed 5 times every quarter.
In grad school there was a professor who said of machine learning that “parameters are the death of an algorithm” - so you want to avoid coupling extra business logic parameters tightly with the use of machine learning models.
I understand it may not be recommended in complex situations, such as you described, but I think @steve_g's idea may be interesting for some scenarios.
I work in automatic train traffic planning, mainly for heavy-haul railways [1]. Recently, we've been working on a regression model to predict train sectional running times based on historical data.
As our tool is used during real time operation, we can't risk the model outputting an infeasible value. So we're thinking about defining possible speed intervals, e.g. (0km/h, 80km/h] for ore trains, and falling back to a default value if the predicted running time causes the speed to fall out of this range.
Might want to look at 'guarded' learning. This https://arxiv.org/abs/2006.03863?context=cs.SE might inspire you. In one team we managed to train with both simulation and data and 'force' the trained model to infer within the 'security' simulation.
I think there might be some better research on this... Not bothered to look it up much.
To me this sounds like a bad misunderstanding of regression and your use case. If you need a system capable of predicting within an interval, you should use something different, for example you could use Bayesian regression with a prior that only has support on your permitted domain.
You very much should be choosing models that actually map to the physical reality of your problem domain, and not using something that is fundamentally unphysical for your use case, but attempting to correct it with hand made business logic.
Any thoughts on that?