Prescriptive AI is used to recommend actions based on objectives, data and constraints. In a business, the question may concern assigning jobs, scheduling equipment or deciding the order in which orders are prepared. Prediction can estimate demand or an operation's duration; optimisation searches for a plan that respects the conditions and pursues the criterion established by the business owner.
What must be defined before choosing a tool
A plan has variables we can decide: start time, assigned resource, quantity or operation order. It also has constraints, such as equipment capacity and dependencies between jobs. The objective may be total duration, lateness against deadlines or a defined cost. Formulate these elements separately so that the result can be checked.
Not every optimisation problem automatically represents AI. Mathematical programming, constraint programming and operations research can produce plans without a learned model. In an AI-enabled system, a model may estimate durations or demand, while a solver, the software component that solves the optimisation problem, calculates assignments. The project's description should reflect the mechanisms actually implemented.
A workshop, two resources and three operations
The demonstrative example uses resources A and B, each capable of executing one operation at a time. Operation P uses A for two hours. Operation Q uses B for two hours and can start only after P finishes. Operation R uses B for one hour and is independent of the other two.
The drawn schedule executes P between relative hours 0 and 2, R between 0 and 1, and Q between 2 and 4. Operations do not overlap on the same resource, and the requirement for P to precede Q is satisfied. B has an idle interval between 1 and 2. This gap is not an error: Q is waiting for P to finish.
A checkable schedule for two resources
With the objective of completing all three operations as early as possible, the compulsory chain of P followed by Q requires at least four hours. The plan reaches this bound, so it is optimal for this example's data and constraints. The calculation is a teaching demonstration. Adding equipment setup, different availability or commercial deadlines requires revising the model.
Mandatory constraints and working preferences
A mandatory constraint establishes which plans are permitted: two operations cannot occupy the same equipment simultaneously, or one stage must finish before the next. A preference influences the choice between permitted plans: fewer configuration changes or a more even allocation. Turning an obligation into a mere penalty can produce a plan unsuitable for the process.
| Requirement | Role in the model | Result check |
|---|---|---|
| One machine, one operation | Mandatory constraint | Intervals do not overlap |
| Q follows P | Mandatory dependency | Q start ≥ P finish |
| Earliest possible completion | Objective | Finish time of the last operation |
When pursuing multiple objectives, agree their priorities. A company may place meeting deadlines ahead of reducing equipment changes, or accept a documented trade-off. The team should be able to explain why two plans received different scores using the same units and calculation rules.
Turning a business requirement into a decision model
- Variables
Choose operation starts and resources. Possible values are bounded by the process’s actual availability.
- Constraints
Preserve dependencies and capacity. Reject a plan violating an obligation when checking the result.
- Objective
Compare permitted plans using the established criterion: completion, lateness or cost. Document multiple priorities.
What a solver's result means
The OR-Tools CP-SAT documentation distinguishes solution statuses. FEASIBLE confirms that a plan satisfying the model was found; OPTIMAL also confirms optimality under the solver's criteria. INFEASIBLE indicates that satisfying the constraints has been proved impossible. MODEL_INVALID signals a model-validation issue that must be corrected before using a result.
UNKNOWN can occur when execution stops, for example at a time limit, before finding a solution or proving infeasibility. The interface must retain this distinct status. Reaching a time limit is different from a problem proved impossible. The application displays plans only when a valid solution is available for that result.
How predictions enter planning
If a model estimates job durations, that value becomes an optimisation input. A plan can perfectly respect the supplied durations while actual execution takes longer. The project must measure estimation error separately from planning quality. For variable operations, duration scenarios and replanning rules can be evaluated.
A better plan in simulation is a result of the planning model. To assess what applying it changed within the business, measure real outcomes and comparison conditions separately. Causal analysis addresses an intervention’s effect; calculating a feasible schedule and evaluating its commercial impact are different tasks.
Initial data includes current availability, operations in progress and update times. Replanning should not automatically move a job that has already started if the process does not allow interruption. Nor should a cancelled order be retained unchanged simply because it existed in the morning export. Current operational state forms part of the model.
Four checks before applying a plan
- Current data
Update started operations, cancelled orders and availability before calculation.
- Solution status
Display the solver result explicitly. FEASIBLE, OPTIMAL and INFEASIBLE describe different situations.
- Approval
The owner compares the proposal with requirements and approves operations permitted by the application.
- Execution
Measure actual durations and differences from estimates. Replan under interruption and priority rules.
A first business planning project
Define a workshop, team or order-preparation flow. Compare the system's proposal with today's schedule using the same data and constraints. Track condition violations, duration, lateness and manual changes. For each exception, establish whether information or an operational rule was missing.
A checkable plan identifies each operation’s resource, start, finish and satisfied dependencies. The calculation report also retains input data, objective, time allocated to the solver and result status. This information allows two proposals to be compared and explains why a job was moved.
Through business automation with AI integration, WebHat can connect application data with a proposed plan and its approval flow. In custom applications with AI, the team can have an interface for reviewing constraints and alternatives. Publishing the schedule, changing an order and notifying those involved remain actions defined separately from calculating the plan.
Questions about prescriptive AI and optimisation
Can a language model replace the solver?
It can help describe requirements and explain the plan. Constraint compliance and objective calculation must be checked through the implemented planning mechanism.
Is large infrastructure required?
Requirements depend on the number of variables, constraints and available time. Measure them on instances representative of the business.
What happens when requirements are incompatible?
Identify the constraints and data involved, then the process owner decides what can change. The system does not silently remove obligations to produce a schedule.
Must every calculated plan be applied automatically?
No. Calculation can produce a proposal for review. Application permissions, approvals and notifications are established separately within the application.
