SolverForge in practice
Turn competing demands into a workable plan.
Cover shifts with qualified staff. Fit lessons into rooms and timeslots. Route deliveries within capacity and time windows. Coordinate maintenance without sacrificing fleet readiness. These examples show how to model the rules a plan must obey and the goals worth improving — so you can find a starting point for your own scheduling, routing, or allocation problem.
Healthcare workforce coverage
688 shifts. 50 employees. 28 days of staffed coverage.
Hospital scheduling shows scalar assignment at serious density: every shift needs a qualified employee while overlap, rest, availability, preferences, and balance remain visible.
Coverage planning breaks when qualification, availability, rest, overlap, and fairness are handled by separate tools. A schedule that fills every slot but violates rest or skill rules is not operationally usable.
The current app keeps location schedules, employee schedules, solver status, score analysis, data tables, and REST endpoints available from the same retained job.
- 1 Department rows expose where coverage is required.
- 2 Dense shift placement stays visible across the 28-day horizon.
- 1 Employee rows expose workload and assignment spread.
- 2 The same retained job can be inspected by people instead of only by locations.
- 1 Status controls keep solve lifecycle explicit.
- 2 Telemetry remains visible while the schedule is being reviewed.
- 1 Hard staffing legality and soft balance are separated for audit.
- 2 Each row exposes contribution and match counts for review.
- 1 Employees, shifts, locations, and availability remain inspectable.
- 2 Input facts stay adjacent to the generated schedule surface.
- 1 Endpoints expose solve creation, status, snapshots, and analysis.
- 2 The UI and integration API share the retained-job lifecycle.
School timetabling
300 lessons. 12 cohorts. 20 teachers. One inspectable school week.
Lesson timetabling shows two scalar decisions per lesson: which weekly timeslot and which room. Teacher availability, cohort availability, room capacity, and single-booking rules hold at the same time as soft timetable quality.
A timetable is not a table of slots. Every lesson needs a room that fits the class, a teacher who is available at that hour, and a cohort that is not already booked. No teacher can teach two lessons at once, no cohort can be in two places, and no room can host a double booking.
The app keeps the generated week, the retained job, score analysis, the input tables, and the REST surface on one inspectable timetable: cohort, room, and teacher views are three readings of the same retained plan.
- 1 The status strip keeps lifecycle state, score, moves per second, and all 11 constraint dots visible.
- 2 Each scheduled lesson carries its room, teacher, and cohort inside the block.
- 1 Room lanes show how the building is used across the week.
- 2 The same 300 lessons, read from the rooms instead of the cohorts.
- 1 Each view is one retained plan; only the grouping changes.
- 2 Teacher lanes expose that teacher's own week and load.
- 1 Hard, medium, and soft score components stay separate.
- 2 Soft pressure keeps its contribution and match count per constraint.
- 1 Input facts stay in the same surface as the generated plan.
- 2 Assignment columns show the chosen room and timeslot per lesson.
- 1 Every endpoint ships a copyable curl example.
- 2 Retained-job endpoints cover create, status, snapshot, analysis, and events.
Urban delivery routing
82 Philadelphia deliveries. 10 vehicles. Ordered routes you can inspect.
Delivery routing proves list-variable planning: each vehicle owns an ordered route while capacity, time windows, travel time, retained snapshots, route geometry, and insertion recommendations stay inspectable.
A delivery plan is not just assignment. Vehicle order matters, time windows matter, capacity matters, and changes need repair workflows that preserve useful route structure instead of throwing the plan away.
The current app exposes the route map, vehicle timeline, delivery timeline, recommendations, score analysis, retained snapshots, and REST endpoints as one planning surface.
- 1 Vehicle route cards keep stop order and load visible.
- 2 The map renders retained route geometry from the same solve snapshot.
- 1 Each lane owns an ordered route and capacity context.
- 2 Timeline placement makes route density and idle gaps inspectable.
- 1 Delivery rows expose service-window and assignment context.
- 2 Time placement shows where the route sequence is under pressure.
- 1 Insertion options are ranked before a user commits a repair.
- 2 The affected delivery remains visible while alternatives are inspected.
- 1 Hard constraints show whether the route plan is legal.
- 2 Soft travel-time pressure remains visible for tradeoff review.
- 1 Retained-job endpoints expose creation, status, snapshots, and analysis.
- 2 Route and recommendation APIs keep repair workflows product-embeddable.
Field service routing
48 Bergamo service visits. 6 technicians. Skills, parts, shifts, and road-network routes.
Field service routing keeps technician-owned ordered routes together with skills, parts, time windows, shift capacity, territory preference, and route geometry.
This is not just dispatch. A valid plan has to decide which technician owns each visit, then order those visits against service duration, travel, time windows, skills, parts, shift capacity, and territory fit.
The current proof keeps map routes, technician route cards, a route timeline, data tables, score analysis, retained snapshots, route-geometry endpoints, and REST workflow on one inspectable surface.
- 1 The status and summary row expose assigned visits, hard issues, and current score without leaving the map.
- 2 Colored route geometry comes from the retained route snapshot, not a separate drawing layer.
- 1 Route cards expose technician, travel, service time, territory, and stop count.
- 2 Focused route markers and path geometry make the selected technician's ordered work inspectable.
- 1 Each technician lane carries stops, travel, service time, and feasibility badges.
- 2 Visit blocks show the ordered route against the service-day clock.
- 1 Hard route legality and soft routing tradeoffs are separated in the analysis modal.
- 2 Match counts show where assignment, travel, priority, and territory pressure comes from.
- 1 Technician-route rows expose shifts, skills, inventory, territory, and assigned visit order.
- 2 Service visits keep duration, windows, priority, skill masks, parts, and territory visible.
- 1 Retained-job endpoints expose creation, events, snapshots, and analysis.
- 2 Route geometry is available through a snapshot-scoped endpoint for product integration.
Industrial heat treatment
155 heat-treatment orders. 11 furnaces. 39 operators. One coupled plan.
Heat-treatment planning couples machine capacity, thermal sequencing, batch placement, task operators, monitoring load, and the shift roster into a single model, so a furnace plan that ignores operator coverage cannot look legal.
The answer is only valid if furnace assignment, time placement, task operators, monitoring capacity, and roster coverage all hold together. Staging those decisions can produce schedules that look legal in one layer and fail in another.
The app keeps the furnace timeline, the operator roster, the order table, score analysis, the retained job, and the REST surface inspectable from one operating artifact.
- 1 The status bar starts Ready with the score empty and all 30 constraint dots present.
- 2 Eleven furnace lanes wait for the solve; 155 orders are still unassigned.
- 1 Hard score is still counting down while the search is live.
- 2 Order blocks appear in the lanes as construction and local search place them.
- 1 Lane headers keep furnace type, maximum temperature, order count, and load capacity.
- 2 Each block carries its work-order code, customer, and process in the lane.
- 1 Operators carry role, availability, planned shifts, and their skill mask.
- 2 Every manual task must land on an operator rostered on the owning shift.
- 1 Assigned furnace and scheduled window are readable per work order.
- 2 Delay per order exposes whether priority-weighted lateness reached the plan.
- 1 Hard feasibility and soft operating pressure stay separated by type.
- 2 Every constraint reports its score and match count for review.
- 1 Every endpoint ships a copyable curl example.
- 2 Retained-job endpoints cover create, status, snapshot, analysis, and events.
Warehouse order picking
8 grocery orders. 145 pick items. 5 trolleys. One inspectable walking plan.
Order picking treats warehouse trolley routes as ordered lists: every item, bucket limit, order split, product location, and walking-metre tradeoff stays visible on the plan an operator would actually walk.
A picking plan is only useful if items are assigned to ordered trolley routes, the buckets can carry the grouped volume, and the walk is short enough to operate. Treating assignment and route order as separate cleanup steps makes the plan look tidy while order ownership or bucket capacity quietly fails.
The app keeps the isometric warehouse canvas, the trolley legend, the picking-plan cards, the input tables, score analysis, and the retained job on one surface.
- 1 The stats panel states the demand before the solve: orders, items, active trolleys, closed metres.
- 2 The warehouse canvas is drawn and waiting; no trolley route exists yet.
- 1 The solver is still improving, with the route plan changing under it.
- 2 Trolley paths and numbered pick markers appear as routes are constructed.
- 1 Coloured paths show trolley ownership; numbered markers expose the pick order itself.
- 2 The legend ties each colour to its trolley and item count.
- 1 Each trolley card carries its item count and bucket-volume capacity.
- 2 The ordered item list is numbered, so the walking sequence is explicit.
- 1 Scenario inputs are explicit: order count, trolley count, and bucket count.
- 2 Generate New rebuilds the dataset through the same demo-data contract.
- 1 required_buckets is the hard rule; bucket overflow is not a preference.
- 2 order_incidence and route_distance carry the soft pressure.
Asset readiness planning
24 vessels. 56 days. 66 decisions. Maintenance, training, and readiness in one plan.
Fleet readiness is a synthetic asset planner: work packages, inspections, training, docks, technician pools, parts arrivals, and daily readiness floors share one scenario surface and one repair workflow.
Readiness planning couples asset windows, dock compatibility, technician capacity, parts arrivals, inspection and training precedence, and daily readiness floors. Optimizing any one layer alone can make another infeasible.
The app keeps the vessel timeline, the daily readiness ledger, technician pressure, parts posture, disruption repair, score analysis, and the REST surface together.
- 1 The summary strip counts vessels, work packages, decisions, and dock utilization.
- 2 Every vessel lane is present and empty; nothing is silently pre-placed.
- 1 The solver is live and the score is still moving.
- 2 Work packages land in the vessel timeline as decisions are made.
- 1 Lanes show placement and readiness windows per vessel.
- 2 Blocks carry the work package, its class, and its priority on the day axis.
- 1 Readiness is reported per day across the full 56-day horizon.
- 2 The floor columns show the hard commitment the plan must hold.
- 1 Each pool reports its peak day and peak capacity.
- 2 Utilization and overtime headroom explain why the plan is constrained.
- 1 Four named disruptions describe the scenario before it is solved.
- 2 A repair seeds a baseline from the plan on screen and compares both revisions.
- 1 Nine hard rules cover assignment, windows, docks, precedence, capacity, parts, and readiness floors.
- 2 Soft objectives keep their weight, score, and match counts.
- 1 Retained-job endpoints cover create, status, snapshot, analysis, and lifecycle.
- 2 Every endpoint ships a copyable curl example.
Airline crew scheduling
10 flight legs. 24 crew. 42 required seats. Rotations that respect rest.
Crew scheduling fills every required cockpit and cabin seat while qualification, overlap, connection continuity, availability, and every rest and recovery window hold at the same time.
A valid rotation is more than a name in a seat. Every seat needs a qualified crew member, no two duties may overlap, connected flights must be operated in sequence, and each person has to be available. Rest is where it gets hard: home-base and away-base minimums, 36-hour extended recovery, and 48-hour recovery after long-haul duty all hold together.
Solve those rules one at a time and you get a roster that looks fine in one view and strands a crew member in another. The app keeps the crew timeline, the by-flight manifests, score analysis, the data tables, and the retained job in one model.
- 1 Required seats and unassigned seats are stated before the solve.
- 2 Crew lanes carry home base and role; no duty block exists yet.
- 1 Duty blocks land in crew lanes as seats are assigned.
- 2 The solver is live and the score is still improving.
- 1 Lane headers keep each crew member's role, home base, and flight count.
- 2 Duty blocks sit against the day axis, with unavailable days overlaid.
- 1 Each row is one flight leg with its seat requirement.
- 2 Seat blocks name the crew members assigned to that leg.
- 1 Coverage, skill, overlap, connection, availability, and rest are hard rules.
- 2 Home-base return stays visible as soft pressure on its own.
- 1 Crew assignments expose which employee owns which required seat.
- 2 Employees carry qualifications and home base as input facts.
- 1 Retained-job endpoints cover create, status, snapshot, and analysis.
- 2 Lifecycle actions and the event stream are integration points as well.
Run one yourself
Run these examples, then model your own decision.
Every case above is a working app with a guide in the docs, and each one is marked with the Hugging Face Space you can open and drive yourself. Scaffold the generic project shell, follow one worked example, or start from a Space.