Framework for Principles of Operation for a Quantum Computer

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:

  • Technical writers tasked with actually writing a POP document.
  • Product managers responsible for designing quantum computer products for use by quantum programmers.
  • Designers of quantum computers and their firmware responsible for specifying the details of their machines which will be visible to quantum programmers.
  • Quality Assurance staff who will be reviewing and using the POP.
  • Support staff who will be supporting customers who are developing quantum programs. They may be the final reviewers, the guinea pigs to validate the quality and readability of the POP document.
  • Managers of any of the above, who need to be aware of the importance, scope, and cost of producing a high-quality POP document.


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

  1. Hardware details not directly visible to or detectable by a quantum program. See the Implementation Specification section.
  2. Software applications.
  3. Application frameworks.
  4. Algorithms.
  5. Operating software.
  6. User interface.
  7. General introduction to quantum computing.
  8. Fundamentals of quantum computing. Although it is debatable whether a standardized set of quantum logic gates should be considered part of those fundamentals rather than being detailed in a POP. Maybe, someday, but we’re not there yet.
  9. The physics of quantum computing.
  10. The mathematics of quantum computing — linear algebra.
  11. A universal quantum computer comprised of all features of a classical computer plus the full set of quantum features. The focus here is solely on the full set of quantum features, excluding the features needed to support a full-blown Turing machine.

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.

  • Definition of a qubit.
  • Definition of computational basis.
  • Probability of quantum states.
  • Bloch sphere for quantum states and actions of quantum logic gates. Or at least the three axes of rotation.
  • Superposition.
  • Entanglement. Bell states.
  • Interference.
  • Measurement.
  • Probabilistic nature of quantum computing.
  • Probabilities and amplitudes.
  • Quantum logic gate.
  • Quantum circuit.
  • Quantum program.
  • Quantum logic gates must be reversible.
  • Quantum errors.

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.

Plain English vocabulary

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

  • Computational basis, computational basis states
  • Basis states
  • Eigenvectors
  • Eigenvalues
  • Ground state
  • Excited states
  • Logic gates — they’re really operations or instructions
  • Unitary matrices
  • Coherence
  • Interference
  • amplitude
  • phase
  • wavefunction
  • Bell states
  • Transmon qubits
  • Superconducting
  • Cryogenic


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

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.

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.

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.

Universal quantum computers?

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

  1. A single, unified computing architecture which combines a full set of quantum logic operations as well as all of the features of a classical computer. Capable of executing all programs which are supported by a Turing machine, plus the quantum operations.
  2. The full set of quantum logic operations, but none (or very few) of the features of a classical computer. Not capable of executing programs supported by a Turing machine.

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.

