Interpret results and feasibility
Understand the difference between execution success, a feasible plan and evidence of optimality.
Three different questions
Did the request execute? Did the resulting plan satisfy the modeled requirements? Is there evidence that no better plan exists? These are separate questions.
The application should evaluate the returned contract rather than reducing all of these outcomes to a single success flag.
- Execution status tells you what happened to the run.
- Feasibility checks evaluate the plan against the modeled requirements.
- Optimality evidence, when provided, supports a stronger conclusion about solution quality.
Read the evidence for your engine
The local rostering path evaluates output through shared feasibility checks. Read the diagnostics and any reported repairs along with the final assignments.
Result shapes and certificate coverage vary by problem family and release. A certificate evaluates the modeled constraints and supplied records; it cannot prove that your input captures every real-world requirement.
Make acceptance an application policy
Preserve the input reference, model version, selected engine, options, returned status, objective and diagnostics. Route unresolved results to a person or an explicit failure path.
Test the consumer with infeasible instances and partial or interrupted runs. Never publish a best-effort plan as fully feasible without checking its returned evidence.