Handle errors and refusals
Distinguish invalid requests, unavailable capabilities and problems with no acceptable result.
Validate before execution
Missing required problem data and unsupported problem types are explicit failure conditions. The service uses typed validation errors, including missing_problem_data and unsupported_problem_type on relevant routes.
The local rostering path rejects an unknown engine with rostering_unknown_engine. Surface the diagnostic so an operator can repair the request. Error envelopes are route-specific; use the schema for the API version you consume.
Infeasibility is useful information
A request can be structurally valid and still have no plan that satisfies the modeled requirements. For example, required coverage may exceed the eligible capacity available.
Distinguish a proven contradiction from a search that simply did not find a feasible answer within its budget. Do not claim mathematical infeasibility unless the returned evidence supports it.
Retry the right failures
Do not retry unchanged invalid input. Preserve diagnostics, correct the data or model, then submit a new intentional run.
For transient service failures, use the documented idempotency and retry behavior of your deployment. A client timeout does not prove that the solve never started.