Basenews
Planning by eye: a luxury you pay for without realizing it
Published on 24 September 2026 by François-Alexandre Tremblay
For the past two years, Quebec businesses have been absorbing costs over which they have zero control. US tariffs reaching up to 50% on certain products. A climate of uncertainty causing deferred investments. Labor that is hard to recruit and paid more. Meanwhile, clients are unwilling to pay more.
What remains under their control lies within their own walls. Work allocation on an assembly line or in a shop. Schedules for a team of teachers, nurses, or drivers. The sequence of maintenance stops on an equipment fleet. Delivery truck routing, material cutting, electrical network layout in a building. These decisions are still made manually, in a spreadsheet, by someone who knows their job and does the best they can with the time they have.
As long as margins were comfortable, approximate planning went unnoticed. Not anymore. What was left on the table without being noticed now makes the difference between a profitable contract and one fulfilled just to avoid losing the client.
There are software programs that make these decisions better and faster than a human. They are called solvers. They are sold on the market, built to serve everyone. But none of them know your collective agreement, nor the reason why a specific machine never runs on Fridays. Our position is simple: the gain comes from a solver tailored to your problem, and no one can tailor it for you without spending time at your facility.
We tested this on three public benchmark problems—the ones the industry uses to compare solvers. For each one, we tuned our solver to the problem, just as we do for a client, and ran it with the same calculation time as commercial engines. This article explains what a solver is, how it is measured, the numbers we obtained, and what this approach yields for three local clients.
What a Solver Is
A solver is an artificial intelligence program that builds a plan for you. You describe the decisions to be made (e.g., which task goes to which machine, which driver takes which route), the rules to be respected (e.g., operation A must precede operation B), and the cost to minimize (e.g., number of workstations, production hours, kilometers driven). It then explores a set of candidate plans and retains the best one found within the allotted time.
Commercial solvers are generic resolution engines. The same program must perform well across thousands of unknown problems, from air transport to shop floor scheduling. And it goes further. Two companies manufacturing the exact same product don't necessarily have the same problem. One has a machine that is constantly overloaded, while the other operates with a reduced evening shift. Everyone has their own way of describing their rules, and a generic engine must fit them all into the same mold.
Our approach is different. We start with a foundational solver that we reuse from project to project. For each problem, we make custom adjustments to the solver that leverage the specific characteristics of that problem.
How Do You Measure a Solver?
The domain has its standardized tests, benchmarks. These are collections of problems published by the research community. Each problem in a collection is called an instance, and for each instance, the best solution ever found by anyone is known—often after days of computation. A solver is evaluated on its ability to approach or beat this best-known solution within a limited timeframe.
Competitors have made this their showcase, publishing their results on instances of varying size and complexity. Anyone can repeat the exercise. We did so on three benchmarks that mirror the challenges our clients face.
Electrical Grid Maintenance (RTE). The challenge set by French grid operator RTE: Plan electrical grid maintenance while exposing it to the lowest possible risk. The task consists of assigning a start date to each intervention over a horizon of up to 365 periods, keeping each team's workload within allowable limits, and avoiding simultaneous scheduling of two operations that cannot overlap during that season. For each period, organizers provide a range of potential grid situations with associated risk levels. The plan is evaluated on average risk and worst-case scenario risk. 45 instances and up to 706 maintenance operations.
Flexible Job Shop. The objective is to process all parts through a production shop, finishing as early as possible. Each part must follow its production steps in a fixed order, and each machine performs one task at a time. The same operation can be performed on multiple machines. You must choose which machine handles each operation and in what sequence. 336 instances, up to 100 parts, 25 steps per part, 500 operations, and 60 machines.
Assembly Line Balancing. An assembly line moves at the same pace for everyone. Each workstation has the same allocated time to do its part, the cycle time, and the part advances whether it is finished or not. Tasks must therefore be distributed among stations without any station exceeding this cycle time, respecting operation precedence, and using as few stations as possible. 525 instances with 100 tasks and 525 with 1,000 tasks.
In all three cases, we took their exact benchmark problems: same constraints, same objective, same calculation budget of one minute, and 8 CPU cores. Our solver starts from a common foundation and AI techniques, which we tune to the specifics of each problem.
A notable difference: Hexaly ran its benchmarks on a server equipped with an AMD Ryzen 7 7700 at 3.8 GHz. Ours ran on a mid-range laptop, an Intel i5-1340P. For the same 60 seconds, we had roughly half their computing power.
The Numbers
The table presents unedited numbers published by the competition. In one minute, a solver may fail to find any valid plan on a difficult instance. The first row of each RTE block gives the percentage of instances where a valid plan is found. In the average gap rows, a negative gap means the solution beats the best-known solution. Each of our solutions was re-validated by an independent checker, and RTE maintenance by the official challenge checker.
| Problem Size | Description | Baseline | Hexaly | CP Optimizer | Gurobi |
|---|---|---|---|---|---|
| RTE Maintenance: minimize risk. Three datasets of 15 instances. | |||||
| Small | Instances where a valid plan is found | 100% | 100% | 100% | |
| Instances within 5% of best-known solution | 100% | 93% | 73% | ||
| Instances within 1% of best-known solution | 87% | 73% | 67% | ||
| Large | Instances where a valid plan is found | 100% | 80% | 33% | |
| Instances within 10% of best-known solution | 100% | 73% | 0% | ||
| Instances within 5% of best-known solution | 73% | 60% | 0% | ||
| Very Large | Instances where a valid plan is found | 93% | 80% | 27% | |
| Instances within 10% of best-known solution | 93% | 67% | 0% | ||
| Instances within 5% of best-known solution | 80% | 33% | 0% | ||
| Assembly Line Balancing: minimize number of workstations. Two datasets of 525 instances. A negative gap is better. | |||||
| 100 tasks | Instances (out of 525) within 1% of best-known solution | 99.6% | 98.1% | 89.5% | 71% |
| Average gap to best-known solution | -1.1% | 0.2% | |||
| 1,000 tasks | Instances (out of 525) within 1% of best-known solution | 100% | 100% | 57.9% | 0 |
| Average gap to best-known solution | -1.9% | 0.2% | |||
| Flexible Job Shop: minimize total production time (makespan). Average gap to best-known solution, in percent. A negative gap is better. | |||||
| 1 to 100 operations | 194 instances | -0.6% | 0.3% | 1.3% | |
| 101 to 200 operations | 48 instances | 0.0% | 1.0% | 8.0% | |
| 201 to 300 operations | 73 instances | -2.8% | 1.0% | 38.5% | |
| 301 to 400 operations | 6 instances | 0.7% | 1.5% | 74.3% | |
| 401 to 500 operations | 15 instances | -25.0% | 0.5% | over 100% | |
| Across all sizes combined | % of solutions beating the best-known solution (113 out of 336) | 33.6% | |||
On small problems, the performance gap between solvers is narrow. On large problems, generic engines struggle while ours continues to find solutions—often better than anything previously published. On an assembly line, one less station means one less workstation to staff, every shift, all year long. In a shop, a few percentage points off total duration means machine hours recovered on every order.
What This Means for You
The three benchmarks are simplified, abstracted problems. Your real-world operations carry far more rules than that: shifts, certifications, crew preferences, priority clients, equipment breakdowns. A generic solver treats every rule with a standard recipe, the same for everyone. A tuned solver is built around how these rules interact in your specific company and reality. Its search process is made for your problem and no other. The more unique characteristics a problem has, the wider the gap becomes. It is this customization work that the numbers above measure.
This custom work remains affordable because we start every time from the same foundational solver. An SME thus has access to it on the same footing as a large enterprise. Here are three cases where we applied it.
Real Customer Results
College Schedule Planning: At the college level, building the master schedule used to take about 520 hours per year. Baseline worked with the client to build an engine that schedules 550 courses, 500 teachers, and 140 rooms, then assigns 29,000 student enrollments per semester under roughly thirty constraint types from 19 departments. The computation takes under two minutes, leaves zero schedule conflicts, and satisfies pedagogical requests significantly better than before.
Commercial Electrical Wiring Routing: Wiring a commercial building or office tower is almost never optimized. The electrical engineer only has time to place major equipment, the electrician pulls cables as best as possible on-site, and every detour is paid for in meters of copper. Baseline built the engine behind the electrical optimization module of a building design specialist. It shortens cable runs while adhering to construction constraints and the Canadian Electrical Code—because a shorter circuit is useless if it isn't compliant.
Fleet Management: On mining sites, hundreds of kilometers of service roads appear on no digital map. Vehicles are assigned day-to-day in Excel files, department by department. Baseline reconstructed the site map from millions of telemetry points, then delivered the optimization engine that builds routes from this map for a Quebec vehicle telemetry specialist. Over 400 light vehicles, several hundred operators, under time, capacity, labor availability constraints, and more. Together, telemetry enhancements and the optimization engine removed around sixty vehicles from the site's fleet.
Going Further
This optimization approach was designed and written in Quebec by a local cooperative. The expertise that stands toe-to-toe with global optimization giants exists in Canada, and it works for local organizations, on their shop floors, with their data. Before sending your optimization budget abroad for an engine that doesn't know your plant, take a look at what is being done locally.
If one of your operations costs more than it should—a schedule, a delivery route, a production line—drop us a line. We spend time with your team to understand your business goals, build a baseline model on your data, and quantify the gap between your current approach and what is achievable. When you're ready, we deploy the solution into production. Software engineering is our core trade just as much as AI.