"Soft" doesn't mean optional: lessons from scheduling real people

I build a CP-SAT scheduler for a 35-person healthcare support team. It replaced a greedy heuristic that could not reach a fully valid schedule in tightly constrained months. CP-SAT encodes every hard rule as a constraint, and an independent validator checks each solved roster, so correctness doesn't depend on the solver being right.

Then a manager asked for a rule to be soft: "a very heavy soft rule, we'll be very pleased if it applies." My first instinct was a small penalty term. That would have been wrong.

What they actually meant

• Not a hard constraint: a month that can't satisfy it should still produce a schedule rather than come back infeasible.
• Ranked above every optimization goal, so no gain elsewhere can pay for breaking it.
• Still reported: the validator flags each violation as a warning a human can see and act on.

That's a priority ordering, not a weight. Once I modelled it that way, the conversations with managers got easier too. We stopped discussing coefficients and started discussing which rule beats which.

Stakeholders don't speak in penalty weights. They speak in what they'd be embarrassed by.