SolverForge in practice

Use cases you can inspect, not just read about.

Every SolverForge use case is open source, so what marks a case here is whether it exposes a Hugging Face Space you can open and drive in the browser. Today all four do. Each one carries source-backed data, explicit constraints, a retained-job workflow, a narrated runtime walkthrough, and annotated screenshots of the same solve.

Hospital Space Lessons Space Deliveries Space Field service Space

Hugging Face Space Open the Space on Hugging Face Read the Hospital guide

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.

Runtime walkthrough Watch the coverage plan fill, then read the same retained job from the location view, the employee view, and score analysis. Narrated walkthrough (2:29): the location schedule, the employee schedule, solver status, score analysis, the data tables, and the REST surface of one retained hospital solve.

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.

Hugging Face Space Open the Space on Hugging Face Read the Lessons guide

300 Lessons

12 Cohorts

20 Teachers

40 Weekly timeslots

10 Rooms

11 Constraints

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.

Teacher availability Teachers can teach only the timeslots they are available for.

Cohort availability Student groups can attend only the timeslots they are available for.

Room capacity An assigned room must have capacity for the class size.

Single booking One teacher, one cohort, and one room cannot host overlapping lessons.

Assignment completeness Medium pressure keeps every lesson assigned to both a timeslot and a room.

Timetable quality Room kind, late-day lessons, and repeated subjects stay visible as soft pressure.

Runtime walkthrough Watch the school week fill cohort by cohort, then check the same 300 lessons from rooms, teachers, and score analysis. Narrated walkthrough (2:02): cohort timetables, room utilization, teacher loads, score analysis, the data tables, and the REST surface of one retained timetable solve.

SolverForge Lessons cohort timetable with solved Monday schedules, per-cohort scheduled badges, and the solver status strip. — Group timetable The cohort view lays out each group's week across a fixed Monday-to-Friday teaching week, with the status strip, score, and constraint dots on the same surface.

SolverForge Lessons room utilization rail showing every room as a lane with its scheduled lesson blocks. — Room utilization Room utilization turns the same retained plan around: every lane is one room, with booked lessons placed against the teaching day.

SolverForge Lessons teacher load rail showing each teacher as a lane with scheduled lessons and load badges. — Teacher loads Teacher loads expose the working week of every teacher, so a timetable that fits the cohorts can be checked against the people teaching it.

SolverForge Lessons score analysis modal listing all 11 constraints with type, score, and match counts. — Score analysis Score analysis makes the timetable auditable: hard legality, medium assignment pressure, and soft quality stay separated with match counts.

SolverForge Lessons data view showing the lesson table with duration, group, subject, teacher, room kind, and assigned timeslot columns. — Data view Data views keep cohorts, subjects, teachers, rooms, and timeslots next to the plan, with the assigned timeslot and room visible per lesson.

SolverForge Lessons REST API guide listing health, info, demo data, job, snapshot, and analysis endpoints with curl examples. — REST API The REST guide exposes the same retained workflow for integration: demo data, solve creation, status, snapshots, analysis, lifecycle actions, and events.

Hugging Face Space Open the Space on Hugging Face Read the Deliveries guide

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.

Runtime walkthrough Watch ordered routes take shape, then inspect route geometry, insertion recommendations, and the retained-job workflow. Narrated walkthrough (2:49): route ownership, vehicle and delivery timelines, error repair with recommendations, score analysis, and the REST surface of one retained route solve.

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.

Hugging Face Space Open the Space on Hugging Face Read the Field service guide

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.

Runtime walkthrough Watch technician routes form across Bergamo, then read skills, parts, shifts, and route geometry from the same solve. Narrated walkthrough (2:37): assignment, road-network routes, skills and parts pressure, score analysis, and the snapshot-bound route geometry of one retained FSR solve.

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.

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.

Start with solverforge-cli Browse the use-case guides

Find SolverForge docs, releases, and references.

Start broad, then narrow down.

Use cases you can inspect, not just read about.

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

300 lessons. 12 cohorts. 20 teachers. One inspectable school week.

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

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

Run these examples, then model your own decision.