Monotonic constraints: encode a justified business relationship

A monotonic constraint tells a model that its prediction may only move in one direction as a feature increases while other model inputs are held fixed. This can stabilize behaviour where the relationship is known and defensible. It can also force systematic error when the relationship bends, reverses or depends on another feature.

Test the rule in a case where truth is known

Our first synthetic case uses 101 evenly spaced inputs from 0 to 10. The noiseless target is 2*x; seeded normal noise is added to training observations. Two depth-limited regression trees are fitted: one unconstrained and one with an increasing constraint.

On a dense 1,001-point diagnostic grid, the unconstrained tree has two decreasing steps. The constrained tree has none. Against the known noiseless rule, grid RMSE falls from 1.0263 to 0.7126.

This is a useful constructed success. It does not prove the constraint from observed data. The relationship was authored into the generator.

The DecisionTreeRegressor documentation defines monotonic_cst values of increasing, unconstrained and decreasing. A constraint controls model behaviour; it does not establish a causal law.

Run a counterexample before trusting the safeguard

The second case keeps the same input grid and noise scale but changes the noiseless rule to (x-5)^2. The outcome decreases until five and then increases. An increasing-only constraint is false over the full range.

The unconstrained tree records six decreasing grid steps and known-rule RMSE 1.3356. The constrained tree records zero decreasing steps, exactly as requested, while RMSE worsens to 5.9701. Passing the direction check is not the same as fitting the real relationship.

from decision_cases import monotonic_case

r = monotonic_case()
assert r['grid_points'] == 1001
assert all(case['increasing_constraint']['decreasing_grid_steps'] == 0
           for case in r['cases'].values())
u = r['cases']['u_shaped']
assert u['increasing_constraint']['rmse_to_known_noiseless_rule'] > u['unconstrained']['rmse_to_known_noiseless_rule']
print(r)

The local lab records both outcomes. Its grid RMSE compares predictions with authored noiseless functions; it is a mechanism check, not a held-out service forecast.

Require a justification package

A constraint should name the feature, direction, applicable range and conditions held fixed. It should cite the domain rule or mechanism and identify exceptions. For example, more allocated capacity might reduce waiting time only until coordination overhead appears. A price relationship can reverse across segments because the observed variable stands in for product tier.

Validate the rule in raw data and with subject-matter review, while remembering that observational trends can be confounded. Then compare constrained and unconstrained candidates on untouched data, inspect residuals by range, and test the direction on a dense grid. Interactions deserve special attention: a global direction can hide a valid reversal for a subgroup.

Constraints may improve extrapolation behaviour, but a model can remain wrong while obeying them perfectly. Monitoring therefore needs both policy checks and outcome checks.

Exercise: restrict the U-shaped case to inputs above five and rerun the increasing constraint. State why a range restriction is part of the model contract, then add a validation row outside that range and decide whether to reject or route it.

NeuraPath's Data Science course connects algorithm controls with assumptions, counterexamples and deployment boundaries. A monotonic constraint earns trust through its justification and failure tests.

Continue learning

This article is part of the Supervised learning methods sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in Quantile regression for uncertainty-aware delivery estimates.
• Continue with Multi-output regression with shared and separate models.