The answer: four points, each conceded or refuted

12 October 2026 (the answer the coordinator ordered by 20:30 UK). Written against main at b729cf87f (the two reviews) and the record's files as they stand there. The relation's owner owns the relation, the reference and the cohort record; the band under review was produced by a team seat on the record's model files, and the relation's owner reads it as the record's, not as another seat's. Nothing in this document is served; the coordinator decides what the served sentences say.

Grades: MEASURED (read back from a card, a box or a machine, the source named), DERIVED (arithmetic on measured numbers), ESTIMATED (an engineering estimate with its band), ASSUMED (a stated choice). The review's grades are kept where its numbers are used.

0. The answer in five lines

1. Point 1 (the count): CONCEDED. The record's engine is charged the card's 609,952 thread-instructions per nonce (MEASURED on the card, the captured mix of the 500 W pod cell) at the engine's per-instruction terms; the relation as frozen forces about 81,000 to 190,000 primitive 32-bit operations per hash (DERIVED, section 2, the review's count and the relation's owner's stricter one), none of them an instruction. The band's count is wrong by 3x to 7.5x.
2. Point 2 (the calibration): CONCEDED in substance. The c construction is per-instruction terms (a datapath, a register file, issue and decode, clock and leakage) over a programmable lane, floored at the RandomX precedent; the frozen relation (form (b), revision 2c, bit 5) has fixed slots, fixed opcode class counts, 3-bit lane selects and a 2-bit phase, so a wired round pipeline computes it with no register file and no issue, and the record's own RandomX file says the class that forces a programmable lane needs what the relation does not have.
3. Point 3 (the count alone takes the stacked edge to about 14x): CONCEDED as a band. On the record's own per-operation energies and memory rows the count correction alone gives 9x to 15x central on the stacked class and 6x to 9x on an external board (DERIVED, section 4); the review's placed estimate reads higher (22x and 12x, ESTIMATED). Both are above the 4x central and 5x upper coexistence limits.
4. Point 4 (the programme lever moves the edge the wrong way): CONCEDED on the record's figures. The card pays 4.3x over its walk (12.206 against 2.844 uJ, MEASURED); a wired pipeline pays 0.1 to 1.0 uJ for the same programme (ESTIMATED and DERIVED); the ratio rises from about 8.7x on the walk to 12x or more on the blended relation. The lever's premise (that the programme forces a programmable lane) does not hold for the frozen form.
5. The corrected band is in section 5; what decides it is the placed round pipeline (section 6), whose inputs the relation's owner supplies now (section 7). The served sentence that the specialist's central edge is under 3x and its upper under 5x does not stand on the record's own figures once the count is corrected; the coordinator's qualifier at 20:30 is the least that is right, and the relation's owner's reading is that the sentence should carry the corrected band, not a qualifier.

1. What the record's band is, in its own files (MEASURED and DERIVED, read for this answer)

From the simt-reconstruct-igneumhash-bundle-v8-b2-x16-f4128__rtx5090-32g-capped500w-loomc__screen file: the cell's instructions per nonce 609,952 (mix_source captured: integer ALU 48.2 percent, 32-bit multiply 13.6, shuffle 18.6, control 11.2, FP32 multiply 3.4, FP32 add 3.4, shared and global loads 0.5, other 1.2); the GPU's energy per programme instruction 15.35 pJ ("the cell's energy less the walk-only twin over the instruction count"); m, the memory share, 0.202; c upper 4.99, central 2.16, weak 0.90; the combined edge stacked 2.53 central, 5.54 upper, 1.09 lower; external 2.37, 5.13, 1.03; the governing upper 3.15 (c 2.69); the term that decides the upper: the register file. From out/version8-c-terms.json: "c = (the GPU's energy per programme instruction at 70 percent of its native rate) / (the placed engine's energy per instruction)"; the engine's terms per instruction, datapath 1.5 to 4.0 pJ, register file 0.8 to 2.5, issue and decode 0.3 to 1.5, clock and leakage 0.5 to 2.0, total 3.1 to 10.0, over a utilisation 0.75 to 1.0 and a package factor 1.1 to 1.25; "the band 1.3 to 4.0 is the upper two thirds of this, the weak edge floored at the RandomX precedent". From controls/upper_published_file.py: engine(mix, features, file_pj, xb_i, ...) returns an energy per instruction from the GPU's mix, and the engine's energy per hash is the GPU's instruction count times it.

