PowerSolver — demo pitches

One pitch per demo in powersolver-demos/, for demo introductions, presentation talking points and customer conversations. Every figure comes from the demo's own files (documentation/demos/<demo>/SCENARIO.md, EXPECTED_RESULTS.md, reference solutions re-checked by the independent checker). Solve times were measured on a development laptop with the settings in each problem file. They are indicative, and they vary with the machine. All demo data is fictional but realistic.

How the plan is made, in plain words

PowerSolver's planning engine is Timefold Solver, a proven open-source optimisation engine. It does not try every possible plan: for 1,000 jobs, 120 technicians and 10 half-days there are far more combinations than any computer could ever list. Instead it works like a very fast, very patient planner, in two phases.

1. Build a first plan (construction). The engine takes the items one by one, for example lessons, jobs or shifts, in the order they are listed. It puts each one in the best place still free at that moment. This is First Fit: quick and sensible, but not perfect, because early choices can block better ones later. Listing the hardest items first helps, for example urgent breakdowns or language groups that must run in parallel. The demos do this.

2. Improve it, move by move (local search). The engine then makes millions of small changes and keeps or rejects each one:

• give this job to another technician;
• move this lesson to another hour;
• swap two shifts;
• move a whole group of lessons at once.

It does not only accept changes that improve the plan immediately. That way it would get stuck on a plan that is "good enough locally" but far from the best. The demos use two well-known strategies, one after the other:

• Late Acceptance: a change is accepted if the plan is no worse than it was a little while ago. The search can step back briefly to find a better path. It is used until every must-follow rule holds.
• Tabu Search: recently changed items are briefly forbidden from changing again, so the search keeps exploring new options instead of going round in circles. It is used to improve the wishes.

Simulated Annealing, Great Deluge, Hill Climbing and Variable Neighbourhood Descent are also available, and they can be chosen per problem.

How the engine judges a plan (the score). Every plan gets a two-part score:

