Not Every Business Rule Is a Constraint

A lot of optimization models become complicated for a simple reason: every sentence the business says gets translated into a constraint.

“We want at least four weeks of supply.”

Constraint.

“We normally order once a month.”

Constraint.

“We prefer full truckloads.”

Constraint.

“We try not to change the vendor plan too much.”

Constraint.

Six months later, the model has 400 rules, half the organization believes each one is mandatory, and nobody can explain why the model is infeasible when demand spikes.

This is not really a solver problem. It is a problem-framing problem.

A mathematical constraint means something very specific: the optimizer is forbidden from violating it, regardless of the economics. That is a much stronger statement than “the business prefers this.”

If you do not separate physical limits, contractual requirements, operational preferences, and inherited habits, the model will eventually force you to do it the hard way.

Start with the decision

Suppose we are building a weekly replenishment model for a supplier shipping multiple SKUs into a distribution center.

For SKU $i$ and week $t$, we might decide:

• $q_{it}$: quantity ordered,
• $y_{it} \in {0,1}$: whether an order is placed,
• $I_{it}$: ending inventory,
• $s_{it}$: unmet demand or lost sales,
• $e_{it}$: expedited quantity,
• $v_{it}$: violation of some preferred operating rule.

A basic inventory balance might be

$$ I_{i,t} = I_{i,t-1} + A_{it} - D_{it} + s_{it}, $$

where $A_{it}$ is arriving supply and $D_{it}$ is demand.

Now the business gives us several rules:

1. A container cannot hold more than 20,000 kg.
2. SKU A is normally kept above two weeks of supply.
3. The vendor prefers one purchase order per month.
4. Contractual MOQ is 500 units.
5. Buyers dislike changing an order after it has been communicated.
6. The DC has 12,000 pallet positions.

These sentences do not belong in the same mathematical category.

The container capacity and warehouse capacity are physical limits. The MOQ may be contractual. The two-weeks-of-supply rule may just be a proxy for stockout risk. Monthly ordering may be a historical operating habit. Order stability is valuable, but perhaps not at any price.

If we encode all six as hard constraints, we have already made several economic decisions without admitting it.

Ask one question: what happens if we violate it?

For every proposed rule, ask:

If violating this rule creates enough value, are we allowed to violate it?

If the answer is genuinely no, it is a candidate for a hard constraint.

If the answer is “yes, but it hurts,” it probably belongs in the objective or in a controlled relaxation.

If the answer is “we have never tried,” it may be a policy assumption that should be tested rather than encoded as truth.

This simple question exposes a surprising amount of fake rigidity.

Consider a preferred minimum inventory rule:

$$ I_{it} \geq L_{it}. $$

If $L_{it}$ represents a physical reserve that legally cannot be consumed, fine.

But if $L_{it}$ is a safety-stock target, the constraint says something much stronger: even if inventory is scarce, another SKU has enormous margin, this SKU has almost no stockout consequence, and the supplier is capacity constrained, the optimizer must still preserve $L_{it}$.

That may be exactly the opposite of the decision you want.

Hard constraints describe the feasible world

A useful mental model is that hard constraints should mostly describe what the system can do, not what somebody historically likes to do.

Typical hard constraints include physical conservation laws, warehouse or machine capacity that truly cannot be exceeded, legal restrictions, contractual commitments that cannot be broken within the decision process, integrality requirements, pack-size logic, material compatibility, and already-committed decisions that are genuinely frozen.

For example, if each purchase order must satisfy an MOQ $M_i$:

$$ q_{it} \geq M_i y_{it}, $$

with

$$ q_{it} \leq U_i y_{it}. $$

If the MOQ is genuinely enforced by the vendor, that is structural business logic.

But even here, verify the real process. Some “MOQs” are contractual minimums. Others are guidelines. Others can be violated with a surcharge. Those are three different models.

The model should represent the mechanism, not the spreadsheet label.

Preferences belong in economics

Suppose the business prefers at least $L_{it}$ units of inventory but can operate below it.

Introduce a shortfall variable:

$$ v_{it} \geq L_{it} - I_{it}, $$

$$ v_{it} \geq 0. $$

Then charge a cost:

$$ \min ; \text{operating cost} + \sum_{i,t} p_{it} v_{it}. $$

Now the optimizer can violate the target when the alternative is worse.

That does not mean the penalty should be arbitrary. The penalty is an economic statement. If $p_{it}$ is huge, the rule is almost hard. If it is small, the optimizer will violate it readily.

The useful question becomes: what is the actual consequence of violating the preference?

Maybe falling below the inventory target increases expected lost margin. Maybe breaking an ordering cadence creates a $300 administrative cost. Maybe changing a committed PO creates a vendor disruption cost. Maybe using an emergency carrier costs an extra $1.40 per unit.

Those quantities belong in the model because they describe consequences.

“We really care about it” is not a unit of cost.

