Framework for Principles of Operation for a Quantum Computer

This informal paper proposes a framework for the principles of operation for a quantum computer, which is a document which specifies all relevant detail needed by a quantum programmer wishing to develop quantum programs for a particular quantum computer or family of similar quantum computers.

It is not a goal to specify any or all details of the hardware and internal design of the quantum computer, but only those details which the programmer needs to control to achieve the functional effect of a quantum program. This includes capacity and performance limits, but not necessarily all details of performance — coherence time is important, as is the approximate time needed to execute a typical quantum logic gate, but the exact execution time of each gate is not needed.

It is not a goal of this paper to provide detailed principles of operation for any particular quantum computer, but simply to summarize at the conceptual level what a principles of operation document should contain.

This conception of principles of operation also applies to quantum computer simulators, although there may be other details needed for simulators, such as configuring the simulator for different hardware models.

For brevity, this paper will refer to the principles of operation as POP. Generally, POP will refer to the document which details the principles of operation.

Audience for principles of operation

The intended audience for a POP document is quantum programmers — anybody writing code to be executed on a quantum computer (or quantum simulator).

Audience for this paper

In contrast to the audience for a POP document itself, the audience for this paper is:


This paper is not intended to cover any of the following:

Fundamentals of quantum computing

The POP is not intended to offer either an introduction to quantum computing or the detailed fundamentals of quantum computing, but both are essential before the quantum programmer will be able to make sense of the POP.

A standardized fundamentals of quantum computing document is needed. Some of the concepts it would cover include:

Plain English, please

The jargon of quantum mechanics and linear algebra may be very tempting and is used very commonly in discussions of quantum computing, but it is an explicit goal of this paper to encourage plain English language to the maximal extent possible. Or at least the common language of classical computing if any jargon is needed.

To the extent reasonable, greek symbols should not be used, in favor of plain English. The goal is to be greek-free.

Some of the jargon of quantum mechanics, linear algebra, and quantum computing will certainly be relevant and warranted, but much of it is used to excess and really isn’t needed.

The jargon of quantum mechanics and linear algebra was quite appropriate 20 years ago when quantum computing was still dominated by physicists, but that time is now past, or at least passing quickly. Sure, the physicists should continue with their jargon, just as electrical engineers continue with their jargon for classical computing, but documents such as a POP, intended for consumption by programmers, should have an appropriate level of terminology and usage.

Plain English vocabulary

A lot of the cryptic jargon of quantum mechanics and early quantum computing needs to be replaced with plain English.

The only exceptions are when the existing jargon is more helpful to quantum programmers.

Some examples of terms which need to be simplified if not avoided entirely — in the context of the POP:

The goal is not unlike classical computing where the jargon of electrical engineering and integrated circuit design is not needed for software developers.

Much of the vocabulary should be established in the separate fundamentals of quantum computing document, which provides the foundation upon which the POP is built.


Both the POP and fundamentals of quantum computing should have reasonable glossaries of the common and important terms.

I have compiled a super-glossary of terminology relevant to quantum computing, with over 2,800 entries:

Some reasonable subset of 50–100 or so terms would be appropriate as a glossary for the POP and fundamentals of quantum computing.

Ket (Dirac bra-ket) notation has to go

The cryptic ket (Dirac or bra-ket) notation for quantum state adds no real value to the lives of quantum programmers. Researchers and mathematicians may prefer it, but it doesn’t facilitate the understanding and use of qubits and quantum logic gates.

Exactly what should replace it remains to be been, but simply using 0, 1, 00, 01, 10, 11, etc. are probably sufficient 99% of the time.

And use a simpler notation such as 0/1 or 0+1 for superposition.

Ditch the Bloch sphere?

The Bloch sphere has only a little utility. It may have some limited utility for teaching the basic concepts of quantum computing, but not much more. Three axes, X, Y, and Z, and that’s all it really does for you.

Most problematic, the Bloch sphere only applies to a single, isolated qubit, and does not extend to multiple qubits or even entanglement of two qubits, so it is indeed of very, very limited utility.

The only real point of the Bloch sphere is that it represents a unit vector from the origin or intersection of the three axes and which can be rotated about any of the three axes as many times and directions as desired.

In short, quantum logic gates need to specify which axis the quantum state vector is being rotated about, but adding the verbiage “in the Bloch sphere” adds no information or real (or complex!) value to the description.

Bridging the world of quantum computing to the world of classical computing

The overarching goal here is to bridge the emerging world of quantum computing to the existing (and evolving) world of classical computing.

To date, the world of quantum computing was able to grow in its own world, but if we want to enable more mainstream applications to utilize quantum computing, we need to start speaking a single, unified language, not two disparate universes.

Of course this will mean introducing a number of novel concepts to the world of classical computing, but that’s not a new process to computing, although the extreme nature of of the quantum world does take the process to a whole new level.

