Feature engineering and preprocessing · insight-1135
Re-derive constraint signs whenever a feature is redefined, reversed or re-encoded
- Evidence type
- practitioner heuristic
- Difficulty
- easy
- Roles
- ML engineer, Data scientist
- Industries
- finance, aviation
Summary: situation, action, reason, boundary
Situation
A model has a monotone constraint vector, and a refactor replaces a feature with its reversed definition, such as discount percent for fare or days left for days elapsed.
Action
Key constraints by feature name where the library allows it, store the intended direction as a business statement with the feature definition, and add a test on synthetic data that checks the learned direction.
Reason
A constraint is a sign per feature position or name; the sign carries a business meaning that a changed definition or column order silently invalidates.
Boundary
XGBoost, LightGBM and scikit-learn boosting with constraint vectors, especially pipelines that reorder or re-encode columns.
Symptom or risk
The old sign now forces the opposite direction, so the booster flattens the feature or fits a worse model and nobody notices because the code still runs.
Exceptions
Models trained without constraints, which have no sign to audit; the risk starts when constraints and column definitions can change independently.
Trade-offs
Name-keyed constraints are not available in every library, and tests add maintenance.
Pitfalls
Passing a constraint list in the order of a column list that a transformer has since reordered.
Lessons and concepts
Claims and their sources
XGBoost monotone_constraints take 1, -1 or 0 per feature and can be given as a vector or keyed by feature name.