Computational intelligence and optimisation.
Feasible, best-known and proven optimal are three different answers.
Routing, scheduling, allocation and slotting, solved with the weakest method that clears the decision-quality bar — and reported honestly, because a plan that claims to be optimal when it is merely feasible is worse than one that admits it.
Choose the weakest method that meets the bar.
A mixed-integer program that times out is worse than a heuristic that returns a good feasible answer with an honest status, because the timeout has no fallback and the heuristic does. Method is chosen per problem, not by preference.
- Linear programming where the problem is continuous and linear — blending, simple allocation.
- Mixed-integer programming where choices are discrete, the instance is bounded and exactness matters — supplier allocation, replenishment with minimum order quantities, stock balancing.
- Constraint programming for rich combinatorial problems and scheduling — wave planning, slotting, manufacturing sequencing.
- Heuristics and metaheuristics where instances are large and exactness is unnecessary — fleet routing runs a regret-based insertion with bounded local search.
- Greedy where the problem decomposes trivially and the tie-breaks are stable — simple picking assignment.
A proposal you can interrogate, not a black-box plan.
- Input identity — the as-of time, an input fingerprint and the configuration version, so the same inputs demonstrably give the same plan.
- Solver identity — name, version, algorithm class and the deterministic seed.
- Hard constraints and soft preferences declared separately, each with its source and whether it was satisfied. A hard constraint is never quietly turned into a penalty.
- Objectives as a stated hierarchy, with the values achieved and the comparison against what you are doing now.
- Feasibility and optimality as two axes — optimal is claimed only when proven.
- Budget — the runtime and iteration limits, what was used, and whether a limit was hit.
- Assignments with a per-assignment explanation, and unassigned items with a typed reason and a remedy rather than silence.
- An independent validator — name, version, and explicitly whether it is independent of the solver, with its verdict and any violations.
- Application safety — a staleness snapshot, an application fingerprint and an expiry, so a plan cannot be applied to a world that has moved on.
No silent relaxation.
The failure mode this engine is designed against is the plan that looks achievable because a constraint was quietly downgraded. Hard constraints and soft preferences are declared separately and reported separately; if a hard constraint cannot be met the item comes back unassigned with a reason, rather than assigned with a violation nobody surfaced.
Where a good answer beats a perfect one that arrives too late.
- “What is today’s delivery run?” — capacity, vehicle capability, driver shift and weekly hours, time windows, cut-off and collection-before-delivery, all as hard constraints.
- “Which supplier should we buy this from?” — approved-supplier policy, contracted volumes and capacity, against cost and lead time.
- “How should we replenish?” — budget, minimum order quantity, shelf life and capacity.
- “What order should the warehouse work in?” — wave planning and slotting.
- “How do we sequence the works orders?” — manufacturing scheduling against real capacity.
Frequently asked questions.
Why not always use an exact solver?
Because an exact solver that times out gives you nothing, and the problems where that happens are exactly the large ones you needed help with. A heuristic with an honest status is more useful than an exact method with no answer.
What does “proven optimal” mean here?
That the solver proved no better solution exists under the stated constraints — not that it ran out of time and returned its best. Feasibility and optimality are two separate axes on the proposal for exactly this reason.
Can the optimiser apply its own plan?
No. A plan is a proposal. Applying it goes through the governed action lifecycle: re-resolve permissions, re-check the fingerprint, refuse the whole thing if anything moved.
What if a constraint cannot be satisfied?
The item comes back unassigned with a typed reason and a remedy. It is never assigned with a violation left unsurfaced.
See this engine on your own records.
Join the waitlist and ask it something real. Every answer names the engines it used and the records they read.
Join waitlist