Universal quantum computers?

There is a lack of clarity over the meaning of the term universal quantum computing:

I’ve explored the former in my paper, What Is a Universal Quantum Computer?, but that’s more of a pie-in-the-sky pipe-dream rather than anything we either have today or are likely to see in the next few years.

I still want to leave the door open for that ultimate machine, but this paper was written presuming the reality of the latter, limited definition for a universal, general-purpose quantum computer — quantum-only, very few if any classical features, as they are available today and likely to appear over the next few years.

The general concepts of a POP are the same regardless of the details of the computing architecture, but the specific structure and details would vary greatly between these two variants of what constitutes a universal quantum computer.

This paper is prescriptive, not descriptive

This paper is not intended to describe existing documentation of quantum computers, other than mention some in passing, but is instead intended to prescribe what information should be included in any future documentation.

Family of machines

The early days (years and decades) of classical computing were marked by each new machine being rather unique relative to all machines which preceded it, with only modest to moderate similarities at most, but by the mid-1960’s the concept of a family of fairly similar machines became common. It became common to speak of models in a family, with the notion that most if not all programs which ran on one model would run unchanged on other models in the same family.

The concept of the POP is intended to document a family of machines which share details which enable a single program to run unchanged across all models of machines in that family.

To be clear, a family of machines is not the same as units of a machine — all machines manufactured according to identical specifications. The models of a family will each have their own hardware specifications — see the Implementation Specification section, which may be very different between models, even though their POP-level specifications would be identical, other than a few details such as number of qubits or coherence time, but the POP would at least give the minimum specifications which are guaranteed to be common across all models within the family.

Quantum computing is still in its early days, comparable to those early days of classical computing, so each new quantum computer is relatively unique, with only modest to moderate similarity to earlier machines, so the family concept is still not fully relevant, but the writing is on the wall, so within a few years we should see more instances of new machines which are incremental enhancement and extension of existing models, such as focusing on higher qubit counts and longer coherence time, rather than radical changes in architecture. Granted, a particular vendor might introduce a whole new family every few years, but still the models within a given family would have the same POP.

There will of course be differences in technologies and approaches of different vendors, with each vendor likely to define their own family concepts.

At some stage we could well see developments comparable to the Intel X86 architecture where the family concept crosses vendors, allowing programs to be run unchanged on machines from different vendors. That’s not a reality today, and not likely in the near future, but it is worth being prepared for that eventual reality.

The POP and family concepts are still very relevant even if the family has only a single model of machine. In many cases, this may simply the first model of an intended family of machines, with the POP clearly documenting the rules of the road so that quantum programs written for that initial model of the family will more likely be able to run unchanged on new models as they become available.

Details to be specified for a quantum computer

Now on to the actual details which a POP needs to specify for a quantum computer:

See the following section for a framework for details for individuals quantum logic gates.

Details to be specified for each quantum logic gate

Each quantum logic gate needs the following detail to be defined:

Any meta-gates, which impact execution but do not necessarily directly impact the state of any qubits, such as:

Ultimately, most if not all of this detail for quantum logic gates should be standardized across a wide range of quantum computers. A generic POP, so that everyone won’t have to reinvent the wheel for every new machine.

Expectations for phase

Superficially, phase or phase angle is a continuous value, but theoretically and practically it cannot be an infinitely continuous value — it has to have some degree of granularity, precision, and gradations, which need to be specified for each model of quantum computer. Algorithm designers and application developers need to know:

This information affects both gate execution and measurement.

Naming and numbering of qubits

The POP should state clearly how qubits are numbered. Typically they start at 0 (zero) and go to n-1, but that’s not mandatory.

Qubits might also have names, such as Q0, Q1, etc. Again, not mandatory, but any convention should be clearly documented.

User-defined operations

A given quantum computer may or may not support user-defined operations, such as specifying a particular unitary matrix and associating it with a symbolic name.

In any case, the POP should clearly document how this is to be done, or if it can be done at all.

Qubit connectivity

Eventually quantum computers may evolve to the stage where all degrees of connectivity are supported — any two qubits in any order, but current and near-term quantum computers have significant restrictions on connectivity.

Any restrictions on connectivity of qubits should be clearly stated in the POP, both as general rules and specific combinations of qubits. The POP should specify which qubits can be used as control qubits, and which qubits can be used as target qubits for each control qubit.

A table might be nice and appropriate, but is not mandatory.

A formula or set of formulas may also be appropriate, but not mandatory.

In any case, the POP must make it very easy for the programmer to understand which qubits can be entangled, which can be used as control qubits, and which can be used as target qubits.

Composite operations

Some quantum logic gates, such as SWAP, are not really single operations, but a composite of operations, a sequence of individual quantum logic gates which must be executed sequentially to accomplish the composite operation. The POP should make such cases very clear, detailing the composed quantum logic gates, and including any performance implications.