Details to be specified for a quantum computer

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

  1. Vendor name.
  2. Product name.
  3. Model number or name.
  4. Mnemonic name for the model. Such as for selecting from a list of available machines.
  5. Number of qubits.
  6. Number of states per qubit. Allow for qutrits, qudits, and qumodes.
  7. Plain English names for the qubit states.
  8. Whether qubits are guaranteed to be initialized to |0>. Seems to generally be true, but documentation should be explicit.
  9. Connectivity of qubits. For entanglement. Both as general rules and specific combinations of qubits. Specify which qubits can be used as control qubits, and which qubits can be used as target qubit for each control qubit.
  10. Maximum permitted circuit depth. May be a range, with degrees of error. Any special notes related to how many gates can be executed in parallel — until further gates cause sequential processing, adding to depth. Also, detail any gates which expand into multiple gates, increasing circuit depth.
  11. Maximum coherence time. Longest quantum program guaranteed to succeed. May be a range, with degrees of error.
  12. State coherence time as circuit depth as well as elapsed time.
  13. Maximum and average error rate. Specific gates may have their own error rates — see below.
  14. Number of gates which may be executed in parallel. Is it any different from the total number of qubits?
  15. Total number of gates permitted in a single quantum program.
  16. List of quantum logic gates supported. And their details — see below.
  17. List of supported unitary matrix values for quantum logic gates. Make it easy to lookup by entry values to get reference to the symbolic gates.
  18. List of special gates for preparation of qubit state.
  19. List of special gates for measurement of qubit state.
  20. List of any common quantum logic gates which are not supported.
  21. List of any special gates which are supported by this particular machine
  22. List of any gates which are macro sequences of more primitive gates. For example, SWAP.
  23. List of any gaps of unitary matrix values which do not have a defined quantum logic gate.
  24. List of any configurations of unitary matrices which are not supported or are problematic.
  25. What degree of quantum error correction, if any, is automatically provided by the hardware.
  26. Number of bits of precision supported for entries of unitary matrices and gate parameters. Single-precision floating point? Double? Quad precision? Exactly how many binary bits and decimal digits of precision are guaranteed to be supported by the POP for the entire family of machines? Clearly document which models of machines in the POP family, if any, have higher precision. Distinguish the software API precision from the firmware and hardware support. The primary goal here is that a quantum programmer can develop quantum programs which run unchanged on all models of machine in the family which the POP covers.
  27. Precision of pi required for specification of angles for parameters of quantum logic gates. This may or may not be the same as the precision supported for specification of angles for parameters of quantum logic gates. Especially for pi, pi/2, pi/4, and pi/8.
  28. Average quantum logic gate execution time. Individual gates may have differing execution times. See below.
  29. Elapsed time required to start a new quantum program. Includes time needed for qubits to be forced to the |0> initial state.
  30. Whether quantum program can be resumed after measuring qubits.
  31. Whether quantum program can be rerun without manually reloading the program.
  32. Whether quantum program can be rerun a specified number of times. Without any explicit external intervention.
  33. Whether there is an explicit RESET gate. Exactly what it does and how long it takes to execute. Does it always reset to |0> or can it reset to a random or noise state?
  34. Can the quantum consist of more than a single quantum circuit, such as a sequence of circuits with measurements of qubit state after each circuit to condition what the next circuit will look like? What limits are there to how many circuits can be executed for a single quantum program? What is the maximal time delay that the application program can introduce between circuits of the quantum program?
  35. Special notes. Any special limitations. Any special modes.

Details to be specified for each quantum logic gate

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

  1. Mnemonic name. Alternate mnemonic names as well — indicate preferred mnemonic name. For example, H or X.
  2. Short phrase description. Optional. For example, Hadamard transform or bit flip. Alternate phrases as well. For example, Hadamard-Walsh transform.
  3. One-line description.
  4. Detailed description.
  5. Detail citation. Such as a journal article, book, or web page.
  6. List of parameters. Mnemonic names, one-line description, detailed description, any limitations on values of parameters, any quantization of values of parameters (e.g., minimum resolution or precision for angle of rotation.)
  7. Clearly state the units for all parameters, such as radians for angles.
  8. Detail parameterized unitary matrix. Some entries of matrix may be fixed, but some may be a function of parameters of the gate.
  9. Provide a table of input quantum state values and the resulting quantum state values after execution of the gate. Including all four Bell states as input values.
  10. State clearly if any quantum state values are undefined after execution of the gate.
  11. State clearly whether execution of the gate results in quantum entanglement.
  12. State clearly what happens to any preexisting entanglement of the qubit(s) referenced by a gate.
  13. State clearly what happens to other qubits if they were already entangled with other qubits before execution of the gate. And the resulting state of those other qubits they may have been entangled with. Is re-entangling of two entangled qubits a no-op or identity, or what exactly will happen? Clearly state any cases whose outcome may be undefined.
  14. Connectivity restrictions. Such as nearest neighbors only.
  15. Whether the gate is a composite gate which expands into multiple gates executed sequentially, impacting circuit depth.
  16. Range of execution time. Minimum. Maximum. Average. Distribution, if available. Detail what parameters or other factors impact execution time.
  17. Minimum, maximum, and average error rates. Note if different from average numbers across all gates.
  18. Stability of pure states, |0> or |1>, over execution of a quantum program. Virtually guaranteed, or as probabilistic and subject to error rates as mixed (superimposed) states.
  19. Examples. Especially for any special or distinctive cases.
  • Identity gate.
  • No-op gate.
  • Barrier gate to limit parallel execution of gates.
  • Reset.
  • Conditional execution.
  • Loop execution.

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:

  1. Resolution or precision of phase, phase angle, phase difference, phase shift (rotation.) How fine-grained? How many gradations? How many decimal digits (nines) or classical bits of precision for values, for gates and unitary matrices.
  2. Expectation for results of quantum Fourier transform (QFT) and phase estimation. Classical bits of precision of the result, maximum — a range.
  3. Resolution or precision for phase estimation. How many classical bits, maximum — a range.

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.

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.

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.

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.

  1. Support for registers and performing gate operations in parallel across all qubits in a register.
  2. Support for classical register backing a qubit register. To prepare or measure all qubits of the register in parallel.
  3. Support for classical control flow. Such as conditional execution and looping, contingent on measured results in the middle of a quantum program.
  4. Pulse-level control of qubits.
  5. Debugging features.
  6. Ability to reset a qubit to |0> in mid-circuit, during circuit execution.

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.

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.

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.

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.

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.


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.


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

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.

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.

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.

  • Volume 1: Describes the architecture and programming environment of processors supporting IA-32 and Intel® 64 architectures.
  • Volume 2: Includes the full instruction set reference, A-Z. Describes the format of the instruction and provides reference pages for instructions.
  • Volume 3: Includes the full system programming guide, parts 1, 2, 3, and 4. Describes the operating-system support environment of Intel® 64 and IA-32 architectures, including: memory management, protection, task management, interrupt and exception handling, multi-processor support, thermal and power management features, debugging, performance monitoring, system management mode, virtual machine extensions (VMX) instructions, Intel® Virtualization Technology (Intel® VT), and Intel® Software Guard Extensions (Intel® SGX).
  • Volume 4: Describes the model-specific registers of processors supporting IA-32 and Intel® 64 architectures.

