From English to Optimal: How savanty Bridges Natural Language and Constraint Solvers
Describe optimisation problems in plain English and receive mathematically guaranteed solutions — no PhD required.
The Gap Between Intent and Formalism
Every organisation has optimisation problems. A hospital administrator wants the best possible staff schedule. A logistics manager wants to minimise fuel costs across a delivery fleet. A university registrar wants to assign rooms to courses without conflicts. These are all constraint satisfaction and optimisation problems, and they have been studied extensively for decades. Powerful solvers exist that can find provably optimal solutions to many of them in seconds.
The catch is that these solvers do not speak English.
To use a constraint solver, you must express your problem in a formal mathematical language: define decision variables, specify domains, write constraints as logical or arithmetic expressions, and declare an objective function. This is not trivial. It typically requires someone trained in operations research, mathematical programming, or a related field. The result is a persistent bottleneck: the people who understand the problem best (the administrators, the managers, the planners) cannot access the tools that solve it, and the people who can write the formal models do not always understand the problem deeply enough to capture every nuance.
This is the gap that savanty is designed to close.
What savanty Does
savanty takes a natural-language description of an optimisation problem and compiles it into a formal representation that a constraint solver can execute. The user describes what they want in plain English. savanty produces a solver-ready model. The solver produces a solution with mathematical guarantees: optimality, feasibility, or a proof that no feasible solution exists.
The key word here is “compiles.” savanty is not a chatbot that guesses at answers. It is a translation layer that converts informal specifications into formal ones, then delegates the actual solving to engines that are purpose-built for that task. The distinction matters because it determines where the guarantees come from.
Why LLM Output Alone Is Not Enough
Large language models are remarkably good at understanding intent. Given a scheduling problem described in English, a modern LLM can often produce a plausible-looking schedule. But “plausible-looking” is not “optimal,” and it is certainly not “guaranteed feasible.”
Consider a nurse rostering problem. The constraints might include: every shift must be covered, no nurse works more than five consecutive days, certain nurses cannot work night shifts, and the total overtime cost should be minimised. An LLM might generate a schedule that satisfies most of these constraints most of the time. But it has no mechanism to verify that all constraints are satisfied simultaneously. It cannot prove that the solution it produces is the best possible one. And when it fails, it fails silently — the schedule looks fine until someone notices that Nurse Rodriguez has been assigned seven consecutive night shifts.
Constraint solvers, by contrast, are built to handle exactly this. They explore the solution space systematically. When they return a solution marked as optimal, it is optimal. When they say no feasible solution exists, there is no feasible solution. This is a fundamentally different kind of guarantee from what a language model can provide.
savanty’s architecture exploits both capabilities: the language model’s ability to understand intent and the solver’s ability to provide guarantees.
The Compilation Pipeline
savanty’s pipeline has four stages.
Stage 1: Problem Understanding. The natural-language input is parsed to identify the key components: what are the decision variables (things to be decided), what are the constraints (rules that must be satisfied), and what is the objective (what should be maximised or minimised). This stage uses a language model fine-tuned on a corpus of optimisation problem descriptions paired with their formal representations.
Stage 2: Formalisation. The extracted components are mapped to a formal intermediate representation. Decision variables are typed and bounded. Constraints are expressed as logical or arithmetic relations over those variables. The objective function is defined. This intermediate representation is solver-agnostic — it does not commit to a particular solver’s input format.
Stage 3: Solver Selection and Encoding. Based on the structure of the formalised problem (linear vs. nonlinear, integer vs. continuous, size of the search space), savanty selects an appropriate solver back-end and encodes the intermediate representation into the solver’s native format. This might be MiniZinc, OR-Tools, or a direct encoding for a SAT or MIP solver.
Stage 4: Solution and Explanation. The solver runs and returns a result. savanty translates the raw solver output back into natural language, explaining what the solution is, why it is optimal (or why no solution exists), and which constraints were binding.
A Worked Example
Suppose a user types:
“I need to schedule 8 employees across 3 shifts (morning, afternoon, night) for the next 7 days. Each shift needs at least 2 people. No one should work more than 5 days. No one should work two night shifts in a row. Minimise the number of night shifts assigned to employees who have requested daytime preference.”
savanty processes this as follows. It identifies 8 employees and 3 shift types as the domain. The decision variables are binary: for each employee, each day, and each shift, does this employee work this shift on this day? The constraints are: at least 2 employees per shift per day, at most 5 working days per employee, no consecutive night shifts for any employee. The objective is to minimise the count of night-shift assignments for employees with a daytime preference.
This maps cleanly to a mixed-integer programming problem. savanty encodes it, sends it to the solver, and returns a complete 7-day schedule along with an explanation of which preferences could be honoured and which could not.
The entire process, from English input to verified schedule, takes seconds. Without savanty, modelling this problem from scratch would take an operations research practitioner an hour or more. With savanty, a hospital administrator can do it directly.
Accuracy and Failure Modes
savanty is not infallible. The translation from natural language to formal model is the critical step, and it can go wrong in several ways.
Ambiguity. Natural language is inherently ambiguous. “No one should work too many nights” is not a constraint a solver can enforce. savanty attempts to detect such ambiguities and ask clarifying questions, but it does not always succeed. When it guesses, it may guess wrong.
Implicit constraints. Domain experts often leave constraints unstated because they are obvious to anyone in the field. “Of course you cannot schedule a surgeon and an anaesthetist for the same operation at different times.” savanty does not have domain-specific common sense. It models what you say, not what you mean but did not say.
Problem complexity. Some problems are computationally hard regardless of how well they are formulated. savanty can produce a correct model that the solver cannot solve in a reasonable time. In these cases, savanty falls back to reporting the best solution found within a time limit, with a clear indication that optimality has not been proven.
Expressiveness limits. Not every optimisation problem can be expressed in the constraint languages that savanty targets. Problems with complex nonlinear dynamics, stochastic elements, or multi-stage decisions may exceed what the current pipeline can handle. savanty is transparent about this: when it cannot produce a valid model, it says so rather than producing a plausible but incorrect one.
We track these failure modes systematically. In our internal benchmarks on a corpus of 500 optimisation problems drawn from textbooks and real-world case studies, savanty produces a correct formalisation approximately 82% of the time without human intervention. With one round of clarifying questions, this rises to 91%. These numbers are honest — there is real room for improvement, and we are actively working on it.
Why This Matters
The practical consequence of savanty is that optimisation becomes accessible to people who have problems but not PhDs. This is not a small thing. Constraint solvers are among the most powerful and underused tools in computing. They can save organisations real money, real time, and real frustration. The barrier has never been the solvers themselves — it has been the translation layer between human intent and formal specification.
savanty is our attempt to build that translation layer properly: not by replacing solvers with language models, but by using language models to make solvers accessible. The guarantees come from the solver. The accessibility comes from the language model. Neither alone is sufficient. Together, they close the gap.