How we work
How an engagement runs, stage by stage
There are five stages, and each one answers a single question before you commit to the next. The first stage can end with a recommendation not to build, and every stage after it has a reason to stop written into it. We arranged it this way after watching too many builds start before anyone had asked whether they were worth it.
Find
Find the decision that is worth improving.
Questions answered
Which repeated decision carries the money, risk or time? What does answering it badly cost today? Is there a plausible better method, a sponsor, and a route to the data?
What we need from you
Access to the people who own the decision, a sample of live cases, and a frank account of how the choice is made now.
What Flexiana produces
A decision map, an economic baseline, the constraints and data reality, and a shortlist of interventions worth proving.
The decision gate
Is there a decision valuable enough, and tractable enough, to justify proving a better method?
Likely commercial form
A Decision Opportunity Audit. A fixed, short engagement.
Reasons to stop
The decision is low-value or one-off, there is no sponsor or data route, or an off-the-shelf product already solves it.
Prove
Test the riskiest assumption on your own data.
Questions answered
Does a better method beat the way you decide today? By how much, on your own data, against an agreed baseline? And is the improvement worth the cost of building and running it?
What we need from you
A dataset representative of live conditions, an agreed success threshold, a decision date, and a named sponsor.
What Flexiana produces
A model, simulation, solver, prototype or formal proof run against a baseline. A measured result with its uncertainty. And a route to production.
The decision gate
Did the method clear the agreed threshold, and does the value justify a build?
Likely commercial form
A Proof of Value. Four to eight weeks, run on your own data.
Reasons to stop
The method does not beat the baseline, the value is too small, or the honest conclusion is that the system should not be built.
Build
Turn the method into a system people rely on.
Questions answered
What does the proved method need to become dependable in production: data, integration, interfaces, controls, monitoring and human oversight?
What we need from you
A credible production owner, access to the systems it must integrate with, and the operating constraints it must respect.
What Flexiana produces
A production system with the method embedded, instrumented for drift and failure, with override and audit built in.
The decision gate
Is the system dependable, adopted, and owned by someone accountable for its operation?
Likely commercial form
A senior-pod product-engineering engagement.
Reasons to stop
No credible operating owner exists. We do not build a production system with nobody to run it.
Operate
Keep it right as conditions change.
Questions answered
Is the system still beating the baseline? Have the inputs drifted, the constraints changed, or the recommendations started to look wrong?
What we need from you
Live data, the outcomes of decisions taken, and the judgement of the people using it.
What Flexiana produces
Monitoring, periodic revalidation against outcomes, tuning, and a clear escalation path when the system should be overridden or paused.
The decision gate
Does the system continue to earn its place, or should it be revised, retired or handed fully to your team?
Likely commercial form
A support or co-operation arrangement, scaled to the risk.
Reasons to stop
The system no longer beats the baseline, or your team can run it without us.
Compound
Use what the first result taught us.
Questions answered
What did we learn about the business that opens the next valuable decision? Where can data, methods or components be reused?
What we need from you
The value ledger from the work so far, and a fresh look at the decisions around the one now solved.
What Flexiana produces
A shortlist of the next decisions worth improving, and reusable data and method assets that lower the cost of the next build.
The decision gate
Is there a next decision whose value justifies starting the loop again?
Likely commercial form
Back to Find, with the ground already partly cleared.
Reasons to stop
No further decision clears the bar. That is a legitimate place to finish, and a common one.
The method applied to our own work
One question, worked six times, with one stop
The stages above are a description. Here is an instance of them, published as it happened. Six pieces of work on one question (which missing outcomes are worth paying to recover before a constrained decision), each carrying the evidence status it has earned so far and nothing more.
- Which missing outcomes should you pay to recover? backtested
- An exact solver for decision-focused de-censoring backtested
- When recovering outcomes one at a time is worth the wait backtested
- Recovering outcomes when you do not trust your recovery model idea
- Learning what to recover while you spend on recovering it idea
- When a screening certificate costs more than the solve it saves negative result
Three cleared a baseline and two have not yet
The backtested ones beat the way the decision is made today, measured against an agreed baseline. The two marked idea have no result yet, and the label says so. A more commercial word for them would have been promising.
The sixth is a stop
The last entry is a negative result: a screening step that turned out to cost more than the solve it was meant to save. Under the Prove gate that is a finish, and it stays published so that the next person who has the same idea finds out for the price of a page instead of a month.
Two of the six carry a further hedge in their own text: a field claim would need a live baseline with the test fixed before the data is opened, and until that run exists they say they have not made the claim. That is the Prove gate applied to our own work before it is pointed at yours, and if it did not apply to ours you would be right to distrust it on yours.
The team on your problem
Who is on the team
Teams are small and senior, usually four or five people, with a specialist added only where the problem earns one. The formal-methods specialist appears when something has to be proved, because testing cannot cover it. That is less often than a formal-methods specialist would like.
-
Engagement partner
A senior person accountable for the whole relationship and for the recommendation, including when the recommendation is to stop.
-
Decision scientist / OR
Frames the objective and constraints and chooses the method that fits the problem.
-
Senior product engineer
Turns the proved method into software that can be operated by your people, and that is a different job from demonstrating it.
-
Data engineer
Secures the sourcing, quality and integration the method depends on.
-
Product designer / domain specialist
Makes the system usable and grounds it in how the work is done on the floor.
-
Formal-methods specialist
Added only where the risk justifies a proof, to verify critical logic that testing cannot fully cover.
The value ledger
From the first day we keep a running account of the value at stake, the cost to pursue it, and what each stage returned. The decision to continue is made on that account, together, and at the end whether the work paid off is a number on the same page. Nobody has to argue it in a meeting.
The production-owner rule
We do not start a production build without a credible operating owner on your side, meaning a named person accountable for running the system once it is live. A system nobody owns stops being used within a year, and we would rather not be paid to build one.
Your first 30 days
Within a month you have a decision mapped with its economics, a frank read on the data and the constraints, a shortlist of interventions, and a recommendation to build, reshape or stop, written so that you can act on it that day rather than file it as a backlog.
Read the standards themselves
Everything above describes how an engagement runs. The engineering handbook is the internal version of it: the standards our teams are held to on maintainability, monitoring, automation, product ownership and spending a client's money well, published unedited, so you can hold us to them afterwards. The research library shows the method being applied, with each item's evidence status on it, and Work shows what came out the other end.
FAQ
Questions about how we work
What are the stages of how you work?
Five. We find the decision worth improving, prove the answer on your own data, build only what the evidence justifies, operate the result so it stays trustworthy, and then look for the next decision the first one opened up. Each stage answers one question, and you pay for the next one only when the last has earned it.
How are commitments staged?
Each stage has its own commercial form and a decision gate that must be cleared before the next. Find is a fixed, short Decision Opportunity Audit. Prove is a Proof of Value of four to eight weeks on your own data. Build is a senior-pod product-engineering engagement. You commit to the next stage only once the previous one has earned it. Some companies find that one of the gates is the answer they came for, and stop there.
What happens if the proof fails?
The work stops. If the method does not beat the baseline, or the value is too small, or the conclusion is that the system should not be built, then the Proof of Value has done exactly what you paid it to do: it kept you from a build that would have cost ten times as much and returned less. We have had this happen, and nobody enjoyed it, and it was still the right outcome.
What does each stage deliver?
Find produces a decision map, an economic baseline, the data and constraint reality, and a shortlist of interventions. Prove produces a measured result against a baseline with its uncertainty and a route to production. Build produces a production system with the method embedded, instrumented for drift and failure, with override and audit built in.
Will you always agree to build the system?
No. We do not start a production build without a credible operating owner on your side, meaning a named person accountable for running the system once it is live. A system nobody owns stops being used within a year, quietly, and then everyone involved pretends it did not. We have seen it enough times to refuse the build.
What will we have after the first 30 days?
A decision mapped with its economics, a frank read on the data and the constraints, a shortlist of interventions, and a recommendation to build, reshape or stop, written so that you can act on it the day you receive it rather than file it as a backlog.
Start with the decision
The first step is the small one
A short fixed-price audit that ends in one of three words: go, reshape, or stop. It is the smallest contract we sell and the one we would rather start with, because the risk is there.