What we solve
Six decisions a business makes every week and rarely makes well
When a company comes to us with a feature request, there is nearly always a decision underneath it that the business makes repeatedly and cannot yet make well. So we organise our work by that decision. Industry and technology come second. Find the decision under the symptom and the right method usually follows, and sometimes the right method is a spreadsheet.
The six
The same six questions, in businesses with nothing else in common
For each one: the question as an owner would put it, what it costs when the answer is wrong, the methods we might use, and the evidence we would want to see before anyone trusted the result. The evidence line is the one to read if you only read one.
Predict
cost-to-complete · demand · delay · failure · project risk
What is likely to happen before it shows up in the numbers?
When it is answered badly
- A fixed-price project drifts toward a loss that reporting only confirms once it is too late to act.
- Demand is met with the wrong inventory, or capacity is booked against a forecast nobody trusts.
- A component, machine or account fails without warning, and the cost lands as an emergency.
Methods we may use
Forecasting, causal methods, survival and reliability models, probabilistic simulation, and machine learning where the data supports it, with the uncertainty stated alongside every number.
Evidence we would require
A backtest against history the model never saw, calibration of the stated probabilities, and a comparison with the forecast you use today.
Allocate
people · capital · inventory · remediation effort · capacity
Where should limited resource go to earn the most, or lose the least?
When it is answered badly
- Skilled people are spread across too much work, and the highest-value task is delivered late.
- Remediation, warranty or maintenance budget is spent evenly instead of against the exposure you carry.
- Capital or inventory is committed by habit, so the position with the best return goes unfunded.
Methods we may use
Mathematical optimisation, stochastic and robust programming, and heuristics where an exact solver is too slow, with the objective and constraints written down and agreed.
Evidence we would require
A measured improvement against your current allocation on live cases, with the trade-offs and the points where the recommendation should be overridden made explicit.
Schedule
jobs · production · deliveries · service · constrained resources
In what order, and on which resource, should the work run?
When it is answered badly
- A plan looks feasible on paper but breaks the first time reality diverges from it.
- Changeovers, travel or set-up time quietly consume the capacity you were counting on.
- A single late job cascades through commitments because the schedule had no slack where it mattered.
Methods we may use
Constraint programming, mixed-integer optimisation, discrete-event simulation to stress the plan, and re-planning that expects disruption instead of assuming it away.
Evidence we would require
A schedule tested against realistic disruption, compared with your current planning on throughput, lateness and cost, including the awkward cases.
Select
orders · projects · interventions · suppliers · opportunities
Which of these should we accept, pursue or decline?
When it is answered badly
- An attractive-looking order is accepted and turns out to consume the capacity two better ones needed.
- A supplier or opportunity is chosen on price alone, and the full cost surfaces later.
- Interventions are approved one at a time, with no view of the portfolio they add up to.
Methods we may use
Portfolio optimisation, decision analysis under uncertainty, ranking and scoring models, and simulation of the second-order effects a spreadsheet cannot show.
Evidence we would require
A retrospective on decisions already made, and a comparison of the recommended choices against the ones taken, including the opportunities correctly declined.
Coordinate
plans · teams · dependencies · execution
Is the work producing the result the plan promised?
When it is answered badly
- Delivery, cost and business outcome live in separate systems, so risk is visible only in hindsight.
- Dependencies between teams surface as surprises, because the plan never accounted for them.
- Effort is measured by activity, and the connection to value is assumed because nobody has shown it.
Methods we may use
Data integration across planning and delivery, decision-science signals, and diagnostics that connect execution to outcome without reducing people to a single score.
Evidence we would require
Signals reconciled against known outcomes, and a demonstration that the view changes a decision a leader would otherwise get wrong.
Verify
algorithms · rules · proofs · critical software behaviour
Can this logic be trusted where a failure is expensive or unsafe?
When it is answered badly
- A pricing, safety or eligibility rule has an edge case that testing never reached.
- A decision algorithm is correct on the examples tried and wrong on the ones nobody thought to try.
- A change to critical code is shipped on the hope that the tests were exhaustive.
Methods we may use
Formal methods and machine-checked proof, including Rainbow, our open-source theorem prover, applied where testing alone cannot close the risk.
Evidence we would require
A machine-checked proof with its assumptions stated, and a clear line around what has been proved and what has not.
Where we have done this before
Four of these we have built the method for already
Where this comes from
We have been writing about this since 2020
A fair question about a page like this is whether any of it predates the marketing. It does. These pieces were published while the work was going on, before anyone thought of them as a position, and the research that came out of that work is below them.
From the archive
- 2020
- 2021
- 2025
And the research it turned into
- 2026
FAQ
Questions about the six
What kinds of decisions do you work on?
Six kinds, and every one of them recurs: predicting what is likely to happen before it shows in the numbers, allocating a limited resource, scheduling work across constrained resources, selecting which orders or opportunities to accept, checking that the work is producing the result the plan promised, and verifying logic where a failure is expensive or unsafe. A company usually has two or three of these, and usually knows which two or three.
Why organise by decision pattern instead of by industry?
Because the industry tells us very little about the method and the decision tells us almost everything. A scheduling problem in a machine shop and a scheduling problem in a hospital lab share more mathematics than either shares with the marketing department next door. So we start from the decision, and by the second week of an audit we know the industry well enough to be useful in it.
How do I tell whether my problem fits?
Look for a decision your business makes repeatedly, that carries money, risk or time, and that nobody is happy with how it gets made. If you can name the choice and say what getting it wrong costs, it almost certainly fits one of the six. If you cannot say what it costs, that is the first thing an audit works out.
What evidence would you expect before trusting a result?
It depends on the pattern. For a forecast, a backtest against history the model never saw, and a check that when it says 70% it is right about 70% of the time. For an allocation or a schedule, a measured improvement against your current approach on live cases, including the awkward ones. We would not trust a result on less than that, and we do not ask you to.
What does a first step look like?
You describe the choice your business keeps making. A partner reads it and replies with which pattern it fits and whether a better method looks worth building. If it does not, that reply is the end of it and it has cost you nothing.
What happens in the Verify pattern?
For logic where a failure is expensive or unsafe, we apply formal methods and machine-checked proof, using Rainbow, our own theorem prover, where testing alone cannot close the risk. The result is a proof a machine has checked, with its assumptions written down and a clear line around what has been proved and what has not, and that line is the part you will use.
Start with the decision
Tell us which decision it is
Describe the choice your business keeps making, in your own words. A partner will reply with which of the six it is, and whether a better method looks worth the cost of finding out.
Who you deal with
A partner owns the engagement and stays on it after the system is running. Work is confidential and unattributed by default, and the client names on this site are there because those owners agreed to it. An audit is a fixed fee agreed before it starts, so finding out what a decision is worth costs less than getting it wrong once.