Quantum for Decision Makers: Six Gates and a Loop

Educational disclaimer. The framework is a facilitation tool, not a forecast. The worked cases are composites built for teaching. Service names and hardware limits are snapshots from the day this was written and will drift. Treat the Kipu Quantum Hub and the linked papers as the single sources of truth.

What is a decision, when quantum is on the table?

Decision comes from the Latin decidere, to cut off. A decision cuts the other routes off. In the decision-analysis tradition it is an irrevocable allocation of resources: money, people and calendar committed to one route among the alternatives. On this page a quantum computer is one of those routes. It is not the thing making the decision, and it is not a foregone conclusion. A classical solver winning is an allowed answer, and a good framework has to let you reach it.

Two sessions ago you met the optimizers, and one session ago the feature extractor. Both are services on the applications layer of the quantum software stack: you subscribe on the Hub, wrap them in your own domain knowledge, and the hardware underneath is somebody else's problem. That is the layer this session lives on. Somebody will bring you a project that says quantum, and you will have to decide what to do with it at minimal cost and without being slow.

What did the two methods teach you about judging a case?

Each method left you one figure that decides whether today's hardware can carry the case at all. You will meet them again at gate three.

For optimization it is the error budget. Every run on a quantum processor accumulates error from two-qubit gates, readout and decoherence, and the fraction of clean runs falls away exponentially with that accumulated error. Below the budget the histogram of answers concentrates and the result is real. Above it you are sampling noise, and a prettier plot will not save you. Two movements matter. A better chip moves you right, which is the vendor's job and the roadmap. A bigger model moves you up, which is your job, and it is the move that quietly breaks a case that worked in the pilot.

For machine learning it is where the precision-recall curves separate. Two arms can lie almost on top of each other across most of the curve, and a summary figure over the whole curve will call them the same. They are not the same where the business pins its threshold. The gap inside your operating region is what you are paying for, and in session three's measured experiment the classical arm won inside that band. The gap can go either way. You measure at your own threshold, not on the averaged curve, and you allow the answer to be that quantum does not win here.

Where can a case land? The loop

A quantum case does not climb a ladder. It takes a position on a loop, and it can move forward or backward through the loop in the same afternoon. Moving backward is not a failure. It is the framework doing its job.

The four positions, in the order a case usually visits them:

1. Understand the application better. The cheapest place to be. You do not yet know the shape of the problem, or you have no measured baseline to beat. The work is classical and it is yours.
2. Build and evaluate on the Kipu Hub. A test, not a commitment. You have a countable objective or a scarce target class, and you want to know whether a solver or the feature extractor changes anything on your data. Free simulators cover a lot of this.
3. PoC and monitor the space. Two things at once: you build and prove the block that is missing, and you watch the field while you do it. Take this position when the case fits but today's chip does not yet carry it, or when the classical gap is real but the quantum lift is unproven.
4. Production Pilot. You have a measured baseline, evidence that the lift is plausible on data like yours, and a plan for the classical inference path. The pilot is what earns a rollout.

Above the loop sits Production rollout. It is where every case is ultimately trying to go, and nothing anyone commits on the first pass gets there. That is expected. A rollout is earned by a pilot that came back good.

The question printed in the middle never changes: at every position, what would change your mind? If you cannot name the fact that would move the case forward or send it back, you are not yet at a decision.

How do you decide the position? Six gates, one order

The gates are the questions you ask a case, and the order is the whole point. The first three are about shape and arithmetic, and they are cheap to ask. The last three are about business fit, and they only earn their keep once the first three have passed. Each gate is a yes or a no you can defend in a room, and none of them is a number.

Gate two is the one people argue with, so here it is plainly: a test may run without a measured baseline, a pilot and a rollout may not. Threshold rules, a spreadsheet heuristic or a gut feeling are not baselines. They are the current method, and the first job is usually to measure how good it actually is.

Gate six is yours. No tool can answer it for you, and the section on Tinkuq below explains why.

What does each position cost?

Same loop, now with the ledger on the right. Read it one line at a time: the position, the gate that decides it, and what it costs you relative to the others.

Two things worth saying out loud. Landing back at understanding the application is the cheapest outcome in the room and it is not a punishment; it is the framework saving you the pilot you were about to fund. And the last line is the only one nobody reaches on a first pass, because a rollout is earned by a pilot that came back good.

Hold this picture for the cases that follow. Each of them has a landing position and a price.

Four cases, walked through the gates

Each case below is written the way a sponsor would pitch it, in three parts: what happens, how big it is, what data exists. Try to place it on the loop before you read the landing. In the live session the room polled, discussed and polled again before the reveal, and the second poll usually moved.

Case one. What the threshold rules miss

"The alarms fire on single readings. The failures come from combinations."

What happens. Machines fail on interactions between readings that no single threshold catches. Maintenance wants the warning a few days early.

How big it is. A modest set of sensor channels per machine, windows labelled healthy or failing, evaluated once a night.

What data exists. A few thousand labelled windows, few failures among them. Threshold rules today, no trained model to beat.

Lands at: Understand the application better. Deciding gate: 2, Baseline. Rules are not a baseline. Nothing trained exists to beat, so build the classical model first. Then the question becomes real, and the case comes back to the loop with a number attached.

