By Hanwen Xing, Matteo Johnson, and Anthony Gelasi — investigating how quantum computing can help solve combinatorial optimization problems through QAOA, completing two implementation-focused project tracks, and documenting our experiments, reports, and final demonstration materials on this website.
Early in the project, we built a foundation in quantum computing through IBM Quantum coursework, Qiskit practice, handwritten notes, and guided circuit exercises. This stage covered core ideas such as qubits, superposition, entanglement, measurement, and standard gates including Hadamard, Pauli-X, and CNOT.
This work gave us the background needed to move from basic circuits to QAOA. It also helped us become comfortable building, simulating, and interpreting quantum circuits in Python before starting the larger optimization experiments.
The first task focused on the mathematical foundations of single-qubit quantum gates. We were asked to prove several important identities involving the Hadamard gate and the Pauli matrices, including HXH = Z, HZH = X, HYH = −Y, H† = H, X² = Y² = Z² = I, H = (X + Z)/√2, and H² = I. We also needed to compute tensor products such as σ₁ᶻ ⊗ σ₂ᶻ and σ₁ᶻ ⊗ I ⊗ σ₃ᶻ to understand how operators act in multi-qubit systems.
We solved this task by writing each gate in explicit matrix form and performing direct matrix multiplication. This approach made each identity concrete rather than symbolic. For example, multiplying the Hadamard matrix by X and then by H shows exactly why the basis changes convert X into Z. The same method explains why HZH = X and why conjugating Y by H introduces a negative sign.
For the tensor product calculations, we used the Kronecker product structure to expand 2×2 matrices into 4×4 and 8×8 matrices. This helped us see how a gate acting on one qubit is embedded into a larger system. Conceptually, this task established the algebra needed later for QAOA, where cost Hamiltonians are built from products of Z operators and where gate identities are used to simplify circuit construction.
This task gave us the mathematical language needed for the rest of the project. QAOA is built from repeated applications of structured quantum operators, so understanding how gates combine, transform, and scale to larger systems is essential before implementing the algorithm in code.
The second task moved from pure gate algebra to actual circuit construction. We were asked to reproduce a small quantum circuit using IBM’s interface, place the correct gates on the correct qubits, and execute it on one of IBM’s quantum backends. The circuit included initialization, gate placement, entangling structure, and final measurement, so the main challenge was understanding both the logical sequence of operations and the physical interpretation of the measured outputs.
We broke the circuit into stages. First, we identified the role of each gate in the diagram and matched the gate placement to the correct qubit lines. Then we constructed the circuit step by step, making sure the control-target relationship of the entangling gate was correct. After that, we added measurement operations and ran the circuit through IBM Quantum tools.
The main idea in solving this task was to treat the circuit as a sequence of state transformations. Rather than simply copying the visual diagram, we asked what each gate was doing to the qubit state at that point. The X gate flips a basis state, the H gates create superposition, the controlled operation introduces correlation between qubits, and the measurement maps the quantum state into classical bits that can be interpreted through counts and outcome frequencies.
This task was our first complete connection between abstract quantum gates and an executable experiment. It showed how a circuit diagram becomes a runnable object in IBM Quantum and prepared us for later work, where QAOA must also be built as a structured circuit rather than only described mathematically.
The third task introduced the key operators used in QAOA. We were asked to revisit the definition of the cost unitary U(C,γ) and analyze how it is constructed for Max-Cut from terms of the form C⟨ij⟩ = 1/2 (I − σᶻᵢ ⊗ σᶻⱼ). We then needed to calculate operator expressions such as e−iγ(I − σ₁ᶻ ⊗ σ₂ᶻ) for a two-qubit system and e−iγ(I − σ₁ᶻ ⊗ I ⊗ σ₃ᶻ) for a three-qubit system.
We solved this task by recognizing that these operators are diagonal in the computational basis because they are built from Z-type terms. That means the exponential can be understood through the eigenvalues of the underlying matrix. Once the basis states are identified, each state picks up a phase depending on whether the relevant qubits agree or disagree. This is exactly why the cost operator is useful for Max-Cut: it rewards bitstrings that correspond to edges crossing the cut.
We also connected this mathematics to circuit implementation. In practice, the cost unitary is not left as a symbolic exponential. Instead, it is decomposed into gates that IBM hardware can run, usually through combinations of CNOT gates and Z-rotations. The mixer operator U(B,β) is easier to implement because it is built from X rotations on each qubit. This task therefore served as the bridge between operator notation and real quantum circuits.
This task is the theoretical core of QAOA. It explains where the algorithm’s two alternating layers come from and why they are meaningful. Without this step, implementing QAOA would be mostly code without a clear understanding of the optimization logic behind it.
The current task asks us to move from foundational theory to a working algorithm. We need to elaborate the Qiskit code structure for QAOA, explain how U(C,γ) and U(B,β) are built for Max-Cut, discuss how they can be decomposed into universal gates on IBM’s quantum computers, and then implement the algorithm for a small graph and submit the results.
At this stage, we are reviewing literature related to QAOA performance, graph-based optimization, and existing implementation strategies. We have also started identifying benchmark data and small graph instances that are appropriate for testing. This allows us to compare our implementation against known examples and gives us a practical basis for evaluating output quality.
Our next step is to implement the algorithm over the next week and a half. This includes building the circuit layers in Qiskit, selecting initial parameter values, running experiments on simulators, and then comparing measured bitstrings according to their Max-Cut values. As the implementation becomes stable, we will add the results and interpretation back into this website.
Our first major implementation track focused on QAOA for the Max-Cut problem. We used this as a direct and well-known combinatorial optimization benchmark so that we could compare quantum and classical approaches across increasing graph sizes.
We generated graphs across multiple sizes, built QAOA circuits in Qiskit, transpiled them, and ran them on the Aer simulator with repeated shots. The classical comparison used brute force to enumerate all possible partitions, while the QAOA side used measured bitstrings to identify high-quality cuts.
This part of the project let us study QAOA in a controlled benchmark setting. Instead of treating the algorithm only as theory, we evaluated how it behaves in practice and how its solution quality and runtime compare to classical baselines.
Our second implementation direction connected quantum optimization to a scheduling-style application: resource-constrained project scheduling. In this setting, jobs must respect precedence rules and limited shared resources, which makes the problem hard to solve exactly at scale.
We modeled the workflow as a conflict-resolution loop. First, we built an earliest-start schedule. Then we detected overlapping jobs that exceeded resource limits and used those conflicts to form a graph. Max-Cut became the optimization subproblem, and QAOA was used as the bottleneck-solving component that helped split conflicting jobs into groups.
This track moved the project beyond a pure benchmark and toward a real optimization context. It helped us show how QAOA-style methods can be embedded inside a larger workflow rather than being presented only as an isolated textbook example.
In the final stage, we organized the project into a clearer public-facing form: written reports, visuals, the project website, and presentation material for final review. The goal is not only to show code, but to explain the motivation, method, experiment design, and lessons learned in a way that is easy to present. This website serves as a final showcase of the capstone project. It summarizes the background learning, documents our two main project directions, presents progress artifacts, and supports final Q&A and Design Expo discussion.
The main technical implementation work has already been completed at the level we want to present. Our current priority is communication quality: making sure the website, slides, and reports all tell the same story and clearly connect the theory, the two implementation directions, and the final conclusions.
That means focusing on clean explanations, readable visuals, and strong presentation flow rather than adding a brand-new experimental branch at the last minute.
1) Finalize the wording of the website.
2) Polish the two project-report writeups and supporting visuals.
3) Make sure the slides match the website and the spoken presentation.
4) Prepare short explanations for common Q&A topics.
5) Rehearse for the Design Expo and final review.
You can know what QAOA is, why Max-Cut was used as a benchmark, how our scheduling-related application connects to combinatorial optimization, and what we learned by comparing quantum and classical approaches in practice. You can also ask the AI assistant for questions related to our project.