Field note 02 · Golden benchmark

Building the Golden Q9 Benchmark on Fujitsu FX700

A step-by-step account of how we are turning an energy optimisation idea into a reproducible, validated QAOA experiment for QARP — one evidence gate at a time.

Fujitsu FX700 / A64FXQARP + QulacsStatus: pre-QAOA validationUpdated August 2026

Current evidence chain

Operational model
Classical reference
QUBO
Ising model
QARP operator
QAOA execution next

1. Reusing the platform, not rebuilding it

Our first design decision was operational rather than quantum. The Fujitsu environment already had the QARP and Qulacs software stack available, so we separated that reusable environment from the experiments themselves. The result is a single project structure for ICEVictoria, with shared source modules and configuration-driven runs for Q9, Q19 and Q39. This avoids copying environments or algorithm code for every qubit count.

That separation matters for reproducibility: a change to an optimiser, encoder or backend can be isolated, recorded and compared without quietly changing the rest of the stack.

2. Defining a benchmark we can explain

Before scaling, we needed a small case that we could solve and inspect completely. We designated Q9 as our Golden QAOA Benchmark: nine binary decisions arranged as three operational clusters, each choosing one of three actions — normal operation, shifting demand or using battery support.

The model is synthetic and deterministic. It is not presented as a production energy system. Its purpose is to give us a stable reference for testing a new optimiser, mixer, encoding or backend before larger experiments obscure the source of an error.

3. Establishing classical ground truth first

With three allowed actions across three clusters, the feasible space is small enough to enumerate exactly. We evaluated all 27 feasible assignments and established an independent classical optimum. This gives every later quantum or hybrid run a clear question to answer: did it return a feasible decision, and how does its operational objective compare with the known reference?

We deliberately distinguish operational cost from penalty energy. A low QUBO energy is not useful if the corresponding decision violates the original one-action-per-cluster rule.

4. Encoding constraints without losing meaning

The next stage translated the operational model into a QUBO. Exactly-one constraints were introduced through penalty terms, then the complete nine-bit space was used as a validation surface. The checks are designed to confirm that valid assignments preserve the original objective and that invalid assignments cannot undercut the best valid decision simply because a penalty was chosen poorly.

This is an important lesson from the journey: selecting a penalty is part of the model, not a cosmetic tuning choice.

5. From QUBO to an Ising Hamiltonian

We then converted the QUBO into a diagonal Ising representation while keeping a fixed variable-to-qubit order. At each conversion boundary, the goal is energy equivalence rather than visual similarity. A sign error, offset error or reversed bit convention can still produce a circuit that runs — but it would be solving a different problem.

Our validation strategy therefore follows the same chain as the implementation: operational objective, QUBO, Ising energy and finally the operator supplied to QARP.

6. Adapting the model to QARP

Inspection of the installed QARP interface confirmed that its QAOA implementation can receive an OpenFermion QubitOperator. We built that adapter explicitly rather than forcing the energy model into a graph abstraction that could hide linear terms.

The current operator represents nine qubits with 28 diagonal terms: one identity term, nine single-Z terms and 18 ZZ interactions. The variable-to-qubit mapping is fixed and documented. This structural milestone has passed on the FX700 environment.

7. Where the work is now

We have not yet declared the QAOA run complete. The next gate is an exhaustive comparison of QUBO, Ising and QubitOperator energies across all 512 computational-basis states. Only when that equivalence is confirmed will we build and run the QARP QAOA object.

After that, we plan to examine feasibility, solution quality, optimiser behaviour and reproducibility before moving towards Q19, Q39 or MPI scaling. Runtime alone will not be treated as evidence of optimisation quality, and a larger qubit count will not be treated as a result by itself.

Working principle
We do not advance because a script runs. We advance when the previous representation has been independently checked.
Next evidence gates
01 · EQUIVALENCE

Check every basis state

Compare QUBO, Ising and QARP operator energies over the complete Q9 state space.

02 · EXECUTION

Build QAOA in QARP

Run the fixed contract and record feasibility, distribution, optimiser evaluations and runtime.

03 · SCALING

Earn the move beyond Q9

Use the validated benchmark to test larger models and MPI without changing the scientific question.