DRAFT, not a pre-registration. It governs no session until reviewed, revised, and committed as
METHODOLOGY-v4.md BEFORE the first measurement it governs. Written immediately after seeing
results, so the two things that matter are stated up front and are checkable: the defect was found
in the ALGEBRA of the gate and then confirmed by observation, and the change makes sessions HARDER
to pass, never easier.

THE DEFECT. The v3 null is 20 pool-vs-pool sessions: fresh pool A against fresh pool B. Two
different 32-key pools do not have the same mean, so the null t is not standard normal but has
sd(t)^2 ~= 1 + (sigma_key/sigma_total)^2 * (n/32) -- a spread that grows with n AND grows as the
environment gets quieter. A fixed 4.5 cutoff on that statistic penalises precision.

THE FIX. Draw BOTH classes from the SAME pool (null-ss). The true difference is then exactly zero
by construction, the mixture shape is preserved (which a single-key A/A null cannot give), and
nothing else about the operation changes. sign-rr stays a gated EXPERIMENT -- pool-vs-pool was
only ever wrong as a NULL.

MEASURED, NOT ASSERTED (section 3, from the committed v3.1 report.json):

- The 20 null t values have sd = 1.742, not 1. The null is 74 percent wider than the gate assumes,
  on the machine where the gate held. Implied sigma_key ~= 10.4 us -- and that SAME parameter
  predicts sd(t) ~= 2.95 on the CI runner, under which 5 of 20 sessions tripping 4.5 is the
  expected order. One physical parameter explains both machines.

- A pre-registered probability of mine was ~10x too optimistic. METHODOLOGY-v3.1-POWER section 6
  put the chance of any null session tripping at 0.1-2 percent; at the measured sd(t) it was ~18
  percent. The estimate used v3b's sigma_total of 733 us, but the session ran quieter at 257-357
  us -- and quieter makes it worse.

- I ALSO WITHDREW A CLAIM FROM MY OWN DRAFT. The first version said the fix "does not change
  v3.1's PASS" because its crop p_emp sat far from the 1/N line. False: SHAPE needs the crop stat
  to exceed ALL 20 null sessions, 9 of 20 currently sit at or above sign-kk-1's 5.84, and the null
  max would have to shrink 43 percent -- while 10.24/1.742 = 5.88, within 1 percent of that
  boundary. If the crop statistic deflates like the raw t, v3.1's sign-kk-1 flips PASS to SHAPE.

- Which surfaces a SECOND defect from the same root: the v3 secondary arm has been systematically
  INSENSITIVE. Every "no SHAPE" reading in v2, v3, v3b and v3.1 was made against an inflated
  reference, so the shape diagnostic has been running with its threshold too high. The primary
  statistic was never affected.

BEFORE ADOPTION: re-judge v3.1's committed raw CSVs against a v4 null and publish the outcome
whatever it is. The experiment side is byte-reproducible (SHA256SUMS); only fresh same-pool null
sessions need measuring. If sign-kk-1 flips, CT_REPORT section 4c gets a correction.

Security Impact: none. A design document -- no code, no vendored C, no build flags, no rule in
force.

The obvious reaction to 'a quiet runner reaches 5.3 us in 20 min while this laptop needs 5.5 h
for 30-42 us' is to kill the running session. Wrong, for two reasons now written down so the
decision is visible rather than inertial:

1. It answers a question the runner cannot. The +13.9 us class-1 pattern is a property of the
   LAPTOP's nine sign-kk pairs. sign-aa on ubuntu says there is no arm offset ON UBUNTU, where
   allocator, alignment, scheduler and a 23x tighter distribution all differ. Only the local
   sign-aa, at +-10 us, tests the hypothesis on the machine where the pattern was seen.
2. It is the like-for-like successor to v3b: same machine, same build, same rules, 17x the
   samples - the only way to tell whether v3b's readings were power-limited or environment-limited.

And aborting a pre-registered session on a preliminary that does not bear on its own validity is
the habit pre-registration exists to prevent: easy to justify each time, corrosive in aggregate.
The correct response is that the session AFTER this one moves machines.

Security Impact: none - documentation only.