Some current quantum computing documentation

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


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.

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:

  1. Technology. Type of hardware architecture. Such as transmon, trapped ion, photonic, etc.
  2. Hardware architecture. Unless it impacts what quantum programmers need to know.
  3. Photos and diagrams illustrating the qubit hardware.
  4. Chip fabrication process.
  5. Details for the use of microwaves to control qubits. Such as frequencies.
  6. Physical dimensions and configuration of the machine.
  7. Operating temperature.
  8. Operating environment requirements.
  9. External shielding requirements.
  10. Internal shielding.
  11. Power requirements.
  12. External cooling requirements.
  13. Cost.
  14. Specific details on performance.
  15. Configuration parameters.
  16. Calibration parameters.
  17. Access controls. Who can use it. Any limits on usage.
  18. Accounting. Records of usage.
  19. Classical computers and firmware needed to operate the quantum computer and make it available as a networked server.
  20. REST API or other specialized networked API to allow remote applications to utilize the quantum computer as a coprocessor.

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.

  1. Summary of the overall implementation technology. Plus links to papers with much finer detail.
  2. Summary block diagram of the core hardware. Anything needed to support the qubits and gate execution, but excluding electrical, cooling, and physical enclosure.
  3. Number of qubits. This may be exactly the same as in the POP, or the POP may be vague or variable, with a range if number of qubits varies by model within a family. This document would be very specific.
  4. Table and/or map of qubit connectivity for entanglement or gate execution. Detail any variations of performance data on entanglement and gate execution if not uniform for all combinations of qubits.
  5. Schematic and photograph of chip layout of qubits. Highlight major components and connectivity.
  6. Physical parameters for each qubit. Size, voltages, frequencies, timing for state changes, whatever.
  7. Physical parameters and limits for dynamic qubits such as trapped ions.
  8. Physical parameters of major components. Including voltages and frequencies.
  9. Implementation details for gates and unitary operators. Any restrictions?
  10. Detail the specific hardware operations on qubits required to implement each quantum logic gate or unitary matrix configuration. Detail which gates and unitary matrix configurations expand into multiple hardware operations. For example, the SWAP and H gates. Detail impacts on performance and coherence of such expansions.
  11. Gate performance. Average, minimum, maximum, distribution.
  12. Coherence times for superposition, entanglement, and interference.
  13. How many gates can execute in parallel.
  14. Maximum rate of gate execution, throughput.
  15. Maximum quantum program size.
  16. Time to initialize qubits to |0>.
  17. Whether |0> is the only state to which qubits can be initialized.
  18. Time to fully initialize for a new quantum circuit.
  19. Run rate per second for repetitions of the same quantum circuit.
  20. Implementation details for measurement of qubit state. Technology and parameters. Including performance.
  21. Number of binary bits and decimal digits of precision actually supported for entries of unitary matrices and gate parameters. Single-precision floating point? Double? Quad precision? In any case, clearly document the precision actually supported by both the firmware and hardware for the machine. This may differ from the precision guaranteed by the POP for a family of machines.

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.

What’s next

This framework is a work in progress.



Freelance Consultant

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store