Use Cases - SolverForge AI

Industrial Heat Treatment

155 heat-treatment orders. 11 furnaces. 39 operators. One coupled plan.

Heat-treatment planning shows SolverForge handling machine capacity, thermal sequencing, task operators, monitoring load, and shift rosters inside one inspectable model.

155 Heat-treatment orders

11 Furnaces

39 Operators

467 Planning entities

30 Constraints

22 / 8 Hard / soft split

The answer is only valid if furnace assignment, time placement, task operators, monitoring capacity, and roster coverage all hold together. Splitting those decisions into staged cleanup passes can produce schedules that look legal in one layer and fail in another.

The current proof keeps schedule lanes, crew roster, score analysis, constraint drilldown, retained-job lifecycle, and the REST surface inspectable from the same operating artifact.

Furnace feasibility Process compatibility, temperature limits, load capacity, and week boundaries.

Sequencing Furnace overlap prevention and changeover-gap enforcement across weekly lanes.

Task ownership Load build, program, quench, unload, monitoring, and linked furnace tasks stay tied to scheduled work.

Operator rules Skills, shift ownership, double-booking prevention, day-only limits, rest, and consecutive-night limits.

Coverage Required role coverage and monitoring capacity are solved with the same plan as furnace assignments.

Soft tradeoffs Express, urgent, and standard lateness, thermal changeover, early starts, night starts, overtime, and load balance.

SolverForge Furnace runtime placeholder showing schedule lanes, solver status, constraint dots, and retained-job controls. — Runtime capture slot for the live Furnace solve, placed before the still-image breakdown.

SolverForge Furnace schedule tab actively solving with status bar, constraint dots, furnace lanes, and scheduled orders. — Schedule Overview The schedule view keeps solver state, score, throughput, constraint dots, and the weekly furnace plan on one operating surface.

Dense Furnace lane schedule showing process-colored heat-treatment orders with furnace type, temperature, capacity, and weekly placement. — Furnace Detail Furnace lanes keep process colors, thermal context, max load, and dense weekly placement visible instead of hiding the plan in a table.

SolverForge Furnace score analysis modal showing hard constraints, soft constraints, scores, and match counts. — Score Analysis Constraint analysis keeps the score explainable: all 30 constraints are visible with type, score, and match counts.

SolverForge Furnace monitoringCapacity constraint detail showing constraint name, hard score, weight, and match count. — Constraint Drilldown A single constraint can be drilled into directly; this capture uses monitoringCapacity from the retained job.

SolverForge Furnace Crew tab showing operators, roles, availability, planned shifts, and skills. — Crew Roster The crew roster is part of the same model: operators, roles, shifts, availability, and skills all constrain the plan.

SolverForge Furnace REST API tab showing retained-job endpoints for demo data, solve creation, job status, snapshots, and analysis. — REST API The shell exposes retained-job workflow through REST endpoints for create, status, snapshots, analysis, pause, resume, cancel, and SSE events.

Open source use case Open Hugging Face Space

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.

82 Deliveries

10 Vehicles

3 City datasets

4 Constraints

3 / 1 Hard / soft split

Retained Job lifecycle

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.

Assignment coverage Every delivery must belong to exactly one route.

Vehicle capacity Route load stays within vehicle capacity.

Time windows Deliveries stay inside the promised service window.

Travel time Soft pressure keeps total route travel efficient.

Route geometry Retained snapshots expose the route path and ordered stops.

Insertion recommendations Route repair suggestions can be inspected before action.

SolverForge Deliveries runtime placeholder showing the route map, route list, and retained-job controls. — Runtime capture slot for the delivery route solve and repair workflow.

SolverForge Deliveries overview showing vehicle route cards beside a Philadelphia route map. — Route Overview Route ownership stays visible as both ordered vehicle lists and map geometry.

SolverForge Deliveries vehicle timeline showing route load and time placement by vehicle. — Vehicle Timeline Vehicle timelines expose route pressure across the fleet instead of reducing the plan to a table.

SolverForge Deliveries delivery timeline showing delivery placement against service windows. — Delivery Timeline Delivery-level timing makes service-window pressure visible across the day.

