Constraint feasibility and slack: reject impossible plans early

Last updated: 5 Oct 20265 min read

tutorial

A feasible plan satisfies every declared operational bound before its objective value matters.

Write inequalities in the right units

Let ordinary and partner reviews use two and three analyst-hours respectively. With 23 available hours, 2 × ordinary + 3 × partner must be at most 23. If the partner contract requires at least four reviews and ordinary coverage requires at least three, the minimum plan consumes 18 hours and leaves five hours of slack. Count reviews as nonnegative integers. The action unit keeps hours and cases from being mixed.

Test feasibility before seeking an optimum

A new policy might demand eight partner reviews and four ordinary reviews under the same 23-hour budget. That minimum consumes 32 hours, so no optimizer can satisfy it. Return an infeasible state with the conflicting requirements and required extra capacity. Do not accept a solver output merely because it returns numbers; inspect status and verify constraints independently.

Keep hard and soft bounds apart

Some requirements are truly hard, such as legal handling limits or maximum available staff hours. Others are targets that can be traded off with an explicit cost, such as a preferred mix of work. Mark which is which. Softening a hard safety rule to make a model feasible is a policy change and needs approval outside the solver. A zero-slack plan may also be brittle when review duration varies.

Report slack in human terms

For a feasible plan of five ordinary and four partner reviews, 22 of 23 hours are used, leaving one analyst-hour; partner coverage is exactly at the minimum of four. Those two facts explain different risks. An extra urgent partner case cannot fit, while one ordinary review may also exceed the budget. Sensitivity work should perturb hours and demand separately. Scenario checks show whether the decision survives those changes.

Validate the final schedule

After a solver or planner proposes an allocation, recompute every left-hand side from the released plan using the same unit definitions. Rounding a fractional result to integers can break a bound. Also check that each queue has enough eligible cases to fulfill its assigned count; a plan cannot review cases that do not exist.

Implementation

def validate_review_plan(ordinary_reviews, partner_reviews, available_hours=23):
    if any(not isinstance(count, int) or count < 0
           for count in (ordinary_reviews, partner_reviews)):
        raise ValueError("whole nonnegative review counts required")
    used_hours = 2 * ordinary_reviews + 3 * partner_reviews
    return {"feasible": (ordinary_reviews >= 3 and partner_reviews >= 4
                         and used_hours <= available_hours),
            "hour_slack": available_hours - used_hours,
            "partner_coverage_slack": partner_reviews - 4}

assert validate_review_plan(5, 4) == {
    "feasible": True, "hour_slack": 1, "partner_coverage_slack": 0}

Performance and operating cost

Checking C constraints over Q decision variables is O(CQ) time in a dense representation; this fixed two-variable check is O(1). Feasibility reporting should preserve each constraint residual, not only one Boolean, so operators can diagnose an impossible plan.

Common Mistakes

Do not ask an optimizer to repair mutually inconsistent hard constraints.
Do not round a fractional plan without rechecking capacity and minimums.
Do not call a zero-slack schedule safe when work duration is uncertain.