Introduction to the Kipu Quantum Hub

Business track, session one. This is the self-paced edition of the Kipu Academy's opening business session. If you are looking for the hands-on counterpart, the first lab picks up where this page ends.

This page is for anyone making decisions about quantum computing, not for engineers: no code, no math prerequisites. Where a live demo is worth trying yourself, you will need a free Kipu Quantum Hub account, sign up at hub.kipu-quantum.com. Everything else here runs without one.

Misconceptions around quantum computing

If you think about what you and your peers have heard about quantum computing, a handful of claims come back every time: it tries every answer at once, it will replace classical computers, it is ten years away. Some of these are myths, and some are true but need context. The biggest misconception, however, is the idea that quantum computing is illogical and unpredictable. The math behind quantum computing, matrix algebra, has been studied for over a century, and the blueprint for a universal quantum Turing machine dates from 1985 (Deutsch, Proceedings of the Royal Society A 400, 97).

The claim that a quantum computer computes every solution at once is a myth. Superposition holds only until measurement, and quantum algorithm design is the work of arranging interference so that useful answers survive the collapse. Speedups exist, and they are problem-specific rather than universal.

Calling it a faster supercomputer is a myth too, and it is the one that misdirects planning the most. A quantum computer is a fundamentally different computational model, and the useful mental model is a hardware accelerator: a specialist co-processor you hand a specific kind of problem, the way you hand graphics or machine-learning workloads to a GPU. It extends the computing stack rather than replacing it, which makes the claim that it will replace classical computers a myth as well. Every practical quantum application in this course wraps a quantum kernel in classical preparation and classical post-processing.

A fourth myth is that the machine is weird and does not follow logic. Superposition introduces randomness, but the evolution of a quantum state is deterministic, unitary, and described by the same matrix algebra. Random and illogical are different things.

"It's not real yet, it's for research only" is outdated rather than mistaken in principle. Quantum computers exist, are commercially accessible, and you can run a job on one this week. The open question is not whether they run but which problems they help with.

The last claim, that quantum computing will break all encryption and solve climate and medicine, is true but scoped. These are real targets, and the encryption impact in particular is why post-quantum cryptography exists. They are workloads for later hardware generations rather than for today's machines, and what is left for today is a computation-specific accelerator that can be tested and built on now.

If quantum computers help with specific problems, which ones?

The history of quantum computing has had several important inflection points. It started with academic quantum supremacy, where mostly hardware players showed that a quantum computer could perform a calculation faster than a classical one. The calculation did not necessarily represent anything meaningful, in most cases the problems were randomly picked, but it proved that some problems are outside the reach of classical computers entirely. This is the territory of academically proven algorithms: ones with a mathematical guarantee of speedup over any classical counterpart. Shor's algorithm, the one that can break RSA encryption by factoring, is the famous example. The catch: most proven algorithms need hardware that does not exist yet.

The current era, as of 2026, is computational quantum advantage. Pioneering groups moved past academic curiosities and found practical computations that make use of the additional capacity quantum computers offer, and they keep finding more, showing that the overlap between real-world problems and quantum-solvable problems keeps growing. These are computationally advantageous algorithms, found empirically rather than derived: they run measurably faster on quantum hardware without a proof explaining why, and they work anyway.

The upcoming effort focuses on applying these computational advantages to industrial problems with a commercial benefit, ushering in the era of industrial quantum usefulness. All three movements coexist and chase different goals, and expect lively debate on which category applies to which result: definitions get mixed, and a press release needs a good story. What ties this era together is that applications become commercially valuable: somebody pays for them because the result is worth more than the cost of producing it.

Mathematical proofs take years and usually assume future hardware. The empirical route is shorter: an algorithm is tested on the machines that exist, measured against the best classical baseline, and adopted where it wins. The zone Kipu aims at is the intersection of implementable on current hardware and commercially valuable. A proof arriving later is the ideal case rather than a precondition for the business case.

What could we mean by industrial quantum usefulness?

Industrial quantum usefulness (noun): a quantum application that is implementable on current hardware and commercially valuable.

All of our efforts at Kipu, and this is where we often experience friction with other players in the industry, are aligned to that one direction: does it help make quantum industrially useful? If yes, we go ahead. If no, it goes on hold for now.

Where to find inspiration: use cases on the Hub

The Kipu Quantum Hub has a public marketplace with use cases published by partners and by Kipu, spanning routing, quantum machine learning, finance, and energy. They are published as inspiration, and the question they exist to trigger is whether your own organization has a problem shaped like one of them. The marketplace is a sample of what is being built, not a catalogue of it.

To give you an idea of what we mean by a use case, take a look at our in-house visual demo:

Air traffic flow management. When two flight paths cross, the planes must travel at different altitudes. Assigning altitude channels to a set of flights is a graph coloring problem, and the live demo lets you pick flight connections in Europe, press an optimization button, and retrieve the assigned channels from the quantum optimizer. The optimization runs on a simulator in the background rather than on a QPU, so the demo shows the shape of a quantum application and not hardware performance.

Predictive maintenance. A cable-break prediction demo, built out of a project with NTT DATA and Komatsu, uses quantum machine learning to extend the window in which equipment failure can be predicted. How far that window moves is not published, so the demo stands as an application shape rather than as a measured result. The user it is designed for is an operator who can schedule maintenance before the failure happens.

FX hedging. What is true for large corporates is also true for private investors. The drift of exchange rates between currencies can eat away your capital gains. You can make your cashflow structure more predictable by hedging against those risks.

Why offer so many different quantum computers?

