Which features would you place monotone constraints on in a boosted lending model, and what does that cost?

## What the constraint actually promises A monotone constraint on a feature says: holding every other input fixed, increasing this feature can never move the prediction in the forbidden direction. Non-decreasing means the score may rise or stay flat but never fall; non-increasing is the mirror image. It is a statement about the *shape* of the learned function, and it is a hard guarantee over the whole input space, not a tendency observed on a test set. It is worth being precise about what it does not promise. It says nothing about how *fast* the score rises - a monotone response can be flat for most of the range and jump at one threshold. It says nothing about the other features. And it says nothing about whether the model is well calibrated or accurate. ## How the split search enforces it The mechanism is local and cheap. When a node splits on a constrained feature, one child covers the lower values and one the higher. For a non-decreasing constraint the finder requires the lower child's leaf weight to be no greater than the higher child's, and it enforces this by bounding the weights rather than by rejecting the split outright: the two optimal Newton weights are clipped toward a common value if they came out in the wrong order, and candidate splits that cannot satisfy the bound at all are refused. Crucially, those bounds are then **inherited** downward, so a split deeper in the tree cannot quietly undo the ordering an ancestor established. Why the whole ensemble inherits the property is a one-line argument worth having ready: a boosted model is a sum of trees, and the sum of monotone-in-x functions is monotone in x. Make every tree monotone and the ensemble is monotone for free. No post-fit repair pass is needed, and none would work reliably if it were. ## Choosing what to constrain The temptation is to constrain everything that looks monotone in the data. Resist it. The right test is not "does the data trend this way" but "would we defend this direction in writing even if next quarter's data disagreed?" That narrows the list sharply. **Good candidates.** Relationships that are effectively definitional or that encode policy the business has already committed to. In small-business lending, a risk score that is non-decreasing in debt-to-income is a good example: however leverage interacts with everything else, a borrower carrying more debt against the same income should never be scored as safer. That is not a statistical finding, it is the shape the product is willing to stand behind. **Bad candidates.** Features whose true relationship is plausibly non-monotone. Tenure, account age, utilisation and many behavioural aggregates are often U-shaped or humped, and a constraint that flattens one arm of the curve does real damage. Also bad: features included mainly for their interactions, where the marginal direction is not even the quantity of interest. Keep the list short, keep it written down with a stated reason per feature, and treat adding to it as a decision with an owner rather than a tuning knob. ## What it costs The honest expectation is a small drop in the held-out metric. The constrained model is being optimised over a strictly smaller function class, so it cannot beat the unconstrained model on the training objective, and on validation it usually lands slightly behind. Sometimes it lands ahead, when the unconstrained model had been fitting noise-driven reversals in sparse regions - but do not promise that outcome in advance. The other costs are subtler. A wrongly signed constraint does not announce itself: the model absorbs the suppressed relationship through correlated features, so the metric barely moves while the reasoning behind individual scores becomes wrong. And a constraint on a feature that is genuinely humped forces the model to pick one arm, silently mispricing the other. ## What you buy Three things, roughly in order of value. **Defensibility** - the model's behaviour on that feature can be stated in a sentence and checked without running it. **Stability** - in regions with few training rows, an unconstrained boosted model will happily learn a local reversal, and every refit will learn a different one; the constraint removes that whole class of instability, which makes month-over-month model comparisons calmer. **Drift tolerance** - when the incoming distribution shifts into a thinly observed region, a constrained model degrades toward flat rather than toward an inverted response. ## Validating one Fit constrained and unconstrained side by side and compare two things, not one. First the held-out metric, to size the cost. Second the shape of the score against the constrained feature over its range with other inputs held fixed - if the unconstrained model bends decisively the other way over a well-populated region, the constraint is fighting real signal and you should ask why. Then check correlated features: if a partner feature's contribution changed noticeably once the constraint went on, the suppressed effect has relocated rather than disappeared. ## The judgment call The question a lead actually answers is not "which constraints does the data support" but "which behaviours must this model guarantee, and what is a guarantee worth?" In a regulated or high-scrutiny setting, a single decision nobody can explain costs more than a fraction of a point of held-out performance, and the constrained model is the right call. In a low-stakes ranking problem it usually is not. Decide that explicitly, write down the trade, and revisit it when the stakes change.