So the review reads the construction right: the specialist's programme energy in the record is the card's instruction count times a placed per-instruction energy. That is the modelling choice under review, and it is the record's.

2. What the frozen relation forces per hash (DERIVED from SPEC-R0A-v0.md 0.4, 0.8 revision 2c, 4.4, 4.5, 4.7)

The launch document is v8-d2048-s0-r64-k32-p256-w128-b2-x16-f5152-k2 and its unkeyed twin at features 4128, under which every cohort row of record is measured and under which the shares hash (RELATION-STATE.md: the network's hashing carries no keyed overhead; the sealer's two keyed compressions are 0.2 nJ per attempt and do not move the edge; the review's 2.4 is right).

Against the card's 609,952 thread-instructions per nonce (MEASURED) the relation forces 81,000 to 179,000 primitive operations: the card issues 3.4 to 7.5 instructions per forced operation. The difference is what the review names: a data-chosen lane is a shuffle on the card and an 8:1 multiplexer on a wire; a bit field is an extract on the card and a wire on an engine; the phase is control on the card and a steering bit on an engine; the tree is computed in every lane on the card and once on an engine; the loop and its control (11.2 percent of the card's instructions) do not exist on a pipeline. The relation's owner verified the field positions against the text: shift1 = p & 7, shift = (p >> 4) & 7, phase_b = (p_(b,0) >> 13) & 3, aligned bit fields of the programme word, which at B K = n = 32 is the item word itself with no lap constant; the sources are d + 1 and d + 2 within the lane's slice and the destination is the slot. Nothing in that is an instruction. CONCEDED.

What the text does force, and the review grants: every item word reaches the state and the address (S1, S2); the item's bytes are keyed XOF output with no redundancy (S4, measured 7.9999 bits per byte); the next index depends on the whole round (S7); the programme's output depends on (item, state) and is not cacheable per item; the opcode class counts per block are fixed (2b). These bind what is computed per hash and prevent precomputation; they do not bind a programmable lane. The review's section 7.2 table of failed shortcuts agrees with the record's S1 to S9 and the relation's owner has nothing to add to it.

3. The calibration (point 2)

The c band's shape is the per-instruction engine of section 1; its weak edge (c 0.9, "the engine worse than the GPU, which is the X5's parity regime") is floored at the RandomX precedent (REDTEAM-RANDOMX.md: the specialist for a RandomX-class program is itself a CPU). RandomX forces a programmable lane by its program space: about 30 instructions over 20 registers, a 2 MiB scratchpad with data-dependent addresses, branches, double precision with program-set rounding modes, superscalar dependency shapes. The record's own RandomX file (RANDOMX-CLASS.md, REDTEAM-RANDOMX.md) reads RXE1 as lacking "the scratchpad, branches, FP and the superscalar shapes", and version 8 revision 2c under bit 5 has fewer of them than RXE1: fixed destination and source slots, fixed opcode class counts per block, no scratchpad, no branch, no rotate, no data-indexed register, two roundings per descriptor at a fixed mode. Its per-descriptor "programme" is 8 x 8 x 4 = 256 possibilities, all select lines. The late binding per nonce and per round prevents compiling a programme; it does not prevent wiring the datapath, because the datapath is the same for every programme.

