Reading a QAOA Run: Sample Table and Energy
After the Resilience Lab finishes a run, the page shows a summary, a classical baseline, and a table of observed samples. This article explains how to read those elements so the numbers are useful rather than decorative.
The summary line
The summary reports the best feasible sample the simulator observed (its bitstring, coverage score, and energy) and the fraction of shots that satisfied the exactly-two-links constraint. If no feasible sample appeared in the requested shots, the best-feasible field stays empty while the classical baseline is still shown. That outcome is possible; the lab does not invent a feasible result to fill the gap.
The sample table
Each row is a distinct bitstring that was measured at least once. Columns show the bitstring (x0 through x5), the number of shots, whether the constraint is satisfied, the coverage score, and the Ising energy. Infeasible rows remain visible. Their coverage may be defined, but the penalty term makes their energy higher than a feasible selection with the same coverage. Sorting or scanning the energy column shows which observed outcomes the circuit considered lower-cost.
Energy versus coverage
Coverage is the planning score the original problem cares about (higher is better, maximum 35). Energy is the quantity the QAOA circuit and the classical optimizer actually minimize. Because of the penalty, the lowest-energy feasible sample is the one the algorithm is trying to find. A low-energy infeasible sample can still appear; its energy is low only relative to other infeasible strings, not relative to the true feasible optimum. Comparing a row’s energy with the classical baseline’s energy tells you whether that sample matched the known best objective value.
The classical baseline and the download
The classical optimum is computed by checking all 15 feasible selections. It is displayed separately and is never written into the sample table as if it had been measured. The JSON download contains the seed, depth, shot count, both results, and the full sample list. Keeping that file lets you re-run the same settings later and confirm that the table and energies match.
Reading the table this way turns a finished run into a checkable record: which bitstrings appeared, which were feasible, how their energies ranked, and how the best observed score compared with the exhaustive answer.