Building an AI-native interface around OptaPlanner

Constraint solvers are good at their job and unpleasant to operate. The engine returns a mathematically defensible schedule; the planner receives a wall of assignments with no argument attached, and either trusts it or does not. Three places a language model earns its keep around a solver, and one place it must be kept out.

One: assembling the inputs

The unglamorous majority of the work. Before a solve, someone has to gather demand and constraints: PMs due including runtime-triggered ones, open correctives by priority and SLA clock, crew availability, competency requirements, parts including sister-site stock, site access windows, job dependencies, travel grouping.

That assembly is mostly deterministic and should stay that way. Where a model helps is at the edges: reconciling the same fault reported three ways across two monitoring platforms, spotting that an alert matches an open work order rather than being new, flagging that a job’s estimated duration is implausible against its own history. Nothing here decides the schedule. It decides what the schedule is about.

Two: authoring the constraints

This is where it changes the economics. Constraint models are written by specialists in code, which means every rule change is a ticket, which means the model freezes at whatever the operation looked like when it was built.

A planner can describe the rule in a sentence: never send someone to a site whose induction has expired; prefer keeping the same crew on a customer’s sites across a week; treat the wind farm access window as hard and everything else as soft. Compiling those into constraint definitions is a good use of a model, provided two things hold. The rule is read back as unambiguous structured English with every assumption listed, and the planner approves the read-back rather than the sentence they typed. And the rule is backtested before it goes live: run it against twelve months of the operation’s own history and report what it would have done. A constraint that would have made forty per cent of last year’s work unschedulable is one you want to discover before Monday, not after.

Three: explaining the result

Solvers can already tell you why, in the sense that the score breakdown says which constraints bound. That is not an explanation a planner can act on.

Turning “hard constraint 4 satisfied, soft score −180” into “Thursday, because the fan kit lands Wednesday and Marek is on that site for the quarterly anyway” is exactly the translation a language model is good at. The rule is that every clause must trace to a solver fact or a record. An explanation layer that invents a plausible reason is worse than no explanation, because it teaches the planner to trust reasoning that was never in the solve.

The same applies to unschedulable jobs. “No competent person available in the window” is actionable. Silence is not.

Where it must not go

The model does not solve. Constraint satisfaction is a solved problem with a mature engine behind it, and a language model producing a schedule directly gives you something that looks right and satisfies nothing reliably. Keep the solve deterministic, keep the model at the edges, and keep every model-authored entry attributed and reversible.

It also does not sign. Anything with a permit, an isolation procedure or a statutory signature is approved by a named person, and no configuration should be able to change that.

What we are building

This is Facterra’s roadmap: input assembly from live records, natural-language rule authoring with a mandatory backtest before activation, and an explanation layer where every claim traces to a source. The solve itself is OptaPlanner’s, called from our side. That division is deliberate and permanent. If you are running a solver-based application and the operators find it opaque, the interface around it is usually a better investment than the engine inside it.