Research
The research behind the methods
Each item in the research library states what was tested, what evidence exists, and where the result does not apply.
Enter the research libraryDecision systems
Software that makes one of your repeated decisions, every day, better than a spreadsheet does
Every company we have worked with has a decision it makes hundreds of times a month: which job goes to which crew, which order to accept, what to quote, what to reorder. It is made by an experienced person with a spreadsheet, and it is a few per cent off every time. But at that volume a few per cent is a large number. A decision system is a better method for that decision, wired to your data, sitting inside the workflow where the decision gets made, watched in production, and answerable to a person who can overrule it. A model on a slide changes nothing, and this changes what happens on Tuesday morning when the schedule gets made.
What they decide
The decisions they make
Each of these starts from a call that carries money. None of them started from a technique looking for somewhere to be used, and that is the other way round from how most of the industry works.
-
Which projects or contracts are drifting toward a loss, and by how much
-
How to allocate people, capital, inventory or maintenance against the exposure you carry
-
In what order and on which resource work should run when capacity is tight
-
Which orders, suppliers, projects or interventions to accept, pursue or decline
-
When a plan is fragile enough that it will break the first time reality diverges
-
Where critical logic must be proved because testing cannot cover it
Where the loss usually sits
Where the money usually is
The pattern repeats. A business runs on a decision it makes hundreds of times a month: which job, which route, which price, which order. An experienced person makes it with a spreadsheet, and it is not obviously broken. It is a few per cent off, every time, and at that volume a few per cent is a large number that nobody has ever measured.
Getting people and equipment to the work
Workforce scheduling, shift planning, dispatch, routing, field-service allocation, fleet utilisation, capacity planning, maintenance scheduling.
Deciding what to accept and what to charge
Quoting discipline, order acceptance, contract selection, delivery promises, pricing under uncertain cost, portfolio prioritisation, which work to decline.
Committing capital before you know
Inventory and spare parts, procurement and supplier selection, working capital, receivables, warranty and claims recovery, loss and exposure reconciliation.
These decisions cluster in businesses with heavy operations and thin analytical capacity: field and industrial services, maintenance, inspection and certification, logistics and fleet, laboratory and diagnostic services, environmental and waste operations, specialised distribution, and software businesses with a service organisation attached. So we go there, because a repeated decision in such a business is worth enough for a better method to pay for itself. Whether the sector is interesting has nothing to do with it.
222
operations-research algorithms with machine-checked proofs, across optimisation, decision-making and validation — the complete catalogue, zero pending, zero refuted. Checked by a 1,200-line kernel that is 0.50% of the code it verifies.
251
functions across 30 namespaces in our open-source OR library, with exactly one dependency — Clojure itself. You can read it before you hire us. That is the point of it being open.
6
dependency cones the catalogue is organised into — exact foundations, problem transformers, discrete optimisation and exploration, sampling and Markov kernels, population methods, and Bellman and fixed points.
One limit on those numbers. They are evidence that the method exists and can be checked. But they are no evidence that it has been run on your operation. Our engineering-delivery research is a separate body of work with a different subject, and we do not count it here — a function that forecasts cost-to-complete on a software programme is not evidence about your fleet.
How we talk about the size of the gain
Later than you might expect. Before anything has been measured on your data, an estimate is a hypothesis with a range, and we label it as one. It becomes an estimate for your operation once we have modelled it against your history, a measured effect once it has run against a counterfactual, and a recurring gain only after it has held for a while. We would rather give you the stage it is at than quote a number from somebody else’s case study, because somebody else’s case study is not going to run your operation.
Methods
The methods, and when each one is the right one
A method that has not earned its place in a paid engagement does not appear here. For each one there is a plain summary for whoever signs, and the detail underneath for whoever has to believe it.
Mathematical optimisation
Find the best allocation or schedule against an objective you agree, subject to the constraints you operate under.
Technical detail + Technical detail −
Linear, mixed-integer and constraint programming. Column generation and decomposition for scale. Robust and stochastic formulations where the inputs are uncertain. We keep the model readable so the constraints can be argued about by the people who own them.
Simulation
Stress a plan or policy against the disruption it will meet in reality before you commit to it.
Technical detail + Technical detail −
Discrete-event and Monte-Carlo simulation to estimate distributions of outcomes, expose tail risk, and compare policies on more than the average case. Used both to validate an optimiser and to answer questions no closed-form model can.
Forecasting
Turn history into a calibrated view of what is likely next, with the uncertainty stated.
Technical detail + Technical detail −
Time-series and hierarchical forecasting, survival and reliability models, and gradient-boosted or probabilistic learners where the data earns them. We report calibration and backtest error in place of a single point estimate.
Causal methods
Separate what drives an outcome from what merely moves with it, so an intervention changes the result you wanted.
Technical detail + Technical detail −
Causal graphs, difference-in-differences, instrumental variables and uplift modelling. The aim is to estimate the effect of acting, which correlation alone cannot give you.
Decision-making under uncertainty
Choose well when the inputs are probabilities instead of facts, and know how much a better estimate would be worth.
Technical detail + Technical detail −
Decision analysis, stochastic and robust optimisation, Markov decision processes and value-of-information analysis. We make the risk appetite an explicit parameter, and never an accident of the model.
Heuristics
When an exact answer is too slow to be useful, get a good answer fast enough to act on.
Technical detail + Technical detail −
Purpose-built constructive and local-search heuristics, metaheuristics, and hybrids that warm-start an exact solver. We benchmark the gap to optimality so you know what the speed costs you.
AI and machine learning
Use learned models where there is enough relevant data, and only where a concrete mechanism justifies it.
Technical detail + Technical detail −
Supervised and probabilistic models, and language models for extraction and workflow, integrated as one component inside a decision system with measurement around it. We do not describe a system as intelligent in place of saying what it does.
Formal methods
Prove that critical logic behaves as intended, where a failure is too expensive to leave to testing.
Technical detail + Technical detail −
Machine-checked proof, including Rainbow, our open-source Clojure theorem prover with a trusted kernel of roughly 1,200 lines. We are explicit about what is proved and what remains outside the proof.
How they are built to last
What keeps one working after we leave
The method is the easy part. Five habits separate a decision system that is still in use three years later from a clever model that quietly stops being opened, and every one of them is duller than the method.
-
Make objectives and constraints explicit
A decision system is only as good as the objective it optimises. We write the objective, the constraints and the trade-offs down in language the people accountable for them can read, challenge and sign off. Hidden objectives are how good models produce bad decisions.
-
Human-in-the-loop by design
Consequential decisions should keep a person in the loop. We design for recommendation with reasons, an override that is easy and logged, and clear boundaries for where the system is allowed to act on its own.
-
Data and integration
A method that cannot reach the data, or whose output nobody can act on, changes nothing. We treat sourcing, quality, latency and the path back into the workflow as part of the system from the start.
-
Validation and counterfactuals
Before trusting a system we test it against history it never saw, compare it with the decision you make today, and ask what would have happened had it been in charge. A recommendation with no baseline to beat is not yet evidence.
-
Monitoring, override and drift
Conditions change and models decay. We instrument the live system so that drift, degraded inputs and unusual recommendations are visible, and so a human can always see why a recommendation was made and step in.
Formal methods
Rainbow, for the logic that has to be right
Our open-source theorem prover for the decision logic that a failing test would find too late.
See RainbowFAQ
Questions about decision systems
What is a decision system?
A model that has been put to work: wired to your data, embedded in the workflow where the decision gets made, monitored in production, and always answerable to a person who can overrule it. A model on a slide changes nothing. A decision system changes what your business does on Tuesday.
Which methods do you use to build one?
Mathematical optimisation, simulation, forecasting, causal methods, decision-making under uncertainty, heuristics, AI and machine learning, and formal methods. Each earns its place only where it fits the problem, and never because it is a technique looking for a use.
Do these systems make decisions on their own?
For anything consequential, a person stays in the loop. The system recommends and gives its reasons, the override is one click and is logged, and the boundary of what it may do on its own is written down and agreed before it goes live. Where the decision is small and frequent enough, it acts alone, and the log shows what it did.
How does a decision system reach production and stay reliable?
We treat data sourcing, quality, latency and the path back into the workflow as part of the system. Before trusting it we test it against history it never saw and against the decision you make today, then instrument the live system so drift, degraded inputs and unusual recommendations are visible.
When should we not build a decision system?
When the objective cannot be made explicit and agreed, when a method cannot reach the data or its output nobody can act on, or when validation shows the system does not beat how you decide today. A Decision Opportunity Audit can end with a clear recommendation to reshape or stop, and not to build.
How do you use AI, and where do formal methods fit?
Learned models, including language models for extraction and workflow, are integrated as one component inside a decision system with measurement around them. Where a failure is too expensive to leave to testing, we use machine-checked proof, including Rainbow, our open-source Clojure theorem prover with a trusted kernel of roughly 1,200 lines.
Start with the decision
Which decision is it?
An audit maps the decision, its economics, the constraints, the data and the operating path, and ends with a recommendation to build, reshape or stop. Two to three weeks, fixed fee, run by a partner.
Who you deal with
The senior people who frame the problem are the ones who build it, and a partner is accountable to you throughout. Work is confidential and unattributed by default. References are owners and operating partners who have run one of these systems and will say plainly what it did not solve.