Do not hide uncertainty behind deterministic rules

Many hard business rules are really crude substitutes for uncertainty.

Safety stock is the obvious example. A business worries that demand might exceed forecast, so it creates a minimum-inventory rule. That may work as a rough policy, but the real concern is not the inventory target. The concern is the economic consequence of uncertain demand.

Suppose demand is represented by scenarios $\omega \in \Omega$ with probabilities $p_\omega$. A policy can be evaluated through expected cost:

$$ \min_x \sum_{\omega \in \Omega} p_\omega C(x, \omega), $$

where $x$ contains the decisions made before demand is known.

The scenario cost can include lost sales, holding cost, expedites, markdowns, and other consequences.

Now the optimizer can distinguish between two products that both have a nominal four-week safety-stock rule but completely different economics and uncertainty.

One may have high margin, volatile demand, and a six-month replenishment lead time. The other may have low margin, stable demand, and next-day replenishment.

A hard four-week rule treats them as equivalent because the rule threw away the information that actually matters.

This is a recurring pattern in supply chain models: a target often exists because the original decision system could not model the underlying uncertainty or economics.

Do not automatically preserve the target when you build a better decision model.

Soft constraints are not free passes

There is a bad version of soft constraints too: add slack to everything, assign giant penalties, and hope the solver figures it out.

That produces a model that is technically feasible but conceptually meaningless.

A good soft constraint needs three things.

First, the violation must have an interpretable unit. If $v_{it}$ is units below a preferred inventory floor, that is clear. If it is “amount of badness,” it is not.

Second, the penalty should represent a real tradeoff or an explicit priority. Do not use $10^9$ because it looks important. Huge penalties can also create numerical problems and make the objective difficult to reason about.

Third, violations must be visible in the output. A model that silently relaxes rules is dangerous. If the optimizer breaks a preferred service floor by 800 units, the operator should see that fact and the economic reason.

A soft rule is useful precisely because it exposes the tradeoff.

Sometimes the right answer is lexicographic priority

Not every preference can be credibly converted into dollars.

Suppose the organization has a genuine hierarchy:

1. avoid violating regulatory requirements,
2. minimize customer shortages,
3. minimize premium freight,
4. reduce plan changes.

If the hierarchy is real, a lexicographic or hierarchical objective can be cleaner than inventing enormous weights.

Conceptually, solve:

$$ \min f_1(x), $$

then among solutions that preserve the acceptable value of $f_1$, minimize

$$ f_2(x), $$

and continue through the priority levels.

Modern MILP solvers support multi-objective structures, but the modeling question comes first: is the priority truly lexicographic?

If the business would accept one additional unit of shortage to save $2 million of freight, then shortage is not infinitely more important. There is a tradeoff, whether or not anyone has written it down.

Policy structure can be better than hundreds of rules

Another common failure is trying to control optimizer behavior with piles of constraints instead of defining a clean policy.

Suppose buyers want stable ordering. The first instinct may be to add constraints limiting week-to-week changes:

$$ -q^{\Delta} \leq q_{it} - q_{i,t-1} \leq q^{\Delta}. $$

That guarantees stability, but it may also force terrible decisions when demand changes.

An alternative is to define a policy with a small number of tunable parameters. For example:

• review every $k$ weeks,
• order up to a target based on current state,
• apply a fixed order cost,
• penalize changes to previously communicated quantities,
• allow emergency overrides when marginal value exceeds the disruption cost.

Then test that policy in simulation.

The difference matters. A hard constraint says, “this behavior is impossible.” A policy says, “this is how we normally act given the state of the system.”

Real operations contain both. Mixing them creates brittle models.

Constraints interact, so evaluate them together

A rule that looks harmless by itself can become destructive when combined with other rules.

Imagine a vendor with ten SKUs and these requirements:

• each SKU must maintain three weeks of supply,
• orders must meet SKU-level case packs,
• the vendor has a shared MOQ,
• the DC has limited inbound capacity,
• the buyer can place only one PO per week,
• a cash budget caps total purchasing.

Each rule may have a reasonable origin. Together they can create a model with almost no useful flexibility.

This is why constraint review should not be a line-by-line legal exercise. You need to understand the feasible region created by the entire system.

Useful diagnostics include:

• how often each constraint binds,
• how much objective value changes when a limit is relaxed,
• which constraints appear in infeasibility diagnostics,
• how much slack is used in soft constraints,
• which rules cause discrete jumps in the solution,
• whether removing a rule materially changes decisions.

A rule that never binds may be harmless clutter. A rule that binds constantly may be either genuinely important or a hidden policy knob controlling the entire system.

You need to know which.

Use shadow prices carefully

For continuous constraints, dual values can help quantify the marginal value of relaxing a limit.

If a capacity constraint is

$$ \sum_i a_i x_i \leq C, $$

