PRE-REGISTERED, 2026-11-05, before the vQPU-EDGE bitstream had been loaded on the board, and before
any power was read from it. Written from the RTL, the software model's activity counts
(`vqpu-edge activity`) and the board's own earlier measurements. Not edited after the data.

WHAT IS MEASURED
Run minus halt on ONE bitstream (kv260/edge, 100 MHz pl_clk0), whole-board INA260, by the board's
written rules: no reload between states, randomised order each pass, sampling on the board in the
measuring process with nothing else running, reload detection per point (engine uptime counter must
keep counting; dmesg FPGA-write count must not move; ID must read back), pass dropped if flagged,
statistic = mean of per-pass differences of medians, error = SE across passes. Label of every
number: board-level, this KV260, this design. It is NOT the 0.1596 pJ/accumulate of the old
constant-folded vehicle and must not be quoted as that: this lowering keeps W in flops and adds a
product LUT, a compressor and a runtime-theta comparator to every cone, so it has its own rate.

THE INSTRUMENT CHECKS, which gate everything else
  K1 known answer: the September vehicle ev_rdet.bit.bin, run/halt by its own script kv_runhalt.sh,
     must reproduce 61.7 mW (its 2026-09-28 run/halt value, +/- 6.5). PASS if within 2 combined sigma.
     If it fails, no number below is reported as measured.
  K2 null: on the vQPU-EDGE bitstream, halt against halt (one slot labelled run): 0 mW.
     PASS if |delta| < 2 SE.

PREDICTIONS (point value, and the range outside which I am wrong)
Reasoning: the old det vehicle drew 61.7 mW at 8.68 state flips per clock, i.e. ~71 pJ per flip with
its constant-folded cones. This lowering has ~3x the LUTs per cone (product + compressor + tree +
comparators), and a flip drives all 64 cones, so I take 2.5x per flip, uncertain by 2x either way.

  class         what repeats                                     flips/clock  predicted P_dyn   range
  t0-recall     dense Hebbian n=64 (8 patterns), T=0 settle         6.88        122 mW         60..250
                from a 30%-corrupted cue, 5 steps, reload
  gibbs-recall  same landscape, 8 sequential Gibbs sweeps at         0.028         5 mW          0..20
                beta=4 + one T=0 step, reload (1539 clocks/job)
                - cones barely move; what is left is PRNG, table
                  read, field mux and counters
  solve-assign  the 3x3 equality landscape (n=9), 39-sweep anneal   ~0.1          3 mW          0..15
                from T=1, final T=0 step; 55 of the 64 cones have
                W=0 and cannot switch
  t0-idle       W=0, bound 0: the job FSM looping with a static       0            1 mW          0..10
                datapath (control and counters only)

Derived, for t0-recall: 12.5 M settles/s at 8 clocks each => ~10 nJ per settle; with its accumulate
count (5 steps x nnz) that is about 0.5 pJ per accumulate, range 0.25..1.0. I expect it to be WORSE
than the old 0.16 pJ/accumulate, because the couplings are now data, not wiring.

WHAT WOULD REFUTE THE REASONING
  - t0-recall outside 60..250 mW: the per-flip cost of this lowering is not 1-5x the old one.
  - gibbs-recall above 20 mW: something other than state flips (the field mux, the table, the PRNG)
    costs far more than the toggle study's numbers say.
  - t0-idle above 10 mW: control is not negligible, and every per-job figure carries it.

WHAT THIS RUN CANNOT RESOLVE (said now, so a null is not read as a finding)
  gibbs-recall, solve-assign and t0-idle are predicted at or below the protocol's floor (paired SE
  ~2-7 mW at 8-12 passes). A result consistent with 0 there means "below what one core on this
  meter resolves", not "free". A second meter on the PL rail (or K replicated cores) is what would
  resolve them.