Decision objectives: define the action before optimizing a score

Last updated: 5 Oct 20265 min read

tutorial

An optimization model needs a decision unit, a measurable outcome and an objective tied to the real action.

Specify what can change

A support team has reviewer hours to assign across ordinary and partner cases. The decision variables are counts of cases to review in each queue, not predicted defect probabilities. Predicted risk can inform expected benefit, but it is an input to the decision rather than the decision itself. One unit of action is one completed review with a known time cost. A decision threshold is a different way to map scores to actions when capacity constraints are absent.

Choose one accountable outcome

The team wants to prevent customer escalations, so it estimates prevented escalations per reviewed case. A high defect-detection count is not identical if some detected defects would never escalate. Record the outcome window and how the benefit estimate was obtained. If it came from a small observational sample, show uncertainty and avoid treating point estimates as certain. The sampling frame limits where the estimate applies.

Check the arithmetic and units

Suppose one ordinary review takes two analyst-hours and is expected to prevent 1.4 escalations; one partner review takes three hours and is expected to prevent 2.3. An allocation of four ordinary and three partner reviews uses 17 analyst-hours and has modeled benefit 12.5 prevented escalations. The arithmetic is simple; the hard part is defending the estimates and ensuring that a half-completed review is not counted as a completed action.

Separate objectives from constraints

Review capacity is an upper bound. Minimum coverage for the partner queue is a requirement. Neither should be hidden as an arbitrary penalty in the objective if violating it is unacceptable. A weighted score that mixes labor cost, risk and fairness without units can select a numerically attractive but operationally invalid allocation. Constraint checks keep those rules visible.

Keep a baseline

Compare the proposed plan to the current scheduling rule and to a simple first-come policy under the same budget and case mix. An optimizer that improves a made-up objective while reducing the real service outcome is a failed model. Report predicted benefit, actual capacity used and the operational baseline together.

Implementation

def allocation_totals(ordinary_reviews, partner_reviews):
    if min(ordinary_reviews, partner_reviews) < 0:
        raise ValueError("review counts must be nonnegative")
    analyst_hours = 2 * ordinary_reviews + 3 * partner_reviews
    expected_prevented = 1.4 * ordinary_reviews + 2.3 * partner_reviews
    return analyst_hours, expected_prevented

hours, benefit = allocation_totals(4, 3)
assert hours == 17 and round(benefit, 1) == 12.5

Performance and operating cost

Evaluating one two-queue allocation takes O(1) time and space. For Q queues the objective calculation is O(Q); searching all feasible plans is a separate problem whose cost depends on variable bounds and whether fractional or integer actions are allowed.

Common Mistakes

Do not optimize a model score without defining the action it controls.
Do not treat predicted benefit as measured benefit.
Do not hide mandatory coverage inside an arbitrary objective penalty.