a dual value of $\lambda$ in the LP relaxation tells us the local objective improvement associated with one additional unit of $C$ under that relaxation.

That can be useful evidence when discussing whether a constraint should be expanded or softened.

But do not oversell it in a MILP. Integer decisions, MOQs, fixed charges, and activation logic create discontinuities. An extra unit of capacity may be worth nothing until it crosses the threshold required to open another discrete action.

For important business rules, perturb the actual model and re-solve. Better yet, evaluate the resulting policy under realistic scenarios.

The question is not just “what is the dual?” The question is “what decisions become available if this rule changes, and what are those decisions worth?”

Simulation is where policy rules get challenged

A deterministic optimization run can make a bad rule look perfectly reasonable because it evaluates only one assumed future.

Simulation gives you a much better test.

Take a candidate policy and replay it across demand, lead-time, supply, and cost scenarios. At each decision epoch:

1. reveal only information that would actually be available,
2. construct the current state,
3. solve or execute the policy,
4. apply the resulting action,
5. simulate the next transition,
6. record economic and operational outcomes.

Then compare alternative rule structures.

For example:

• hard four-week inventory floor,
• soft inventory floor with a calibrated penalty,
• no inventory floor, but explicit shortage economics,
• scenario-based replenishment with no safety-stock target.

Measure total contribution, lost sales, inventory, expedite spend, rule violations, cash usage, and tail outcomes.

This turns a philosophical argument about “best practice” into an empirical policy comparison.

Metrics should reveal the tradeoff

Do not evaluate a soft-constraint design only on objective value.

Track at least the economic outcome, the frequency and magnitude of violations, operational stability, service outcomes, inventory exposure, premium actions such as expedites, and tail risk.

For each rule $r$, I like to log something like:

$$ \text{violation rate}_r = \frac{\text{decision periods with violation}}{\text{total decision periods}}, $$

and

$$ \text{average violation}_r = E[v_r \mid v_r > 0]. $$

Also record the economic cost attributed to the violation and the alternative cost that was avoided.

If the model violates a preferred minimum inventory level 3% of the time and doing so avoids massive premium freight during supply disruptions, that may be exactly what you want.

If it violates the rule 90% of the time, either the penalty is wrong, the target is nonsense, or the rest of the model makes the target structurally unrealistic.

All three are useful findings.

Production implementation needs an exception ledger

In production, do not return only the final order quantities.

Return the decisions and the exceptions.

For every soft rule, log:

• rule identifier,
• entity and time period,
• preferred bound,
• realized value,
• violation magnitude,
• penalty or priority,
• major competing constraint,
• objective impact when practical.

This gives operators a reason to trust the system. It also creates a dataset for improving the model.

After three months, you can ask whether a supposedly important rule is violated constantly, whether buyers repeatedly override certain penalties, or whether a particular capacity limit drives most expensive exceptions.

The optimization system becomes an instrument for learning about the operation instead of just an order generator.

Common failure modes

Everything is hard. The model becomes infeasible or produces bizarre decisions because preferences are treated as laws.

Everything is soft. The model is always feasible but can violate things that are genuinely impossible or prohibited.

Penalty values are arbitrary. A developer picks 1,000 because 100 felt too small. Nobody knows what tradeoff the number represents.

Giant penalties simulate priorities. This creates numerical ugliness and hides whether the business priority is actually absolute.

Targets substitute for economics. Service levels, weeks of supply, utilization targets, and cadence rules survive long after the model could represent the underlying consequences directly.

Violations are hidden. The model relaxes a preference, but the downstream user sees only the final decision and assumes every rule was satisfied.

Rules are reviewed independently. Nobody tests how MOQ, capacity, cadence, inventory floors, and budget constraints interact as a system.

The current process is treated as ground truth. A rule exists in today’s spreadsheet, so it is copied into the optimizer without asking why it exists.

What I would do in practice

Before building the MILP, create a rule inventory. For every proposed constraint, write down its source, its unit, who owns it, what happens when it is violated, and whether violation is physically impossible, contractually prohibited, economically costly, or merely undesirable.

Then classify it into one of four buckets:

• hard feasibility — the system cannot or may not violate it,
• priced consequence — violation is allowed and has an economic cost,
• priority rule — violation is allowed only after higher-priority outcomes are protected,
• policy assumption — a behavioral choice that should be tested in simulation.

Build the smallest model that represents the actual decision and the actual feasible world. Add preferences deliberately. Give every soft rule an interpretable violation variable. Log every violation. Stress the model under scenarios where rules conflict.

Then remove rules one at a time and see what happens.

That last step is underrated. If deleting a “critical” business rule changes nothing, you learned something. If deleting it increases expected value by 15% with no meaningful operational damage, you learned something more important.

The goal is not to encode every rule the organization has accumulated.

The goal is to build a decision system that understands what is truly impossible, what is merely expensive, and what is just habit.