So the calibration is conceded in substance: the per-instruction construction and its RandomX floor model a SIMT-lane die with a register file and an issue stage, which the text names in 0.8 as the specialist's cost ("the specialist's is a crossbar per read", "the register-file term an in-house adversarial review found sets its edge"), and that sentence of the text is a modelling choice the relation's owner made with a team seat, not a property the relation forces. The record's own reading that the 40 nm Ethash incumbent die cannot run the programme (SUPPLY-CORNERS.md 11, superseded by 12) is right and is not what is at stake: the question is what replaces that die, and a fixed round pipeline is the cheaper answer.

What is NOT conceded: that the calibration changes the memory side. The stacked A band (5.98 to 9.74 on the walk) and the external board's (2.36 to 5.77) rest on shipped machines and the review uses them unchanged; so does this answer.

4. The count correction alone, on the record's own energies (point 3; DERIVED)

The record's engine energy per instruction, central 5.8 pJ and the band 3.1 to 10.0 before utilisation and package (version8-c-terms.json); the coordinator's framing of the review's figure, 5.5 to 7 pJ, sits inside it. Applied to the forced operation count instead of the card's instruction count:

With the memory term unchanged (the stacked class 326 nJ measured, the record's own stacked model band 292 to 476; the external board 480 to 1,250 measured class, central 800) the specialist's energy per hash and the edge against the row of record (12.206 uJ, MEASURED) read:

So the count correction alone, with no energy figure of the review's and no register-file or issue term removed, gives a central stacked edge of 9x to 15x and a board edge of 6x to 10x against the row of record, and 5x to 9x and 3.5x to 6x against the 4090 knee (7.05 uJ at the wall, MEASURED). Every central figure is above the 4x limit and every stacked upper above 5x. The review's 14x is inside the relation's owner's band and is the figure at its own count. CONCEDED.

The review's placed estimate (section 4.2 of its text) removes the register-file and issue terms as well and prices the lane-descriptor at 2 to 8 pJ placed and the station at 0.2 to 2.5 nJ per round, giving 0.41 to 1.02 uJ all in on the stacked class and 22x central: ESTIMATED, not verified by the relation's owner, and not needed to reach the verdict; it is what the placed pipeline (section 6) measures.

5. The programme lever (point 4) and the corrected band

The lever's premise, as the record wrote it (RANDOMX-CLASS.md, SPEC 0.8): a per-nonce, per-round programme drawn from the item forces the specialist into a programmable lane, whose per-instruction cost (register file, issue) closes the gap to the card. On the frozen form the premise fails for the reason of section 2: the programme is select lines. What the lever then does on the record's figures: the card's energy rises 4.3x over its walk (2.844 to 12.206 uJ, MEASURED, the pod cell), while a wired pipeline's rises by the programme term of section 4 (0.45 to 1.25 uJ at the record's per-operation energies; 0.09 to 0.68 uJ on the review's placed estimate) over a memory term of 0.33 uJ stacked or 0.8 uJ on a board. The edge therefore rises with the lever: 8.7x on the walk alone against a stacked specialist (2.844 over 0.326) to 9x to 22x on the blended relation; 3.6x on the walk against a board (2.844 over 0.8) to 6x to 12x. CONCEDED. The lever as the frozen form realises it is a cost on the card that the specialist does not share in proportion.

The corrected band, stated with its grades, replacing the record's 2.53x central, 3.25x governing upper, 5.54x stacked extreme:

What stands from the record: the memory-class containment (a stacked specialist at 6 to 9x on the walk, boards at 3 to 6x), the exactness and admission rows, the finding that the specialist's die is small and cheap, the overlap efficiency (1.15) and the per-nonce timing spread. What does not stand: the sentence that the central edge is under 3x and the upper under 5x, and the coexistence verdict built on it (the registered 4x central and 5x upper limits are not met by any row of the corrected band against the row of record).

Two things this answer does not claim, to keep the grades honest: (a) the review's engine energies are ESTIMATED and a placed design may read the station term heavier (the review's own rank-3 assumption); that moves the upper and the review's central, not the floor, which rests on the record's per-operation energies and the relation's owner's stricter count; (b) the card's side can move too: the card issues 3.4 to 7.5 instructions per forced operation and is issue-bound at 57 percent of its slots (the pod cell's counters), so a leaner kernel could lower the row of record and with it every ratio; that is the project's own lever on the GPU side, measured on the card when it exists, and it does not change the specialist's energy.

