This is the multi-page printable view of this section. Click here to print.
Before diving into SolverForge, it’s helpful to understand the core concepts behind planning optimization. This section covers:
The need to create plans generally arises from a desire to achieve a goal:
Achieving those goals involves organizing the available resources. To correctly staff a hospital you need enough qualified personnel in a variety of fields and specializations to cover the opening hours of the hospital.
Any plan to deploy resources, whether to staff a hospital shift or to assemble the building materials for a new house, is done under constraints.
Constraints could be:
Any plan needs to consider all three elements—goals, resources, and constraints—in balance to be a feasible plan. A plan that fails to account for all the elements of the problem is an infeasible plan.
For instance, if a hospital staff roster covers all shifts, but assigns employees back-to-back shifts with no breaks for sleep or life outside work, it is not a valid plan.
Planning problems become harder to solve as the number of resources and constraints increase. Creating an employee shift schedule for a small team of four employees is fairly straightforward. However, if each employee performs a specific function within the business and those functions need to be performed in a specific order, changes that affect one employee quickly cascade and affect everybody on the team.
As more employees and different work specializations are added, things become much more complicated.
Example: For a trivial field service routing problem with 4 vehicles and 8 visits, the number of possibilities that a brute force algorithm considers is 19,958,418.
What would take a team of planners many hours to schedule can be automatically scheduled by SolverForge in a fraction of the time.
Operations Research (OR) is a field of research focused on finding optimal (or near optimal) solutions to problems with techniques that improve decision-making.
Constraint satisfaction programming is part of Operations Research that aims to satisfy all the constraints of a problem.
Planning AI is a type of artificial intelligence designed specifically to handle complex planning and scheduling tasks, and to satisfy the constraints of planning problems. Instead of just automating simple, repetitive tasks, it helps you make better decisions by sorting through countless possibilities to find the best solutions—saving you time, reducing costs, and improving efficiency.
Traditional methods of planning often involve manually sifting through options or relying on basic tools that can’t keep up with the complexity of real-world problems. Planning AI, on the other hand, uses advanced strategies to quickly focus on the most promising solutions, even when the situation is extremely complicated.
Planning AI also makes it possible to understand the final solution with a breakdown of:
This makes Planning AI incredibly valuable in industries where getting the right plan is crucial—whether that’s scheduling workers, routing deliveries, or managing resources in a factory.
Constraints can be considered hard, medium, or soft.
Hard constraints represent rules and limitations of the real world that any planning solution has to respect. For instance, there are only 24 hours in a day and people can only be in one place at a time. Hard constraints also include rules that must be adhered to, such as employee contracts and the order in which dependent tasks are completed.
Breaking hard constraints results in infeasible plans.
Medium constraints help manage plans when resources are limited (for instance, when there aren’t enough technicians to complete all the customer visits or there aren’t enough employees to work all the available shifts). Medium constraints incentivize SolverForge to assign as many entities (visits or shifts) as possible.
Soft constraints help optimize plans based on the business goals, for instance:
To help determine the quality of the solution, plans are assigned a score with values for hard, medium, and soft constraints.
0hard/-257medium/-6119520soft
From this example score we can see:
Note: The scores do not show how many constraints were broken, but weighted values associated with those constraints.
Because breaking hard constraints would result in an infeasible solution, a solution that breaks zero hard constraints and has a soft constraint score of -1,000,000 is better than a solution that breaks one hard constraint and has a soft constraint score of 0.
The weight of constraints can be tweaked to adjust their impact on the solution.
SolverForge can solve a wide variety of planning and scheduling problems. Here are some common categories:
Assign activities to time slots and resources.
Assign employees to shifts based on:
Examples: Hospital nurse scheduling, retail staff scheduling, call center scheduling
Assign lessons to timeslots and rooms:
Examples: University course scheduling, school class scheduling
Find optimal times for meetings:
Schedule jobs on machines:
Examples: Manufacturing scheduling, print shop scheduling
Plan routes and sequences for vehicles or resources.
Plan delivery or service routes:
Variants:
Examples: Delivery route planning, field service scheduling, waste collection
Visit all locations exactly once with minimum travel:
Examples: Sales territory planning, circuit board drilling
Assign entities to resources or positions.
Assign tasks to workers or machines:
Examples: Project team assignment, warehouse task allocation
Pack items into containers:
Examples: Truck loading, cloud server allocation, cutting stock
Allocate limited resources to competing demands:
Real-world problems often combine multiple problem types:
Combines:
Combines:
When modeling your problem, consider these characteristics:
| Characteristic | Description | Example |
|---|---|---|
| Hard constraints | Must be satisfied | Legal requirements |
| Soft constraints | Should be optimized | Customer preferences |
| Planning entities | What gets assigned | Lessons, visits, shifts |
| Planning variables | The assignments | Timeslot, room, vehicle |
| Problem facts | Fixed data | Employees, rooms, skills |
When modeling your problem:
The Getting Started section provides complete examples for common problem types.
The input to the solver: a set of planning entities with uninitialized planning variables, plus all problem facts and constraints.
The root Rust struct that holds all problem facts, planning entities, and the current score. Annotated with #[planning_solution].
A Rust struct whose instances are modified during solving. Planning entities contain genuine planning variables or list variables. Annotated with #[planning_entity].
A field on a planning entity that the solver changes during optimization. Annotated with #[planning_variable(...)].
Immutable input data that constraints reference but the solver does not modify. Annotated with #[problem_fact] and stored in a #[problem_fact_collection].
A stable identifier for an entity or fact. Annotated with #[planning_id]. Most user-facing examples use one so joins, telemetry, and analysis stay easy to read.
The set of possible values for a planning variable. In the common stock runtime, the planning variable names its provider with value_range = "solution_field".
A measure of solution quality. Higher scores are better. Common types: SoftScore, HardSoftScore, and HardMediumSoftScore.
A constraint that must be satisfied for a solution to be feasible. Broken hard constraints make a solution invalid.
A constraint that should be optimized but isn’t required. Used for preferences and optimization goals.
A constraint between hard and soft, typically used for “assign as many as possible” scenarios.
A solution with no broken hard constraints (hard score of 0 or positive).
A feasible solution with the best possible soft score. May be impractical to find for large problems.
The fluent API for defining constraints. Streams start from ConstraintFactory::<Solution, Score>::new(), then either for_each(...) or a generated collection accessor such as .shifts().
An algorithm that builds an initial solution quickly by assigning values to all planning variables.
An algorithm that improves an existing solution by making incremental changes (moves).
A change to the solution, such as swapping two assignments or changing a single variable.
One iteration of the optimization algorithm, consisting of selecting and applying a move.
The condition that stops the solver (time limit, score target, no improvement, etc.).
A planning variable whose value is calculated from other variables, not directly assigned by the solver. Used for derived values like arrival times.
A shadow variable that maintains a reverse reference to the owner or assignment created by a genuine variable.
Shadow variables that track the previous or next element in a list variable.
A shadow variable that triggers recalculation when upstream variables change.
A planning variable that holds an ordered list of element indices. Used for routing and sequencing problems. Annotated with #[planning_list_variable(...)].
Distance-pruned move generation for large neighborhoods. In the config-driven runtime, this is expressed by choosing nearby move-selector variants such as nearby_list_change_move_selector.
Locking certain assignments so the solver cannot change them. Useful for preserving manual decisions or already-executed plans.
A modification to the problem while the solver is running (real-time planning).
The search engine that applies phases, selectors, acceptors, and incremental scoring to improve a solution.
Configuration object for runtime behavior such as termination, random seed, phases, and move-thread count.
Manages retained solve jobs, authoritative lifecycle state, streamed
SolverEvent values, snapshots, and exact in-process pause/resume. Useful for
services and web applications that need job ids, status polling, cancellation,
or score analysis after the solve finishes.
Trait generated for #[planning_solution] types that specify a constraints path. It enables score analysis for a concrete solution instance.
Internal component that calculates scores efficiently and powers score analysis.
The trait implemented for tuples of finalized constraints returned by your constraint function.
Start a constraint stream by iterating over items produced by an extractor closure.
A method like .shifts() or .employees() generated by #[planning_solution] for use on ConstraintFactory.
A generated helper on streams of entities with a single Option<_> planning variable. It filters to entities whose planning variable is currently None.
Remove items that don’t match a predicate.
Combine two streams by matching on joiners. The current API uses one unified .join(target) entry point for self-joins, cross-joins, and predicate joins.
A condition for matching items in joins, such as equal, equal_bi, or overlapping.
Aggregate items by key with collectors.
Flatten the final element of a tuple stream into a child collection, then continue matching on the flattened values.
Compute load imbalance directly from a uni-stream without manually writing group_by aggregation code.
Keep or reject items based on whether matching items exist in another collection.
Aggregation function (count, sum, min, max, toList, etc.).
Apply score impact for matching items.
Finalize the constraint with a human-readable name.
Breakdown of which constraints contributed to the score.
A single instance of a constraint being triggered.
List of constraint violations associated with a specific entity.
Explanation of why a constraint was triggered.