If you have browsed around after looking at the use cases, you might have come across the Quantum Backends (requires login). A reasonable question: why does one platform offer so many different quantum computers? The reason is not price competition between vendors. There are fundamentally different ways to build a qubit, and each way trades off three properties: qubit count (how large a problem fits), error budget (how many operations you can chain before the result dissolves into noise), and connectivity (which qubits can talk to which, and therefore how many extra operations a given algorithm costs).

Superconducting machines from IBM, Rigetti and IQM have fast gates and mature fabrication, and the largest announced devices are in the thousand-qubit range. The Kipu results cited in session two were run on 156-qubit IBM Heron processors, well below that ceiling. The price of the modality is millikelvin refrigeration and qubits fixed in place with nearest-neighbor links, so you benefit when your problem fits the chip layout and pay extra operations when it does not.

Trapped ion machines from IonQ and Quantinuum have the highest gate fidelities and effectively all-to-all connectivity, because the ions can be rearranged at will. Gates are slower, and device sizes stay small: the largest in Kipu's published trapped-ion experiments are IonQ's 36-qubit Forte (arXiv:2506.07866) and a 64-qubit barium development system (arXiv:2604.26861).

Neutral atom platforms from Pasqal and QuEra look on paper like one of the best recipes, thousands of atoms in reconfigurable geometries. In practice the machines are optical instruments of mirrors and lenses tuned by hand at sub-millimeter precision, and atom loss and reload time between shots are the daily tax.

Linear optical systems from Quandela and Xanadu compute at room temperature and send photons through existing fiber. Gates are probabilistic and photon loss dominates, so circuits have to stay lean.

Quantum dots, pursued by Intel and other silicon-spin efforts, are the semiconductor answer: CMOS-compatible, tiny, and printable one day by existing chip fabs. The technology is early stage, and crosstalk between dots is the current fight.

NV and other color centers in diamond run at room temperature on a desktop and hold quantum memory for a long time. A device typically carries one to six qubits, and networking many of them together at scale is unsolved.

There is no clear winner, and algorithms today are handcrafted to a specific hardware stack. Most vendor roadmaps converge on the same milestone, fault-tolerant error correction around 2030, which is the point at which the long, dense circuits the proven algorithms need become runnable. That date is a projection published by the hardware makers, not a demonstrated result. Until it arrives, the empirical method from the previous section is the one available.

One Hub, many machines

This diversity is why a serious platform is multi-vendor by design. The Hub connects superconducting, trapped-ion, neutral-atom and photonic machines from different vendors, alongside GPU-accelerated and classical simulators, behind one SDK, one CLI and one API. Checked live on 2026-08-24 that was 22 backends, of which 16 are QPUs from 7 vendors and 6 are simulators; 20 of the 22 are reachable from the SDK. The count moves, and the current machine list is always on the quantum backends page. You pick the backend whose trade-offs fit your problem, or start on a free simulator and move to hardware unchanged, which is exactly how the hands-on track of this course proceeds, and how you avoid paying for hardware time while you are still debugging.

The machines are only the bottom layer. The platform has four of them:

• L0, hardware: the QPUs and simulators above.
• L1, orchestration: the software that makes them usable together: SDK, CLI, REST API, data pools, classical compute, observability.
• L2, services: ready-made solvers you subscribe to instead of building. The two you will meet in this course: Miray, the quantum optimizer behind the air-traffic demo, and Rimay, quantum feature extraction for machine-learning pipelines. Both run on simulators and on real QPUs. Both are also heuristics: the BF-DCQO algorithm behind Miray carries no a-priori bound on how far a returned answer sits from the optimum, so what it is worth is settled by benchmarking rather than by proof. Miray's free simulator tier is capped at 20 variables (Hub service description, checked 2026-08-24), which is prototyping scale and not production scale. The marketplace adds partner services on top.
• L3, applications: the use cases from earlier, built from the layers below.

The same four layers are used as the reference map in every later session.

Anatomy of a quantum-centric workflow

So how does anyone actually build one of those applications? Behind the air-traffic demo sits a small program: a quantum-centric workflow. Visualized, it is a chain of self-contained components, each with a defined input and output:

Walk the air-traffic example through it:

1. Encoder. Your selected flights go in. The encoder translates them into an unconstrained binary optimization formula, a mathematical object the quantum computer can work on. (The formula family and how to build one is the subject of the optimization sessions; for now it is enough that "flights" become "math".)
2. Optimizer. The quantum kernel, in this case the Miray optimizer, searches for the configuration with the lowest value of that formula: the channel assignment where no planes collide.
3. Decoder. The optimizer returns a bit string, raw 0s and 1s. The decoder translates it back into the language of the problem: plane one on channel one, plane two on channel three.
4. Visualizer. The decoded result becomes the map with colored flight channels a dispatcher can read.

Three properties of this model carry most of the weight. Each block is a service, self-contained with defined inputs and outputs, which is what makes blocks reusable across applications. The quantum kernel is a specialist component you subscribe to rather than build, so the optimization expert never has to learn your domain and you never have to learn theirs. And the quantum and classical parts interleave: data preparation before, result processing after, with the quantum step as one stage in an otherwise classical pipeline.

One practical rule runs from the first lab onward: develop on simulators first. Quantum hardware time is expensive, simulators are free or cheap and behave identically at small scale, and a mistake found on a simulator costs nothing. The move to hardware comes once the workflow is proven.

The hands-on lab builds your first circuit on the Hub, and the Academy page has the full curriculum.

The definition, three ways