Picking a shipping lane is a constraint problem, not a price sort

Junior fulfillment systems pick a shipping lane by sorting carriers on price. That breaks the first time a package contains a battery, or is oversized, or needs a signature. Lane selection is really a constraint filter first, then a cost sort.

function chooseLane(order, lanes) {
  const eligible = lanes.filter(lane =>
    lane.serves(order.destination) &&
    lane.acceptsWeight(order.chargeableKg) &&
    lane.acceptsAttributes(order.attributes) && // battery, liquid, oversized
    lane.supportsTracking
  );
  if (!eligible.length) return null; // no lane can legally carry this
  return eligible.sort((a, b) =>
    a.costFor(order) - b.costFor(order) ||
    a.estimatedDays - b.estimatedDays
  )[0];
}

The order of operations matters:

1. Filter by hard constraints before price. A cheaper lane that cannot carry a lithium battery is not cheaper; it is a rejected shipment at the airport.

2. Chargeable weight, not actual weight, drives cost. Compute max(actual, volumetric) first. On bulky items the divisor (5000 vs 6000) can flip which lane wins.

3. Quote transit as a range, not a promise. "Estimated 6-11 days" is honest; "5-day delivery" is a guarantee you do not control once customs is involved.

4. Return null loudly when nothing qualifies. Silent fallback to a random lane is how sensitive cargo ends up on a passenger-air route that bans it.

We route across a carrier and partner network that we re-check lane by lane, and the same principle holds whether you have five lanes or five hundred: legality and capability first, price second. The bug is always the sort that skipped the filter.