SolverForge Deliveries recommendations modal showing insertion options for route repair. — Recommendations Recommendations turn retained plans into inspectable repair options instead of opaque reruns.

SolverForge Deliveries score analysis modal showing constraint types, scores, and match counts. — Score Analysis Score analysis separates hard route legality from soft travel-time pressure.

SolverForge Deliveries REST API tab showing retained-job endpoints for routes, snapshots, status, and analysis. — REST API REST endpoints expose the same retained route workflow for integration.

Warehouse Order Picking

8 grocery orders. 94 pick items. 5 trolleys. One inspectable walking plan.

Order picking shows SolverForge handling warehouse trolley routes as ordered lists: every item, bucket limit, order split, product location, and walking-distance tradeoff stays inspectable.

8 Grocery orders

94 Pick items

5 Trolleys

37 Products

4 Constraints

2 / 1 / 1 Hard / medium / soft

A warehouse picking plan is only useful if order items are assigned to ordered trolley routes, trolley buckets can carry the grouped order volume, and pick paths are short enough to operate. Treating assignment and route order as separate cleanup steps can make the walking plan look tidy while order ownership or bucket capacity fails.

The current proof keeps the warehouse map, trolley contents, order review, product and location facts, score analysis, retained snapshots, and REST workflow visible from the same operating surface.

Item coverage Every order item must appear in a trolley route.

Bucket capacity Per-order volume must fit the trolley bucket count and capacity.

Order splits Customer orders are kept on fewer active trolleys when possible.

Walking distance Route distance through shelving, side, and row locations remains a soft pressure.

Warehouse geometry Shelf, side, and row facts drive the path shown on the map.

Retained workflow Status, snapshots, score analysis, lifecycle actions, and SSE events stay integration-ready.

Runtime walkthrough for the warehouse order-picking solve and retained-route workflow.

SolverForge Order Picking warehouse map showing current trolley routes, numbered pick markers, solver score, and lifecycle controls. — Warehouse Map The warehouse map keeps ordered trolley routes, pick markers, solver state, and constraint dots on one surface.

SolverForge Order Picking warehouse map with one trolley route selected and trolley load cards visible below the map. — Trolley Focus Trolley focus isolates one picking route while the surrounding warehouse plan remains visible.

SolverForge Order Picking order review tab showing assignment metrics and order cards with trolley assignments. — Order Review Order review shows whether each customer order is assigned, split, or still waiting.

SolverForge Order Picking data tab showing product rows with warehouse location and volume fields. — Data View Data views keep products, orders, order items, trolleys, volumes, and warehouse locations adjacent to the plan.

SolverForge Order Picking score analysis modal showing hard, medium, and soft constraint rows with weights, scores, and match counts. — Score Analysis Score analysis separates hard legality, medium order-split pressure, and soft walking-distance pressure.

SolverForge Order Picking REST API tab showing retained-job endpoints for demo data, solve creation, status, snapshots, analysis, lifecycle actions, and events. — REST API REST endpoints expose the same retained order-picking workflow for integration.

Open source use case Open Hugging Face Space

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.

48 Service visits

6 Technicians

26 Locations

10 Constraints

6 / 4 Hard / soft split

Retained 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.

Assignment coverage Every service visit must appear in exactly one technician route.

Reachability Invalid visit indexes and unreachable travel legs are hard route issues.

Skills and parts Technician skills and inventory must cover visit requirements.

Time and capacity Time windows and shift capacity constrain the service day.

Territory affinity Routes prefer territory fit without hiding legality.

Soft tradeoffs Travel time, workload balance, priority slack, and territory affinity remain visible.

SolverForge Field Service Routing runtime placeholder showing route cards, map geometry, status bar, and retained-job controls. — Runtime capture slot for the field-service route solve and retained geometry workflow.

SolverForge Field Service Routing map showing assigned Bergamo technician routes, route cards, status bar, and colored route geometry. — Route Map The map keeps technician route ownership, assigned visits, retained route geometry, and solver state visible together.

SolverForge Field Service Routing map with one technician route highlighted and route cards beside the Bergamo map. — Route Focus Route focus lets an operator isolate one technician route while preserving the surrounding fleet context.