Parallel and register operations

Some quantum computers may support the ability to execute a single operation across an arbitrary number of qubits in parallel, such as the ability to define a register as a collection of continuous qubits and then execute a quantum logic gate on the collection as if the gate were being executed for each individual qubit of the collection. The POP should make such cases very clear, including any performance implications or limits.

Special features

The POP should also document whatever special features a particular machine or its operating software may support, presuming that such features are visible or controllable from a quantum program.

For example:

Support for registers

Quantum computers do not have registers per se in the sense of a classical computer. Except for entanglement between pairs of qubits, each qubit is a discrete entity, analogous to a classical flip-flop.

The programming tools for a quantum computer may syntactically support a conception that behaves as if it were a register to a limited degree, usually in terms of applying a single quantum logic gate to all qubits in the defined register in parallel, but operating on each qubit independently rather than treating the individual qubits as if they were connected as they are in a classical computer (such as for arithmetic on numbers.) The POP should make such cases very clear, including any performance implications or limits.

Specialized machines

Not all quantum computers will be general-purpose machines. This POP framework applies only to general-purpose machines which support quantum circuits consisting of a sequence of general-purpose quantum logic gates.

The D-Wave 200Q from D-Wave Systems is an example. It indeed does some form of quantum computing, focused on optimization, but is not a general-purpose quantum computer per se. In fact, it’s more of an analog computer than a digital computer. That doesn’t make it any less interesting or useful, but does keep it outside the realm of general-purpose quantum computing.

Instruction formats — bit layout, assembly language, and APIs

A classical computer places a lot of attention on precisely how bits and bytes are organized and packed into instruction formats. Operation codes and operations primarily focused on assembly language for symbolically representing machine instructions.

Some quantum computers may support an assembly language.

And some quantum computers may be controlled using an API used within a high-level programming language.

Ultimately the same quantum logic gates will be executed, but the precise syntax with which they are expressed may vary.

The POP should document quantum logic gates in any and all of the forms which programmers of the machine are permitted to utilize.

Bit-level layouts are probably a lot less important in this new era of high-level language APIs, but may in fact be welcome, especially if there are nuances of function which are made more clear using bit layouts. For example, the precision of various quantum logic gate parameters.

API bindings

The API for using a particular quantum computer may look rather different in different programming languages, such as Python, Java, C++, and Lisp. These differences in APIs are referred to as bindings or language bindings, with each programming language having its own binding for a given API function or feature.

Unfortunately, there is no universal API language at present, although Python seems quite popular right now.

Generally, APIs should be specified and discussed in language-neutral terms, such as pseudo-code or tabular form.

Alternatively, APIs in a POP could be specified with multiple bindings to cover the variety of languages expected to be useful for this type of machine.

Whether Python becomes the standard or at least the de facto standard for API language bindings remains to be seen. In any case, vendors could be excused if they jumped on the Python bandwagon at this juncture.

My personal preference and advice is to remain language-neutral as much as possible.

Programming model

The principles of operation is distinct from the programming model. The former specifies what the machine can do and how to control the machine, while the latter gives the programmer guidance as to how to accomplish application-level tasks — how to map application-level functions to machine-level functions.

A programming model employs metaphors to describe how the programmer should think, while the POP merely describes the full details of the most basic functions, the most basic building blocks for software, instructions or quantum logic gates. A programming model focuses more on larger, more sophisticated building blocks, such as functions, objects, classes, data structures, and modules. The POP is the atomic or molecular level of computation, while the programming model focuses on larger structures.

Granted, the programmer needs both, but this paper focuses only on the principles of operation level.

The jury is still out on how best to represent many application-level functions in the language of quantum logic gates. Much more research, experimentation, and development is needed.


Copious examples should be used for all features in the POP. They may not be exhaustive, but enough to illustrate all significant variations, especially where distinct quantum states cause distinctive results.

Not just examples of inputs, but examples which show the various possibilities for results of particular operations on particular inputs.


Algorithms are extremely important to exploit the capabilities of any computer, classical or quantum.

The programming model will be the place where algorithms begin to flourish.

The POP itself is below the level where algorithms take root. The POP defines the very basic building blocks, the soil, nutrients, water, air, sunlight, gravity, and physical environment where algorithms can be rooted, but doesn’t define what such plants will look like. Algorithms are essentially the DNA for the plants that are expected to grow in a quantum computer. The POP details the individual nucleotides of the DNA, but not the combinations of nucleotides which are composed as algorithms.

Issues related to algorithms for quantum computers are discussed in much greater detail in my paper The Greatest Challenges for Quantum Computing Are Hardware and Algorithms.

Document layout and formatting

This paper takes no position on layout and formatting of a POP document. Not that such matters are not important, but the focus here is on content (function) rather than on form.

