By Lunibyte team · November 1, 2026 · 6 min read

Try QAOA: A Beginner’s Guide to Our Quantum Lab

You can examine a quantum optimization experiment without opening an account or using a paid service. Our Resilience Lab runs a small QAOA circuit on a local classical statevector simulator, then compares its measured candidates with an exact classical solver.

The goal of this guide is to help you explain one result correctly. You will identify the decisions, run the experiment, inspect feasibility and save the evidence. You do not need to know circuit notation beforehand, but you should resist treating a green constraint check as proof of quantum advantage or a production-ready network design.

Know what the experiment represents

Open the Resilience Lab. The network is a chain of six nodes, A through F, joined by five existing links. Six candidate bypass links are available: AC, BD, CE, DF, AD and CF. The budget allows exactly two.

The experiment considers five separate scenarios, each removing a different existing chain edge. It rewards selections that restore disconnected node pairs across those scenarios. It does not simulate five simultaneous failures, traffic queues, attacks, hardware faults or measured network performance.

Six decision qubits represent the six optional links. There are 64 possible six-bit strings, with only 15 satisfying the budget. This is small enough for exact enumeration, which is why the classical baseline can tell us the optimum for the specified model.

Step 1: predict the budget check

Before running anything, imagine the bitstring 100001 in the displayed x0-through-x5 order. It selects AC and CF, so it satisfies the two-link budget. The string 100000 selects only AC and is invalid, regardless of whether that link would help in one outage.

That distinction separates feasibility from quality. First ask whether an answer obeys the rules. Only then compare its restored-pair score with another feasible answer.

The maximum aggregate score is 35. It is a sum over the five separate outage scenarios, not a percentage, probability or count of simultaneously protected users. A score needs its definition as much as it needs its number.

Step 2: start with the default settings

Leave the depth at p = 1, measurement shots at 2048 and sampling seed at 42. Press Run QAOA. Results appear after an actual run; there is no prerecorded answer substituted into the quantum panel.

Depth describes the number of alternating cost-and-mixer layers. A shot is one final measurement sample from the prepared distribution. The seed controls the pseudorandom sampling sequence in this simulator, making a fixed configuration reproducible within the implementation.

The seed does not make quantum hardware deterministic. Nor does increasing shots rerun the angle optimizer for each measurement. These are separate parts of the experiment, and the lab exposes them separately so you can compare like with like.

Step 3: read the two answer panels separately

The QAOA panel shows the best feasible candidate that was actually observed. The classical panel shows the result of exhaustively checking the toy instance. They answer different questions: what did the sampled distribution produce, and what is the exact reference optimum?

For the default p1 configuration, recorded runs found score 35, matching the classical optimum. Your local runtime will vary. The important procedure is to check the displayed score and feasibility rather than assuming a particular number means success.

If no feasible quantum sample is observed, the lab must show none. It does not borrow the exact solver's answer and call it a quantum result. Keeping that boundary visible is essential to an honest comparison.

Step 4: inspect the invalid outcomes

Expand or read the measured-outcomes table. Some strings violate the budget and remain visible. Their presence is expected because the cost function uses a penalty, rather than a circuit that restricts every sample to valid two-link choices.

The energy is negative coverage plus 36 times the squared difference between the number of selected links and two. For feasible selections, the penalty vanishes. For invalid strings, the quadratic coverage extension is not a physical restored-connectivity score, so the interface does not present it as one.

At the default p1 setting, the exact feasible probability is approximately 0.461043, with 958 feasible shots in a recorded 2048-shot run. Those figures are different kinds of information: one comes from the simulated distribution, while the other counts its seeded samples. Finite sampling need not match the probability exactly.

Step 5: compare p1 with p2 carefully

Change the depth to p = 2 and run again with the same seed and shots. The extra layer adds circuit parameters and work. It does not promise a better result with this bounded optimizer.

In recorded Resilience runs, p2 had feasible probability approximately 0.466307 and 962 feasible shots, with best score 35. That is a small change in this configuration, not a general theorem about increased depth or a benchmark against hardware.

Keep the objective, feasibility and runtime together. Finding the same best score does not mean the distributions are the same. A higher feasible fraction does not establish a speed advantage. The small exact baseline is usually a simpler way to solve this particular toy problem.

What happened between pressing Run and reading the result?

The simulator initializes a six-qubit superposition, applies the problem-dependent phase operations and mixer rotations, and evaluates the expected penalized cost. A classical optimizer adjusts angles using a fixed grid and bounded coordinate search.

After selecting angles, the simulator samples the final Born distribution, checks original constraints and compares observed feasible results with the baseline. The lab records 176 circuit evaluations for p1 and 208 for p2. It also exports angles and all 64 probabilities.

The original QAOA paper explains the method's foundation. IBM's circuit-model introduction provides background on the operations. Our bounded search, toy objective and simulator should be evaluated on their own documented behaviour.

Save enough information to repeat the experiment

Choose Download run evidence (.json) after a completed run. The export contains the toy definition, backend identifier, depth, seed, shots, angles, probabilities, samples, selected result, baseline and timings.

For a comparison, keep the original export and a second file with only one setting changed. Write down what you changed and what you expected. If you change both depth and shots at once, it becomes harder to explain which difference affected your observation.

The lab's calculations happen locally, with no commercial quantum or AI API involved. Loading the page and its assets still contacts website hosting. The word AI in LuniQ-Resilience AI is the product name; current explanatory text is fixed, without model inference.

Finish with one short explanation

Try writing this sentence with your own observed values: “For six backup-link decisions and an exactly-two budget, the simulator produced this feasible fraction, found this best score and matched or missed this classical optimum.” Add the depth, shots and seed so the statement can be checked.

You can cancel a running job. A worker failure or timeout should produce an explicit status rather than a replacement result. Device speed affects execution time, and a problem in your browser is useful feedback rather than evidence about quantum theory.

Once you can read that experiment confidently, try SatMesh. Its variables choose routes at two synthetic snapshots, its objective is minimized planning cost, and its disconnected scenario correctly produces no feasible schedule. The same habit applies: understand the model before celebrating the number.