SolverForge Field Service Routing route timeline showing ordered service visits per technician across the work day. — Route Timeline The route timeline shows the same plan as ordered technician lanes across the 08:00-18:00 service day.

SolverForge Field Service Routing score analysis modal showing constraints, weights, scores, and match counts. — Score Analysis Score analysis makes all 10 constraints inspectable with weights, scores, and match counts.

SolverForge Field Service Routing data tab showing technician routes, service visits, locations, skills, parts, windows, and territories. — Data View Data views keep routes, visits, locations, skills, parts, windows, and territory facts adjacent to the plan.

SolverForge Field Service Routing REST API tab showing demo data, retained jobs, snapshots, route geometry, events, and analysis endpoints. — REST API REST endpoints expose demo data, retained jobs, snapshots, route geometry, SSE events, and analysis for integration.

Open source use case Open Hugging Face Space

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.

688 Shifts

50 Employees

28 Days

9 Constraints

6 / 3 Hard / soft split

2 Schedule views

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.

Coverage Required shifts must receive staff.

Skills Employees must satisfy role and qualification requirements.

Overlap prevention Employees cannot be double-booked across overlapping work.

Rest and day limits Work sequences respect rest and one-shift-per-day rules.

Availability Unavailable employees are excluded from assignments.

Soft balance Preferences and workload balance remain inspectable tradeoffs.

SolverForge Hospital runtime placeholder showing the location schedule and retained-job controls. — Runtime capture slot for the hospital schedule solve and review workflow.

SolverForge Hospital location schedule showing many shifts across departments and days. — Location Schedule Location schedules keep coverage pressure visible by department and day.

SolverForge Hospital employee schedule showing assignments by employee across the planning horizon. — Employee Schedule Employee schedules reveal whether the same plan works from the worker perspective.

SolverForge Hospital solver status surface showing retained-job lifecycle and telemetry controls. — Solver Status Solver status keeps lifecycle and telemetry visible during retained workforce planning.

SolverForge Hospital score analysis modal showing constraint rows, scores, and match counts. — Score Analysis Score analysis explains which staffing rules are hard legality and which are soft tradeoffs.

SolverForge Hospital data view showing employees, shifts, locations, skills, and availability tables. — Data View Data views keep the facts behind the schedule close to the plan being inspected.

SolverForge Hospital REST API tab showing retained-job endpoints for demo data, solve creation, status, snapshots, and analysis. — REST API REST endpoints expose the same retained workforce workflow for product integration.

Asset Readiness Planning

24 vessels. 56 days. Maintenance, training, parts, and readiness in one plan.

Fleet readiness is a synthetic maintenance and readiness planner: work packages, inspections, training, docks, technicians, parts, and readiness floors share one scenario surface.

24 Vessels

56 Days

66 Planning decisions

14 Constraints

8 / 6 Hard / soft split

5 Docks

Readiness planning couples asset windows, dock compatibility, technician capacity, parts arrivals, inspections, training, and readiness floors. Optimizing any one layer alone can make another layer infeasible.

The current app keeps readiness overview, schedule timeline, resource pressure, disruption controls, repair comparison, and API analysis surfaces together.

Required assignments Work, inspections, and training must be placed.

Dock feasibility Dock capacity and compatibility constrain maintenance placement.

Precedence Inspection and training order must respect readiness logic.

Resource pressure Technician capacity and parts availability gate the plan.

Readiness floors Weekly readiness targets remain hard operating commitments.

Soft tradeoffs Ready days, shortfall, lateness, overtime, churn, and deferral stay visible.

Use cases you can inspect.

155 heat-treatment orders. 11 furnaces. 39 operators. One coupled plan.

82 Philadelphia deliveries. 10 vehicles. Ordered routes you can inspect.

8 grocery orders. 94 pick items. 5 trolleys. One inspectable walking plan.

48 Bergamo service visits. 6 technicians. Skills, parts, shifts, and road-network routes.

688 shifts. 50 employees. 28 days of staffed coverage.

24 vessels. 56 days. Maintenance, training, parts, and readiness in one plan.

Bring a similar decision to SolverForge.