• hard: the number of must-follow rules broken, multiplied by their weight. 0hard means the plan can be used.
• soft: the cost of the wishes not met (preferences, keeping last week's plan, fewer subcontractors…). Closer to zero is better.

The engine always prefers fewer broken must-follow rules, then fewer unmet wishes. The score is updated incrementally after each small change, which is why it can evaluate tens of thousands of changes per second.

When it stops. After the time limit you set, for example 60 or 120 seconds, or earlier if it stops improving. It returns the best plan found. With the same data and settings, the search follows the same steps. Because it stops on time, a faster machine may go a little further. Each demo states the time at which a valid plan was found.

Replanning. Published decisions can be pinned: the engine never moves them. Items that may move remember where they were, and moving them costs something in the soft score. The engine therefore changes only what it must, which is why a crisis is absorbed in seconds with only a few dozen changes.

Independent proof. After solving, a separate checker, written independently of the engine, recalculates every rule on the final plan. In every demo the two agree, rule by rule.

Where AI helps, and where it does not

The plan itself is never produced by AI. It is calculated by the optimisation engine from your data and your rules, following the steps above. Every rule is checked, the result can be verified independently, and it is the same for the same inputs and settings. AI (through PowerAI) helps the people around the plan:

• Describing the problem. In the AI-assisted path, you describe your situation in your own words and the AI drafts the items, options and rules in the wizard. You review and edit everything before planning.
• Advice before a change. When you remove or change something in the wizard, the AI explains which rules and data depend on it, so you do not break the model by accident.
• Reviewing a plan. On the Results page, the AI critic comments on the plan and can propose a change to the problem, for example a rule weight. Nothing happens until you accept it. The engine then plans again, and the page shows whether the new plan is better, the same or worse.
• Summarising differences. On the Compare page, "Describe with AI" turns the differences already computed (what moved, which rules changed) into a short plain-language summary for a manager or a steering committee.

In short, the engine decides and proves; AI explains, advises and summarises, and a person always stays in control.

Why PowerSolver

Planning problems are everywhere: timetables, rosters, maintenance weeks, project plans, event programmes. In most organisations they are solved by one or two experienced people with spreadsheets. It takes days. The result is fragile. When something changes on a Monday morning, the plan is rebuilt by hand under pressure.

Optimisation engines such as Timefold Solver solve these problems very well, but using one directly is a software project. Developers write the domain model in code (planning entities, variables, value ranges) and express every business rule as code. They then build, deploy and maintain it, and build the screens planners need around it.

PowerSolver is a planning layer built on Timefold Solver 2.0. It keeps Timefold's optimisation engine and adds what is needed to use it as a product:

Where Timefold directly remains the right choice. A team that needs a rule outside the catalogue, or wants to tune the engine in code, works at the Timefold level, or adds a built-in rule to PowerSolver. Routing with vehicle capacity, time windows and travel distances is in that situation today (see demo 06).

Demo 01 — School timetabling: Fessenden Upper School

60 lessons, 3 grades, 6 teachers, 5 rooms, 6-day rotation. The model grows step by step (room and time, then teacher, then session type), then an in-year disruption: "Dr. Chen unavailable on Day 3".

A. Why PowerSolver rather than Timefold directly. The demo shows the same problem growing from 2 to 4 decisions. Each step is a change to the JSON description and the rule list, not a new version of the code. The disruption is handled by generic features (the resource_unavailable rule and pins), with no special-purpose code. For a school, that means the timetable can be maintained by the people who know the school, without a development team.

B. Why plan with PowerSolver. The rules a timetabler juggles mentally are all explicit and enforced together:

• no class, teacher or room double-booked;
• labs and gym for the subjects that need them, and qualified teachers only;
• no subject twice a day, and a protected lunch period;
• balanced room use and teaching load.

When a teacher is absent, everything else is pinned and only the affected lessons move.

C. Pains it removes.

• Timetable built by hand over days → generated from the rules → time back for pedagogy.
• One absence breaks the published week → minimum-change replanning (master pinned) → families and staff keep their week.
• Rules applied inconsistently → every rule checked on every lesson → a timetable that holds up to scrutiny.

Scope note: this demo ships problem files and a presenter script; it is the guided introduction to the wizard, not a large-scale benchmark (see demo 12 for scale).

Demo 02 — Timetabling: Northbridge University, School of Computing

Cohorts (Year 1–3), modules, module leaders teaching several modules, Mon–Fri × 8 slots, about 33 sessions. Provided as plain-language intake answers for the AI-assisted path.

A. Why PowerSolver rather than Timefold directly. The same school-timetabling model covers a university department. Cohorts and modules replace grades and subjects, and nothing is re-coded. The intake is written in plain language, ready for the AI-assisted path.

B. Why plan with PowerSolver. A department has module leaders shared across cohorts, computer labs in short supply and a fixed lunch slot. PowerSolver checks all of these together and gives every leader a conflict-free week.

C. Pains it removes.

• Each department re-invents its spreadsheet → one model reused across institutions → faster roll-out to the next department.
• Leaders double-booked across cohorts → teacher no-conflict enforced → fewer last-minute swaps.

Scope note: intake only (no reference solution file); it shows breadth of use rather than measured results.

Demo 03 — Timetabling: St. Aldric's College (independent senior school)

Years 10–12, about 75 lessons, three distinct science labs, a language lab and a sports hall, two teachers for each core subject. Provided as plain-language intake answers.

A. Why PowerSolver rather than Timefold directly. Several specialist rooms with different equipment are just data ("this room offers lab-chemistry"). The room-suitability rule from the catalogue does the rest. No room-specific logic is written.

B. Why plan with PowerSolver. Science-heavy schools are limited by their labs. PowerSolver places each practical lesson in a lab that suits it, and spreads the shared teachers of each core subject across the week.

C. Pains it removes.

• Labs over-booked or used for theory lessons → room suitability enforced → practical lessons always where they should be.
• Two teachers per subject coordinated by hand → assignment optimised → consistent weeks for every class.

Scope note: intake only (no reference solution file).

Demo 04 — Task assignment: development backlog

A small reference model: 10 tasks, 4 developers, 6 time slots; each task gets a developer, a time slot, a priority class and a location (7 rules: everything assigned, skill match, no double-booking, balanced load).

A. Why PowerSolver rather than Timefold directly. The same backlog can be modelled with 1 to 4 decisions (who, when, priority lane, location). Adding a decision means adding a line, not a new class. It is a quick way to show a technical audience how little is needed to get from a problem to a working optimiser.

B. Why plan with PowerSolver. Every task goes to a developer with the required skill, nobody is booked twice in a slot, and the workload is spread instead of falling on the same two people.

C. Pains it removes.

• Assigning tasks by habit overloads a few developers → load balancing and skill matching → steadier delivery.

Scope note: a small reference example (independently certified feasible); demo 11 and demo 16 show the same kind of planning at project scale.

Demo 05 — Employee rostering: shift plan (reference model)

A small reference model: 10 shifts, 4 employees; each shift gets an employee, a time slot, a role and a location (7 rules: everything assigned, skill match, no double-booking, balanced load).

A. Why PowerSolver rather than Timefold directly. It is a compact starting point for any rostering project. Staff, shifts, roles and availability are data, and the same rules scale to a hospital (demo 15).

B. Why plan with PowerSolver. Every shift is covered by someone qualified, nobody is booked twice in a slot, and shifts are spread fairly.

C. Pains it removes. Rosters built by hand and checked by eye → every rule checked → fewer uncovered or illegal shifts.

Scope note: small reference example; see demo 15 for a full hospital roster and replanning.

Demo 06 — Vehicle routing: delivery rounds (current scope)

3 vehicles, 9 visits. The decision is the ordered route of each vehicle; arrival times are derived along the route.

A. Why PowerSolver rather than Timefold directly. Route sequencing (list variables) and derived arrival times are described in JSON with expressions, not code.

B. Why plan with PowerSolver. Today it places every visit on a route and orders the routes.

C. Honest scope. PowerSolver's routing rules currently cover "every visit placed" and "keep a number low". They do not yet cover vehicle capacity, customer time windows or travel distances, the core of real delivery planning. Present this demo as a preview. A customer whose main need is delivery routing should be told this plainly. The routing rules are planned work, not a current capability.

Demo 07 — Maintenance scheduling: plant (reference model)

A small reference model: 10 maintenance jobs, 4 technicians, 6 time slots, tool kits and priority classes (6 rules: everything assigned, no double-booking, balanced load).

A. Why PowerSolver rather than Timefold directly. It shows four decisions per job (technician, slot, tool kit, priority tier) configured without code. It is a compact way to explain the model to a technical audience before the large maintenance demo (13).

B. Why plan with PowerSolver. No technician double-booked, and load spread across the team.

C. Pains it removes. Assignments made on the phone without a full view → one plan with every job and every technician → fewer clashes.

Scope note: small reference example; demo 13 shows 1,000 jobs and Monday-morning replanning.

Demo 08 — Cloud capacity: service placement

A small reference model: 10 workloads, 4 servers, 6 time windows; each workload gets a server, a time window, a rack zone and a priority tier (6 rules: everything assigned, no double-booking, balanced load).

A. Why PowerSolver rather than Timefold directly. It shows that the model is not limited to people and time. A platform team describes servers, windows and zones as data and gets a placement optimiser without writing a solver; capacity limits (capacity rule) can be added as a further rule.

B. Why plan with PowerSolver. No server hosts two workloads in the same time window, and load is balanced across servers.

C. Pains it removes. Placement by rules of thumb → explicit, checked placement with balanced load → fewer overloaded hosts.

Scope note: small reference example (independently certified feasible); demo 17 shows cloud placement at scale, with an incident replan.

Demo 09 — Job shop: production orders

A small reference model: 10 operations, 4 machines, 6 time slots; each operation gets a machine, a time slot, an operator and a tool kit (7 rules: everything assigned, machine capability, no double-booking, balanced load).

A. Why PowerSolver rather than Timefold directly. Machines, operators and tool kits are data. Machine capability and no-double-booking come from the catalogue rather than custom code.

B. Why plan with PowerSolver. Each operation runs on a capable machine, no machine is booked twice in a slot, and load is balanced across machines.

C. Pains it removes. Shop-floor schedules rebuilt by hand after each rush order → re-solve in the same model → less firefighting.

Scope note: small reference example (independently certified feasible); demo 18 shows a full machining week, with a breakdown replan.

Demo 10 — Work-order assignment: field technicians

A small reference model: 10 work orders, 4 crew leads, 6 time slots; each order gets a lead, a time slot, a crew and a priority class (7 rules: everything assigned, skill match, no double-booking, balanced load).

A. Why PowerSolver rather than Timefold directly. It is the same pattern as maintenance (who, when, which crew, which priority), configured rather than coded.

B. Why plan with PowerSolver. Each order goes to a qualified lead, nobody is booked twice in a slot, and work is spread across leads.

C. Pains it removes. Dispatch decided by whoever answers the phone → consistent rules → fairer, more predictable dispatch.

Scope note: small reference example; demo 13 covers field service at scale.

Demo 11 — Project portal: 4-month software project

260 tasks, 6 developers, 84 day slots from 7 September, 3 priority lanes, 3 locations; 17 rules (skills, leave, public holidays, project phases, prerequisites, a capped expedite lane, facilities, closed locations, spread of work).

A. Why PowerSolver rather than Timefold directly. The project was described from a customer's JSON. Leave, holidays, phases, prerequisites and a capped expedite lane are all catalogue rules with parameters. Building the same optimiser directly on Timefold would mean coding each of these 17 rules.

B. Why plan with PowerSolver. A four-month plan that respects leave and holidays, keeps tasks inside their phase, does prerequisites first and keeps the expedite lane within its 80-task cap. It is shown day by day in the calendar view.

C. Pains it removes.

• Gantt charts updated by hand → plan derived from the rules → a plan that stays consistent when tasks change.
• Expedite lane abused → capped by a rule → real priorities stay visible.

Scope note: problem file only (no reference solution in the folder); run it live to show the result.

Demo 12 — Collège Jean-Moulin: weekly timetable for each term, with in-year changes

A French state collège: 520 weekly lessons, 20 classes, 35 teachers, 33 rooms, 32 time slots. Language groups (LV2) from several classes are taught in parallel. Term 2: a maternity leave and a closed lab. Term 3: the teacher returns, revision hours are added and a teacher has training days.

A. Why PowerSolver rather than Timefold directly. Features such as parallel LV2 groups, the "pupils" of a lesson being several half-classes, and teachers fixed by the principal's attribution are handled by generic rules with parameters. No collège-specific code is written. The period of the term (holidays, bank holidays) lives in the time slots, so the calendar and Excel show every teaching day of the term.

B. Why plan with PowerSolver. Measured on the reference run:

• Term 1: a full timetable valid after about 85 s (0hard/-9soft), with every one of the 9 must-follow rules at 0.
• Term 2: valid after about 4 s, with 178 lessons pinned. Only 14 lessons change time and 37 change room, mostly the lab that closed.
• Term 3: valid after about 1.5 s, with 400 lessons pinned and 8 lessons changing time.

The Changes tab lists every move.

C. Pains it removes.

• Weeks of summer work on the timetable → minutes of solving → the timetabler reviews instead of builds.
• A mid-year change forces a full rebuild → pins plus "keep last term's time/room" wishes → families and teachers keep their week (459 of 520 lessons unchanged in term 2).
• "Is it really conflict-free?" → independent checker agrees with the engine on every rule → a timetable the principal can defend.

Demo 13 — Field-service maintenance: 1,000 jobs, then a Monday-morning crisis

A multi-technical maintenance company around Lyon. Friday: plan next week's 1,000 jobs for 120 technicians (skills, zones, absences, client access windows, repair deadlines, survey before installation). Monday 07:30: 6 technicians sick for the week, 2 away Monday, 4 agency temps called in, 15 breakdowns reported over the weekend.

A. Why PowerSolver rather than Timefold directly. All eight must-follow rules are catalogue rules: skills, zones, absences, windows, dependencies and one job per half-day. The Monday replan is generated from Friday's plan by a short script that adds data and pins; the solver configuration is unchanged. The demo also exposed, and led to fixing, a performance issue in the dependency rule. That rule now places 1,000 jobs in seconds instead of failing to reach a valid plan in 300 s. A customer gets this kind of hardening without owning the engine code.

B. Why plan with PowerSolver. Measured on the reference run:

• Friday: a valid plan for 1,000 jobs after about 23 s, with every breakdown repaired by Tuesday evening.
• Monday: a valid replan after about 16 s. 712 jobs are guaranteed unchanged (pinned) and 146 jobs change, 64 of which had to (absent technician). The 4 temps absorb 32 jobs.

C. Pains it removes.

• Friday afternoon lost to the weekly plan → generated in under a minute → the planner checks exceptions instead of filling grids.
• Monday sick calls trigger chaos → replan before the vans leave, with route sheets kept for everyone else → fewer phone calls and missed appointments.
• Subcontractors used by default → "own staff first" wish (13 subcontracted jobs on Friday) → cost kept under control.
• Breakdowns lost among preventive work → deadlines as hard rules, "by Tuesday" as a wish → service-level commitments kept.

Demo 14 — Tech conference: the programme, then the eve of the event

A 3-day conference in Lyon: 153 sessions (3 keynotes, 130 talks, 10 two-part workshops), 10 tracks, 12 rooms, 120 speakers. Eve of the event (18:00): two speakers' flights cancelled, one speaker ill, a broken projector, workshop PCs arriving a day late, three sessions added.

A. Why PowerSolver rather than Timefold directly. A plenary keynote is modelled as "a session that belongs to every track", using the same no-overlap rule as the tracks. Room size and equipment are one capability rule. No conference-specific code is written.

B. Why plan with PowerSolver. Measured on the reference run:

• Programme: valid after about 3 s.
• Eve-of-event replan: valid after about 0.3 s. 139 of 153 printed sessions are unchanged; 13 are touched (6 new time, 9 new room), 3 added and 1 cancelled.

The Changes tab gives the exact list for the app, the screens and the room signs.

C. Pains it removes.

• Days of spreadsheet juggling between speaker availability, track clashes and room equipment → seconds → time to spend on content and sponsors.
• Last-minute changes break a printed programme → pins plus "keep its printed time/room" wishes → attendees' agendas mostly survive.
• Hidden conflicts discovered on the day → every rule checked → no speaker in two rooms, no workshop without PCs.

Demo 15 — Hospital rostering, Paris: the fortnight roster, then a flu wave

4 wards (Urgences, Réanimation, Cardiologie, Médecine interne), 12-hour day and night shifts, 532 positions, 120 doctors, nurses and nursing assistants. Saturday 06:00: five nurses and an emergency doctor off sick, an early maternity leave, a sick child, two extra intensive-care beds, four agency nurses on standby.

A. Why PowerSolver rather than Timefold directly. The working-time rules are configured with generic building blocks:

• 11 h rest between two shifts, at most 48 h a week, at most 3 days in a row (consecutive nights still allowed);
• intensive-care qualification;
• contract limits;
• days on duty.

The roster can be adjusted by the staffing office, not only by developers.

B. Why plan with PowerSolver. Measured on the reference run:

• Roster: valid after under 2 s, with every legal rule proven. 95 of 96 day-off requests are granted and nobody who asked for days works a night.
• Saturday replan: valid after under 1 s. Shifts already worked are untouched, and 28 of 351 remaining shifts change: 13 had to, 15 adjust around them. No agency nurse is needed.

C. Pains it removes.

• Early-morning phone marathons after sick calls → a valid replan in seconds, with the list of people to call → safe staffing restored before the shift starts.
• Rest rules broken under pressure → 11 h rest, 48 h a week and days in a row are musts → legally and clinically safer rosters.
• Agency staff called by reflex → "hospital staff first" wish → agency spending only when really needed.
• Requests for days off forgotten → wishes in the model → fairer rosters and better retention.

Demo 16 — International ERP and e-commerce rollout: 14 squads in 6 countries

172 one-week work packages across 7 workstreams and 2 country waves, 14 squads in Paris, Lisbon, Kraków, Casablanca, Bangalore and Montréal, 26 weeks, local holidays, a vendor date and 22 milestones. Week-9 steering committee: a squad pulled onto another client, a late delivery, a vendor slip of 3 weeks, and new regulatory scope due by week 20.

A. Why PowerSolver rather than Timefold directly. Time zones (European hours for user-facing work), holidays, dependencies, vendor dates and milestones are catalogue rules. This demo also led to an engine improvement: a broken dependency now costs more the later it is, so the search knows which way to move. Without that change, no search setting reached a valid plan. The fix was made once, in the engine, its score breakdown and the independent checker together, and benefits every customer.

B. Why plan with PowerSolver. Measured on the reference run:

• Initial plan: valid after about 50 s, with every milestone met.
• Week-9 replan: valid after about 4 s. The 53 completed packages are untouched, 11 of 123 remaining packages move (10 in time, 1 to another squad) and every milestone still holds.

C. Pains it removes.

• Programme plans that are out of date by the next steering committee → replanned in seconds from the actual situation → decisions made on a valid plan, not a hope.
• Dependencies across countries tracked in heads and spreadsheets → enforced → no team starts before its inputs exist.
• Holidays in six countries forgotten → part of the data → no surprise idle or overloaded weeks.
• "What does the vendor slip really cost us?" → Compare shows what moved and which rules changed → clear trade-offs for the steering committee.

Demo 17 — Private cloud: placing 390 VMs, then a Black Friday night incident

An e-commerce company's data centre: 390 virtual machines of 20 services (web, cart, checkout, payment, databases, search, machine learning, CI…) on 48 servers in 9 racks, with standard, high-memory, GPU and PCI-DSS servers. Tuesday 02:14, Black Friday: a rack loses power (6 servers), another server fails, and traffic doubles (24 replicas added).

A. Why PowerSolver rather than Timefold directly. CPU and memory capacity, hardware requirements, "replicas of a service on different servers" and "never on a server that is down" are all catalogue rules with parameters. The same model that plans lessons or technicians places VMs, with no placement code to write. The incident is handled by changing data: servers marked down, replicas added, databases pinned.

B. Why plan with PowerSolver. Measured on the reference run:

• Placement: valid after under 1 s, with no server overbooked and no service with two replicas on the same server.
• Incident: valid after about 3 s. Only the 64 VMs whose server died are migrated: not one other VM moves. The 24 new replicas are placed, and databases stay where they are.

C. Pains it removes.

• Placement by spreadsheet and rules of thumb → every capacity and safety rule checked → no overbooked host discovered under load.
• A 2 a.m. incident handled by hand under pressure → a valid placement in seconds → the on-call engineer executes instead of computing.
• Mass live migrations after a failure → "stay on your server" wish → only the unavoidable migrations, less risk in production.
• Special servers used for anything → "batch on standard servers" wish → GPU and PCI capacity kept for what needs it.

Demo 18 — Machining job shop: the week's schedule, then a Wednesday-morning breakdown

A precision-machining subcontractor (aerospace, automotive, medical, industrial pumps): 60 orders, 235 operations on 19 machines, two shifts, 2-hour blocks. Wednesday 06:00: a mill's spindle fails until Thursday afternoon, a rush order of bone screws arrives, and two bar-stock deliveries slip to Thursday.

A. Why PowerSolver rather than Timefold directly. Routings, machine capabilities, maintenance windows, material arrival and promised dates are catalogue rules. Building this demo also led to an engine improvement. When an item has two decisions (machine and time), the search now also changes both in one move, so an operation can leave a machine that cannot do it without first breaking something else. It was added once in the engine, tested against the independent checker, and makes other two-decision problems faster too (maintenance and conference demos).

B. Why plan with PowerSolver. Measured on the reference run:

• Week: valid after about 42 s, with every due date met.
• Wednesday replan: valid after about 0.5 s. Operations already done are untouched, and only 5 operations change: the three planned on the broken mill and two follow-on moves. The rush order is finished on Wednesday, a day before its due date. No due date is missed.

C. Pains it removes.

• The weekly schedule rebuilt on a whiteboard → generated from routings and machine data → the shift leader checks instead of juggling.
• A breakdown forces a full reschedule → only what the breakdown touches moves → operators keep their plan, set-ups are not wasted.
• Rush orders accepted blindly → the plan shows at once whether and where the order fits → realistic promises to customers.
• Late material discovered on the shop floor → earliest dates in the data → no machine waiting for parts that are not there.

Demo 19 — University exam session: 3 decisions per exam, then a snow day

A faculty's January session: 99 exams for 18 year groups of 50 to 260 students, 13 rooms from 30 to 450 seats, 40 invigilators, two weeks. For each exam PowerSolver decides the slot, the room and the invigilator. Thursday 07:00: snow closes the campus for two days (21 exams to move), a lecture hall has a heating failure, three invigilators are sick.

A. Why PowerSolver rather than Timefold directly. A third decision is one more line in the problem description, not a new model in code. Exact seat counts, invigilator availability, closed rooms and "one exam a day per year group" are catalogue rules.

B. Why plan with PowerSolver. Measured on the reference run:

• Session: valid after about 10 s, every room big enough, every invigilator available, the invigilation load spread as evenly as possible.
• Snow day: valid after about 11 s. Exams already sat are untouched, and 60 exams keep their slot, room and invigilator.

The demo also shows honesty about the data: without hall B there were not enough large halls in week 2, so the faculty opened two Saturdays.

C. Pains it removes.

• Weeks of juggling rooms, year groups and invigilators → one plan with three decisions per exam in seconds → the exam office checks instead of builds.
• A snow day ruins the published timetable → replanned before the first exam of the day → students and staff informed at once.
• Too-small rooms or double-booked invigilators found on exam day → exact seats and availability are must-follow rules → no surprise in the hall.

Demo 20 — Operating theatre week: 4 decisions per operation, then a Tuesday crisis

A hospital surgical block: 110 operations in 8 theatres (cardiac, orthopaedic with laminar flow, robotic, paediatric, general), 21 surgeons in six specialties, 10 anaesthetists. For each operation PowerSolver decides the theatre, the time, the surgeon and the anaesthetist. Tuesday 07:00: a theatre's ventilation fails, a surgeon is sick, three emergencies arrive.

A. Why PowerSolver rather than Timefold directly. Four decisions per operation, fourteen must-follow rules (equipment, specialty, paediatric and cardiac anaesthesia, availability, oncology deadlines), all configured. Writing this model directly on Timefold means coding the domain and every rule by hand.

B. Why plan with PowerSolver. Measured on the reference run:

• Week: valid after about 37 s, with every patient operated by their own surgeon.
• Tuesday: valid after about 30 s. Monday's operations are untouched, only 4 operations change time, and the three emergencies are operated on Tuesday. No oncology deadline is missed.

It is not instant: with four decisions most of the time goes into building the first plan. The demo says so.

C. Pains it removes.

• The theatre schedule built by phone between surgeons, anaesthetists and theatre managers → one plan with every constraint checked → fewer cancelled operations.
• Emergencies squeezed in by bumping whoever is easiest → only what must move moves → patients who were told a time mostly keep it.
• A child anaesthetised by a non-paediatric anaesthetist, a hip replaced without laminar flow → must-follow rules → safety by construction.

Demo 21 — Supermarket checkouts: shift start times from the hourly demand

A Lyon supermarket open 08:00-21:00 every day, 14 cashiers (full-time, part-time, weekend students), and the number of checkouts needed each hour of the week, from last year's tills: 329 cashier-hours, 1 to 9 at once.

A. Why PowerSolver rather than Timefold directly. The hourly demand is just a column on the list of hours; the rule "Enough people per time slot" counts every hour, even the ones nobody covers, so the plan puts the shifts where the demand is. Days off, one shift a day and closing time are configured, not coded.

B. Why plan with PowerSolver. Measured on the reference run: valid after about 10-15 s, every one of the 91 hours covered, and 27 of 28 morning/afternoon preferences met.

C. Pains it removes.

• Noon and Saturday peaks always short in the spreadsheet → every hour checked against its demand → shorter queues.
• "Do we need to hire?" answered by intuition → remove a cashier and see which hours go short → a hiring decision backed by numbers.

Closing

Across these demos the pattern is the same:

• The planning problem is described as data and plain business rules.
• PowerSolver, using Timefold's optimisation engine, produces a plan whose every rule is checked and independently verifiable.
• When reality changes, a new valid plan arrives in seconds. What was already published stays put unless it really must move.

The value for an organisation is not only a better plan. It is planning that no longer depends on one person's weekend, replanning measured in seconds instead of hours, and decisions that can be explained, rule by rule and change by change. Where PowerSolver's catalogue does not yet cover a need, routing today, we say so; that honesty is part of what makes the rest credible.