Outline and template

Although this paper provides a very rough outline or roadmap for a POP document, it certainly fails to provide a true template for precisely the content and layout of such a document. That’s okay since that is not its intent, but ultimately it would be desirable to have something much closer to a true template.

Or a dummy document for a hypothetical machine.

Machine-readable principles of operation

In addition to a human-readable document, all of the technical details of the POP should be available in XML, JSON, and other structured information formats. This will facilitate comparing machines and also allow applications to query specific details which may be needed.

Machine-readable documentation should be available both a static files, such as on the GitHub repository, as well as a REST API which would facilitate narrow queries for specific details.

Some examples of principles of operation from classical computing

Quantum computers certainly do not have to follow in the precise same footsteps of classical computing, but there’s some value in learning from the hard-learned lessons of classical computing.

An example of this tradition from the 1960’s (1964) — over 50 years ago:

That same architecture, as upgraded over 40 years (2004) into IBM’s z architecture:

Or for the common Intel computer architecture (x86):

Intel provides a number of volumes, either separately or combined — the link above:

Some current quantum computing documentation

Doc for quantum logic gates for use in Python for Rigetti Computing:

Rigetti quantum processing unit specifications:

Quantum instruction language for Rigetti — A Practical Quantum Instruction Set Architecture:

Open Quantum Assembly Language (OpenQASM) from Quantum Information Software Kit (QISKit) for IBM Q Experience:


A quantum simulator may be designed to specifically simulate an actual quantum computer with precise accuracy, or be more of a general, abstract simulator with no implied claim that it precisely mimics any particular real quantum computer.

Every simulator should have a detailed POP. If the simulator does indeed match a particular real quantum computer, the details can be by reference rather than duplicated. But usually there will be some differences, if only performance, so any differences or deviations should be very clearly spelled out in the simulator POP.

A special area of difference for simulators, besides raw performance, is quantum noise. Quantum computers are more probabilistic than deterministic, while simulators will tend to be strictly deterministic unless the simulator artificially introduces some element of probability, notably as simulated noise. The POP should clearly state the default degree of probability and noise, as well as any configuration settings to amplify, diminish, or otherwise control the degree of probability and noise.

Irrelevant but interesting hardware details

Information about the hardware of a quantum computer is of course interesting, but not really relevant to the task of developing and using quantum programs at the level of the POP:

Of course the quantum computer will have user documentation and software documentation beyond the level of the POP, including the Implementation Specification described in the next section.

Implementation specification

A subset of hardware details may not be absolutely required for development of quantum programs, but may well be of interest to the quantum programmer to better understand what is really going on in the physical machine. This may give the quantum programmer valuable insight, but again, the average quantum programmer should be able to fully develop a successful quantum program using only the POP. Some more advanced or specialized development may in fact require detailed knowledge of the implementation.

The implementation specification will be specific to specific models of a quantum computer even if a single POP describes a full family of multiple models of quantum computer.

The implementation specification might ideally be a separate, standalone document, but could also be an appendix to the POP, with multiples appendices for multiple models of a family of quantum computers. Or, it might be a single appendix in tabular form, with columns for each different model.

The implementation specification is distinct from the operations guide for a quantum computer. It’s not about electrical or cooling requirements or physical dimensions, but it would be about performance data.

A separate paper will elaborate the framework for an implementation specification, but some of the general features include:

Each simulator should also have its own implementation specification, although it will be less about hardware and more about performance and simulating hardware features, including decoherence.

When might principles of operations documents become available?

Availability of POP documents is an indication of the level of maturity of the industry. The lack of availability indicates that the industry is still rather immature.

I would say that quantum computing is at a comparable level of maturity as classical computers were in the early 1940’s. Maybe in another five years the industry might advance to the level of maturity of classical computers in the early 1950’s. That’s still quite a ways off from classical computing in say the mid to late 1960’s when mainframes and minicomputers can be said to have finally hit their stride.

What’s next

This framework is a work in progress.

It may be a few years before any sense of maturity in specification of principles of operation is achieved for this still-nascent field and industry.

In the meantime, documentation for the detailed principles of operation of quantum computers will remain spotty and uneven at best.

In fact, what is really needed is not to carefully document existing machines, but to focus on incrementally leapfrogging current machines by at least several generations of hardware and architecture to produce systems which are actually able to support real applications rather than relatively toy-like proofs of concept.

I wouldn’t hold out for my own pie-in-the-sky universal quantum computer, but something much closer to it, at least part of that vision.

As I point out in my algorithms paper, The Greatest Challenges for Quantum Computing Are Hardware and Algorithms, the difficulty of developing algorithms for quantum computing is really holding the field back. And very limited hardware is holding algorithms back.

All of that said, each new machine should endeavor to be documented with a POP as defined by the framework presented in this paper.

Freelance Consultant

Freelance Consultant