Skip to main content

Overview

When the VRP solver cannot assign certain jobs to any resource, it can now provide detailed reasons explaining why each job remains unassigned. This feature helps identify scheduling conflicts and constraints preventing job assignments.

Enabling Unassigned Reasons

To receive unassigned reasons in your response, enable the explanation feature with the onlyUnassigned option:

Example Request

Here’s an example where jobs cannot be assigned due to time window conflicts:

Example Response

The response includes an unservedReasons map that explains why each unassigned job could not be scheduled:

Common Unassigned Reasons

Use Cases

  1. Capacity Planning: Identify when you need more resources or extended shifts
  2. Schedule Optimization: Understand which constraints are most restrictive
  3. Customer Communication: Provide clear explanations for service limitations
  4. System Debugging: Quickly identify configuration issues preventing assignments

Incomplete Results

Reasons are derived from the alternative positions computed for each unassigned job, and that analysis is bounded (see Limiting the cost of alternatives). Every unserved job still gets an entry in unservedReasons, but a job that was not analysed gets an empty list - which is indistinguishable from “no hard constraint blocked this job”. The solution carries an explanationTruncation object whenever that can have happened:
An empty reason list only means “no blocking hard constraint” when explanationTruncation is absent. Raise maxExplainedJobs and maxDurationMillis if you need the full picture on a large instance.

Performance Considerations

  • Setting onlyUnassigned: true improves performance by only analyzing unassigned jobs
  • For large problems, consider using this feature selectively during debugging
  • The defaults (maxDurationMillis: 30000, maxExplainedJobs: 500, maxAlternativesPerJob: 25) keep the analysis bounded; without them a heavily unassigned instance can produce gigabytes of alternatives
  • The explanation process runs after the main optimization, so it doesn’t impact solution quality. It impacts latency however.