6. What decides the band: the placed round pipeline

The review's section 9 names it and the relation's owner agrees it is the instrument: RTL of one round pipeline (the absorb, the two block stages with the snapshot as the pipeline register, the tree, the cell, the exchange, the next address) and a station of 256 contexts, synthesised and placed on an open PDK (a 7 nm predictive or a 28 nm open process), power analysed on the reference's descriptor stream, read for exactness against the reference's vectors. Its output replaces the engine's ESTIMATED terms with a MEASURED-class energy per round and an area. An in-house adversarial review runs it from tonight on a box reliability allocates; the relation's owner's part is section 7, supplied now, and any further set an in-house adversarial review asks for, cut on a team machine by the generator within the hour of the ask.

7. The trace sets and vectors (in the tree at main; the paths)

• The launch document's sets, keyed and twin: the v8-d2048-s0-r64-k32-p256-w128-b2-x16-f5152-k2 directory (keyed.json, keyed-n100.json, dataset.json, trace.json, fp.json, the light classes nonce-boundary, unseen, transitions, malformed) and the v8-d2048-s0-r64-k32-p256-w128-b2-x16-f4128 directory (the unkeyed twin: fp.json at 15,872 rows, the four light classes, the dataset and tails classes, the trace class), plus the -k4 twin. Every vector carries the document's parameters and the expected mix and hash; the trace class carries per round the index, the 32 item words, h, the block snapshot and every lane's registers after the block, so the per-round switching activity of the pipeline is the diff of consecutive records; the fp class carries the per-descriptor binary32 intermediates (the two roundings) for the FP unit's exactness and toggle counts.
• The reference: the ref directory (libignpow, the C reference; ignh_hash, ignh_hash_keyed_m, the trace verb IGM_IH_TRACE_FULL in the harness workers prints S, E, P, init, fill and every round's idx, item words, h and registers); the vector checker ignpow-vectors check <dir> (exit 2 on a missing or wrong set; the fp class checked).
• One line of the record is not served here (a name, a machine or a path).
• The dataset itself for a power run of the memory side: derived by the reference from the document (2 GiB at the gate point); the cache 32 MiB; the derivation the hash directory names; the X16-Q row stands for the memory class and needs no new run (the review's section 9.2, agreed).

8. The lines the relation's owner takes from the review for the record

1. The band's engine must be re-based on the relation's forced operations on a fixed pipeline, not on the card's instruction stream; the record's model files (simt-die.json, version8-c-terms.json, captured-mix) stand as the SIMT-lane adversary's reading, labelled as such, beside the pipeline's.
2. The served sentences on /relation, /litepaper and /standard that carry 2.59x and 3.25x, and the guard rows G1 and the coexistence verdict that rest on them, do not stand on the record's own figures; the corrected band of section 5 is what the record supports today, with the placed pipeline's measurement to narrow it.
3. The design question the lever was meant to answer is open again: a programme that forces a programmable lane needs RandomX-class properties the record rejected for the GPU's sake (data-dependent control with divergence, a scratchpad with data-chosen addresses, program-set rounding modes, variable-latency shapes); whether any of them can be had at a GPU cost the cohort tolerates is a team-seat question with the independent reviewer, not tonight's.
4. cohort.json gains no row from this; the edge is not a cohort figure. The record's register entries that cite the band (LAUNCH-GUARDS.md G1, LAUNCH-READINESS.md condition (a), ablation-redteam.json's jointly-feasible-upper rows) are a team seat's and the coordinator's to re-grade on this answer.