Reading a Compilation Report

Why care? A compiler's output is only as trustworthy as the record that comes with it. If you can read that record, you can catch mistakes before they cost you a run.

A compilation report is the record a compiler writes next to the output circuit. Its job is to make the work repeatable. Another engineer with the report should be able to run the compile again and get the exact same output, bit for bit. They should also be able to check every claim in it.

An everyday example: a lab notebook in science class. You write down what you used, how much, and in what order, so a classmate can do the same experiment. Here the example breaks. A classmate's result will be a bit different each time. A compiler given the same inputs and seed should give exactly the same circuit every time.

The key fields are:

• Input hash: a fingerprint, or checksum, of the exact logical circuit that was compiled. If the input changes by even one gate, the hash changes.
• Compiler version and target version: which software was used, and which snapshot of the chip's wiring, native gates and calibration (measured error rates). Both change over time.
• Seed: the starting value for any step that uses random choices. It makes those choices repeatable.
• Initial and final mapping: which physical wire held each logical qubit at the start, and where each one ended up after routing.
• Metrics: gate counts by type, depth (the number of time steps), two-qubit depth, and how many SWAPs were added, before and after.
• Assumptions: the scoring formula, called the objective function, and any calibration values the choices relied on, with time stamps.

Numbers without these source details are just numbers. You can't tell whether "depth 6" is good, bad, or even real.