Start with a real problem

Define what a good plan means

Start with the decision you need to make: assign people to shifts, allocate scarce inventory, or plan a set of routes. Separate the records you know from the choices you want the solver to make.

Write down the rules that make a plan acceptable and the preferences that make one acceptable plan better than another. A preference weight is not a substitute for a hard constraint.

• Inputs: the entities, quantities, time windows and relationships in your problem.
• Constraints: requirements that the selected problem model can evaluate.
• Objectives: the costs, coverage or preferences used to rank candidate plans.

Choose your integration path

Use the service when your application should submit work to a separate solver deployment. Use the embedded Python path when you need local execution and control over the process and its dependencies.

For either path, arrange access to the supported distribution and confirm your problem type, engine, license and compute requirements. The examples in these guides are integration templates, not a public anonymous endpoint.

Bring a representative dataset

Use a small, non-sensitive instance of your actual problem first. Include the awkward cases: missing skills, overlapping times, insufficient capacity and pinned decisions.

Retrieve the problem manifest from your service or distribution. Map your records to that schema before sending a solve request. Do not rely on demo data as a substitute for missing production records.

Decide how results will be accepted

Inspect the returned status, feasibility information, objective and diagnostics before applying assignments. Compare the proposed plan with a trusted baseline and have an operator review your first runs.

A successful HTTP request is not proof of feasibility. A feasible plan is not necessarily a proven global optimum. Your acceptance policy must use the evidence the selected engine actually returns.