Case two. Why is the customer calling

"They have run out of ideas for improving it."

What happens. A contact centre reads each call's intent from the transcript and routes it, in real time, while the caller is still on the phone.

How big it is. A few hundred thousand labelled calls, routed within seconds, on the call.

What data exists. A few dozen hand-built tabular features per call. Gradient boosting has plateaued on this table.

Lands at: Build and evaluate on the Kipu Hub. Deciding gate: 4, Practicality. The model plateaued, not the case. Inference still has to answer at the phone in seconds, so this is a practicality question, and it passes because quantum feature extraction runs during training only while the phone stays classical. What is missing is any evidence that a quantum step lifts this particular table. The honest landing is a build on the Hub against the plateaued model, not a pilot.

Case three. Claims from orbit

"We want that on our imagery."

What happens. An agricultural insurer settles crop damage claims by classifying loss events from satellite tiles, run in batch.

How big it is. A few dozen features into the quantum step, stacked on embeddings from a pretrained vision model.

What data exists. Tens of thousands of labelled loss events, a measured classical baseline the sponsor wants lifted by a couple of points, and a published lift on a public benchmark of comparable tiles.

Lands at: Production Pilot. Deciding gate: 5, Evidence. The baseline is yours and measured. A published result on a public benchmark says the lift is plausible. The published anchor sat on top of a fine-tuned baseline, not instead of one, which is the rare configuration where a public result travels straight to a pilot on your own tiles.

Case four. Where the antennas go

"We think the plan leaves coverage on the table."

What happens. An operator densifies a metropolitan network, choosing which candidate sites to build. One planning run per metro; minutes are fine.

How big it is. A few hundred candidate sites, each site chosen or not.

What data exists. Every site interacts only with its handful of near neighbours. A greedy spreadsheet heuristic today; its gap to optimal has never been measured.

Lands at: Build and evaluate on the Kipu Hub. Deciding gate: 2, Baseline. The list looks too big, and size is not what decides it. Density is: sparse coupling converges on today's chip. The gap to the spreadsheet is a belief the planning team holds, not a measurement, so measure it against a solver on the Hub before any pilot.

Notice what the four landings have in common. Two of them went to the cheapest positions, none reached the rollout, and the one that reached a pilot got there on a measured baseline plus published evidence, not on enthusiasm. That is the distribution to expect from a framework that is working.

Can a tool do this for you? Tinkuq

Tinkuq is Kipu's matchmaking assistant. You describe a case in a short interview and it returns an assessment of whether the case fits Kipu's optimizers or feature extraction, with a suitability verdict and the first step it would take. In the live session we ran the same four cases through it and set its verdict against the room's own reading, then said plainly where they agreed and where they did not.

It asks for the same facts the gates ask for, so the pitch format above is the preparation. For a machine learning case: the task and data type, the dataset scale, the inference latency you need, the model you run today with its current metric, and the size of an improvement that would matter. For an optimization case: the problem type, the count and type of the variables, the constraint structure, the solver you use today and its gap, how often you re-optimize and whether you need the true optimum or a good answer. Two facts it will ask for if you leave them out: how many features go into the model, and what your current metric is together with the lift that would be meaningful.

One thing to know when you use it. Tinkuq is hardware neutral: it does not care whose chip you end up on. It is not vendor neutral, and nobody should pretend otherwise. It assesses whether a use case fits Kipu's solutions, and its answer ends in a Kipu tool call. That is exactly why gate six is your job and not the tool's.

For cases somebody has already carried further, the Hub's use case library holds worked examples with code, data and a result attached. Read one against the gates.

When should you decide, and with how much information?

Most positions on the loop are reversible. A build on the Hub can be abandoned, a PoC can be paused, and even a pilot can be unwound. In his 2016 letter to Amazon's shareholders, Jeff Bezos called these two-way doors and gave a rule of thumb for them: make most decisions with somewhere around seventy percent of the information you wish you had, because waiting for ninety is usually slow, and be good at recognizing and correcting the ones that turn out wrong. The dashed arrows on the loop are that correction. Take the cheap position early, learn, and move.

Production rollout is the exception. Dixit and Pindyck describe an investment by three characteristics: it is partially or completely irreversible, its rewards are uncertain, and you have some leeway about its timing. Under those three conditions the option to wait has value, and the right move is to buy the information that would change your mind before committing the irreversible sum. That is why the ledger prices every position below the rollout, and why the rollout is reached only through a pilot that came back good.

One last rule, from the decision-analysis tradition: judge a choice by what was known when it was made, not by how it turned out. A pilot that returned a classical win was a good decision if the gates said pilot. A rollout that happened to work was a bad decision if it skipped them.

Conclusion

Quantum decision making is ordinary decision making with one more route on the table. The loop gives the case a position, the gates give the position a reason, and the ledger gives the reason a price. The cheapest next step is to write your own case in the three-part pitch format above, walk it through the six gates in order, and record where it lands and why. If it lands at understanding the application, you have saved a pilot. If it lands at a pilot, you have a claim that survives an audit.

The optimization and machine learning sessions carry the evidence behind gates three and five. Tinkuq runs the interview. The full curriculum is available via the Academy page.