When should a requirement be a hard constraint rather than a penalty in the objective?

## The decision Every real optimization has requirements that did not come from the mathematics: a budget, a fairness target, a latency ceiling, a regulatory limit, an operational rule. For each one you choose a modelling posture. Either it enters as a **hard constraint**, restricting the feasible set so no violating solution can ever be returned, or it enters as a **penalty term** in the objective, discouraging violation at a price you set. This is a judgment call, and it is usually made implicitly by whoever writes the model first. ## The case for a hard constraint **It is a guarantee.** The output is compliant by construction. You do not have to monitor whether the penalty weight was high enough, and you do not have to explain to a regulator or a customer why the system produced a violating answer on some particular day. For anything with a legal, contractual or safety character, this is close to mandatory: pricing a violation implies you are willing to accept it at some price, and often you are not. **Infeasibility is informative.** When a hard-constrained problem returns no solution, it has told you something true: the requirements as stated cannot all be met with the current inputs. That is a signal worth surfacing, not an inconvenience. **The multiplier prices it for free.** Solving the hard version returns a shadow price on the constraint - how much objective you are giving up per unit of the requirement. That number is exactly what stakeholders need to renegotiate the limit, and it exists only if you modelled the requirement as a constraint. ## The case for a penalty **It always returns something.** Production systems run on data that shifts. A constraint set that was comfortably satisfiable at design time can become infeasible, and a solver returning nothing is a hard outage. A penalized objective degrades: it returns the best compromise it can find, and you observe the violation as a number instead of a failure. **It expresses genuine tradeoffs.** Many requirements are preferences with a real exchange rate - smaller solutions are better, smoother schedules are better, fewer changes are better - and pretending they are absolute thresholds forces you to invent a cutoff nobody can defend. A penalty states the exchange rate directly. **It is easier to solve.** Unconstrained or lightly constrained objectives are attackable by general-purpose methods; hard constraints demand solvers that respect the feasible region and can be far more expensive. ## The costs on each side Hard constraints risk **infeasibility**, and an over-constrained model can also be brittle in a subtler way: it may sit exactly on several boundaries at once, so a tiny data change swings the solution far. They also encourage requirement inflation, since each stakeholder's ask is cheap to add until the whole set becomes unsatisfiable. Penalties risk **silent violation**. The weight has units of objective per unit of violation, no natural scale, and it interacts with feature scaling and data volume, so a weight tuned on one dataset can be badly wrong on the next. Nobody outside the modelling team can read a penalty weight and know what behaviour it implies. And unless you monitor violations explicitly, the requirement quietly stops being met with no alarm. ## The hybrid worth knowing The standard middle path relaxes a hard constraint by allowing a measured violation and charging steeply for it. The requirement is expressed at its stated level, the amount of violation becomes an explicit quantity you can monitor and report, and the problem stays feasible under any input. This gives you the constraint's interpretability with the penalty's robustness, and the size of the violation term becomes a first-class metric rather than a hidden consequence of a weight. ## A workable process 1. **Classify the requirement.** Absolute or negotiable? A limit someone external will audit is absolute. A preference the team invented last quarter is negotiable. 2. **Model it hard first, even if only offline.** Solve, and read the multiplier. If the requirement costs almost nothing, keep it hard - the guarantee is free. If it costs a great deal, you have quantified the tradeoff and can take a real number to the people who set the requirement. 3. **Check feasibility under stress.** Replay the constraint set against historical and adversarial inputs. If it goes infeasible under plausible conditions, either relax it or add a monitored violation term. 4. **Instrument whatever you soften.** Every penalized requirement needs a dashboard number for how often and how badly it is violated, or it is not really a requirement. 5. **Revisit as data drifts.** The active set changes. A constraint that never bound may start binding, and one that always bound may go slack - which changes both the cost and the argument for keeping it hard. ## What an interviewer is listening for Not a rule, but a framing: that you recognise the difference between a guarantee and a price, that you know infeasibility is a real production failure mode rather than a theoretical curiosity, that penalty weights are uninterpretable without context, and that the multiplier is the bridge between the two views - the number that tells everyone what the requirement actually costs.