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 of a Quantum Turing Machine exists since 1985.

"It computes every solution at once." Myth. Superposition holds only until measurement; the art of quantum algorithm design is arranging interference so that useful answers survive the collapse. Speedups exist, but they are problem-specific, not universal.

"It's just a faster supercomputer." Myth. A quantum computer is a fundamentally different computational model. The productive 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's weird and doesn't follow logic." Myth. Superposition introduces randomness, but the evolution of a quantum state is deterministic, unitary, and described by mathematics that has been studied for a century. Random is not the same as illogical.

"It will replace classical computers." Myth. It extends the computing stack rather than replacing it. Every practical quantum application you will meet in this course wraps a quantum kernel in classical preparation and classical post-processing.

"It's not real yet, it's for research only." Outdated. 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.

"It will break all encryption and solve climate and medicine." True, but scoped. These are real targets, and the encryption impact in particular is why post-quantum cryptography exists. But they are workloads for later hardware generations, not for today's machines.

Computation-specific accelerator, testable and developable today.

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: they run measurably faster on quantum hardware, found empirically, by trial and error, without a proof explaining why. They work.

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 practical stance is empirical: test an algorithm on the machines that exist, measure it against the best classical baseline, and adopt it where it wins. The zone worth aiming at is the intersection of implementable on current hardware and commercially valuable. If a proof arrives later, that is the Nature-paper best case, but the business case never waited for it.

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

Knowing the definition is nice; seeing live examples is usually better. 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 exist as inspiration: browse them, and every now and then dare to ask: "does my organization have a problem shaped like this?" The marketplace by definition will never be complete, but it will give you a feeling for what is going on.

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 quantum computer (simulator) works in the background. If you have been following along, you just ran a quantum application: congratulations.

Predictive maintenance. A cable-break prediction demo built based on a project with NTT DATA and Komatsu uses quantum machine learning to extend the window in which equipment failure can be predicted. In the end we need to keep the end user in mind: we envision quantum-centric tools at an operator level, in the hands of somebody who can schedule maintenance before the failure.

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? Not for price competition. The reason is that 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 (IBM, Rigetti, IQM): fast gates, mature fabrication, scales past a thousand qubits. The price: millikelvin refrigerators and qubits fixed in place with nearest-neighbor links, so you benefit when your problem fits the chip layout and pay a penalty when it does not.

Trapped ion (IonQ, Quantinuum): the highest gate fidelities and effectively all-to-all connectivity, because the ions can be rearranged at will. Slower gates, and scaling past a hundred qubits is hard.

Neutral atom (Pasqal, QuEra): on paper 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; atom loss and reload time between shots are the daily tax.

Linear optical (Quandela, Xanadu): photons compute at room temperature and travel through existing fiber. Gates are probabilistic and photon loss dominates, so circuits must stay lean.

Quantum dot (Intel and other silicon-spin efforts): the semiconductor answer, CMOS-compatible and tiny, which means existing chip fabs could one day print them. Early stage, with crosstalk between dots the current fight.

NV / color center (diamond spin defects): runs at room temperature on a desktop and holds quantum memory for a long time, but typically only one to six qubits per device, and networking devices 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 in effect raises the error budget by orders of magnitude and unlocks the long, dense circuits the proven algorithms need. Until then, the empirical doctrine from the previous section is not a compromise; it is the method.

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; 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. Read the platform as a four-layer stack:

• 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 are the product of years of algorithm research and heavy investment in hardware experiments, and both run on simulators and on real QPUs. The marketplace adds partner services on top.
• L3, applications: the use cases from earlier, built from the layers below.

You will see this stack again; it is the map on which every later session pins itself.

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 do the heavy lifting:

• Each block is a service, self-contained with defined inputs and outputs, so blocks are reusable across applications.
• The quantum kernel is the specialist you subscribe to, not build. The optimization expert does not need your domain; you do not need theirs.
• Quantum and classical interleave. Data preparation before, result processing after; the quantum step is one specialist stage in an otherwise classical pipeline.

And a practical rule you will meet from the first lab onward: develop on simulators first. Quantum hardware time is expensive; simulators are free or cheap, behave identically at small scale, and let you make your mistakes where they cost nothing. Upgrade to hardware when the workflow is proven.

Ready to run this yourself? The hands-on lab builds your first circuit on the Hub, and the Academy page has the full curriculum.

The definition, three ways