§4c, the reading of the 82k session:
- All five pre-registered gates passed; SESSION VERDICT PASS at MDE90 ~= 14.5 us (against a
  planned 30-42 us - the machine was quieter, sd 350-357 us vs the 425-1039 us planning band, so
  the session DOES resolve the 12-17 us range every earlier session was blind to).
- sign-aa puts the arm offset at +1.40 us with a CI of [-3.53, +6.33] - EXCLUDING +13.9 us. The
  control added the day before has answered its question: no systematic arm/layout offset of that
  size on the machine where the 8-of-9 pattern was observed. The pattern also failed to reproduce
  (this session: +4.05, -7.22, -6.94; pooled 9 of 12, two-sided p ~= 0.15).
- Exactly what the PASS licenses, and the list of what it does not license at any sample size.
- A predictions scorecard including the one that was WRONG (sign-key predicted a near-certain
  FAIL at E|t| ~= 12.5; observed t = 2.36, PASS) and why: it assumed v3b's point estimates were
  true. So did the 44% FAIL forecast. Both failed for the same reason.
- The methodological result, which is worth more than the verdict: the +12-17 us deltas that three
  rounds of council review forced this repo to withdraw have now failed to reproduce at 17x the
  samples, INCLUDING THEIR SIGN. Sub-threshold t with a CI excluding zero is a documented
  non-replicating shape here, not a weak signal.
- Recorded before anyone reads them as a finding: two gated pairs again show that same shape,
  now negative. Fourth session running; the first three did not replicate.

Document header rewritten: the top of this file previously presented the WITHDRAWN v1 FAIL as
the report's verdict, so a reader who skimmed left with the wrong finding (flagged by the pre-run
language audit). There is now a five-row table of every session, its verdict and what it is worth
today, with the standing statement that nothing here is a constant-time claim. Earlier sections
stay unedited except where a correction is marked - the record of what was claimed and withdrawn
is itself the evidence that the process works.

Security Impact: none - documentation. No code, no vendored C, no flags. The net effect on claims
is restrictive: one over-broad header removed, one PASS bounded by a stated MDE90, and a
previously live hypothesis (arm layout) excluded by measurement rather than by argument.

Eight concurrent rust-ci runs had queued on PR #39, most of them behind markdown-only commits.
Three causes, three fixes, all in the workflow file:

1. A pull_request path filter is evaluated against the PR's CUMULATIVE diff, not the newest
   commit. PR #39 has touched rust/** and third_party/** extensively, so every later push to the
   branch matches the filter no matter what it changed. That is GitHub behaving as documented and
   the filter cannot express "what this commit touched" -- so the fix is the concurrency group
   below, not a cleverer filter.
2. push and pull_request both fired for the same SHA, running everything twice. push is now
   restricted to the default branch; pull_request already covers PR branches.
3. No concurrency group, so superseded runs kept going. Added, with cancel-in-progress: a
   superseded run reports on code nobody has any more.

And the falcon-ct evidence session no longer runs per-push -- it is now schedule (weekly) plus
workflow_dispatch. It costs 20+ minutes, and its verdict is currently INCONCLUSIVE BY
CONSTRUCTION on this class of runner: the null gate is a fixed |t| < 4.5 applied to a
pool-vs-pool null whose spread grows as the environment gets QUIETER, sd(t)^2 ~= 1 +
(sigma_key/sigma_total)^2 * (n/32). The runner's sigma_total is ~32 us against the laptop's
350-733 us, so 5 of 20 null sessions tripped the gate and voided the session while BOTH synthetic
controls behaved perfectly (evidence/ct/OBSERVATION_ci-ubuntu-2026-08-18.md). Until the v4 null
lands, a per-push session spends runner time re-deriving a known INCONCLUSIVE. Weekly plus
on-demand keeps its real value -- it is also the end-to-end smoke test of the harness, and it is
what caught that the v3.1 binary ran correctly before the 5.5-hour local session.

The reason to restore the per-push trigger is written into the job so it is not forgotten: when
the v4 null makes a CI session capable of a verdict again.

Security Impact: none. CI scheduling only -- no gate weakened. Every correctness job (3-OS KAT,
fmt+clippy -D warnings, MSRV, cargo audit + deny) still runs on every relevant push and PR; only
the non-gating observation job moved off that cadence.

A second review -- an independent reimplementation of welch_t / pooled_percentile / t_values /
crop_statistic that reproduces report.json exactly -- found seven defects in revision 1. Every
number below was re-verified locally before acting on it. The design survives; three of my claims
do not.

WITHDRAWN: "10.24 / 1.742 = 5.88, within 1% of the boundary". That number should never have been
computed. It divides a max-of-nine ORDER STATISTIC by an sd measured on the RAW t: the nine crop
t's have their own spreads across the 20 null sessions -- 3.82, 4.79, 5.21, 5.63, 4.69, 3.94,
3.24, 2.91, 2.33 -- and none of them is 1.742. The max is attained at crop 0.80 in 8 of 20
sessions and at six other crops in the rest, so it is not even a fixed statistic. Cropping also
shrinks the denominator (SE 2466 ns raw vs 906 ns at crop 0.50 on raw-sign-rr.csv), so removing a
location offset deflates the crop by MORE than the raw factor -- the opposite direction to what
"the same factor" assumed. And every stable-looking estimate disagrees: the chi-square band maps
10.24 to 4.03-7.73, spanning all three outcome branches; two decompositions give 4.97 and 7.31.

OVERSTATED IN ITS OWN CONSEQUENCE: "v3.1's PASS may flip". Revision 1 named only the middle
outcome -- the one that does NOT change the verdict. All three are now pre-registered, with
thresholds read off the code (SHAPE iff the crop exceeds ALL 20 null sessions; sign-kk combines at
>= 2 of 3; session = worst of kk_combined and sign-rr; the three kk crops are 3.4754 / 5.3584 /
5.8405):
  >= 5.8405           nothing moves                      -> PASS unchanged
  5.3584 - 5.8405     sign-kk-1 alone SHAPE              -> PASS UNCHANGED (one pair cannot carry
                                                            >=2-of-3); one CT_REPORT row and one
                                                            sentence need correcting
  < 5.3584            kk-1 AND kk-2 SHAPE                -> session SHAPE
Flipping the SESSION needs the v4 null's crop max below 5.3584, not below 5.84.

AND THE BEST AVAILABLE PRIOR SAYS IT DOES NOT FLIP: v3b's 20 null sessions carry an inflation of
only 1.004-1.024, so they are ALREADY a v4-equivalent null on the location statistic. Their crop
max is 5.749 -- between kk-2's 5.358 and kk-1's 5.840, i.e. the middle branch. n = 2352 against
v3.1's 40180, so it settles nothing, but it is evidence and it belongs in the file.

FALSE AND WITHDRAWN: "every 'no SHAPE' reading in v2, v3, v3b and v3.1 was made against an
inflated null". Checked against the committed reports: v2's null was 24 FLAT-LOOP sessions -- a
NARROW null -- and v2 returned SHAPE on all six signing experiments, so it contains no "no SHAPE"
readings at all; v3's first run had null_ok:false and minted nothing; v3b's inflation was under
2.5% and immaterial. ONLY v3.1 had a materially inflated null. Over-claiming about this project's
own record is the exact failure this file exists to correct, and I did it.

ALSO FIXED:
- The contradiction between 2a and 3.3 over which reference judges sign-kk. Named: repeated
  sign-aa. Ambiguity resolved BEFORE any measurement.
- "All ten experiments' raw samples are committed" -> report.json holds 9 experiments, the
  directory holds 11 raw CSVs, SHA256SUMS covers 13. And the null side is NOT recoverable, so a
  re-judge compares August's experiment crops against a null measured later, on different key
  material, in a different thermal state. Stated.
- The design was never priced. Measured: mean sign is 7.7066 ms, one 82k block is 632 s, 20 null
  sessions are 3.51 h = 63.6% of v3.1. Three references at 82k is ~10.5 h of null before an
  experiment runs. So v4 session 1 is a VALIDATION run at v3b scale (~1 h) whose only job is to
  answer whether null-ss gives sd(t) ~ 1; sizing a verdict session comes after. Running a 10-hour
  verdict session on an unvalidated null would repeat the v3.1 ordering mistake at five times the
  cost.

NEW 2b, alternatives rejected -- including one that would have been a disaster: a
label-permutation surrogate null returns sd(t) ~ 1 BY ALGEBRAIC IDENTITY whatever the data holds.
Run on raw-control-leaky.csv, whose raw t is -296.34, it returns 0.97. A reference that certifies
the deliberately leaky control is the check-that-cannot-fail defect this repo keeps a register
for. Excellent regression fixture, not a null.

AND a second confirmation of the defect that never touches a t statistic: sd(dmean) = 3229.8 ns
against rms(se) = 1839.1 ns implies a between-pool offset sd of 2655 ns, hence a predicted sd(t)
of 1.756 against 1.742 observed; both routes put sigma_key at 10.49 / 10.62 us.

Still a DRAFT, in force nowhere.

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

Code (S8, S6): judge_raw_only now maps a non-finite raw t to INCONCLUSIVE
(welch_t is total today, so the guard is unreachable through real samples
and documented as such - it exists so INCONCLUSIVE-never-PASS survives a
future welch_t change). The regression test is now TWO-SIDED: the same
flat series judged v2-style against a bank built strictly below its own
crop statistic is demoted to Shape (the live failure's mechanism), while
raw-only Passes it - reverting the production wiring goes red. A constant
series is asserted flat-and-finite -> Pass.

Pre-registration amendment (S1-S5, prospective, before any run exists):
instrument pinned to the amendment commit with cargo build --release
--locked and recorded toolchain; null_raw_t_sd defined in the document
(n-1 sample SD over the 20 null-ss raw t values); one-run/first-launch
rule with every attempt kept and pre-measure environment capture;
blindness clause over the quarantined banks until the controls pre-reg
and section 6.1 are committed; reading gated on the replicate's own
controls with all-20-or-no-reading; the partial band is a NO-PROCEED;
the founder A/B choice is dated before any governed launch and a Branch A
stop carries to Branch B.

RETRACTIONS (S7, S9) - correcting my previous commit message and docs:
"cannot lift any session verdict" was FALSE: removing the mismatched crop
demotion can flip controls NOT-OK -> OK, which lifts control-blocked
INCONCLUSIVEs back to their isolated verdicts - that lift is the ruling's
intent and is now stated, not denied. And "the crop diagnostic does not
run" overstated the implementation: crop statistics are still computed
and retained as descriptive numbers; what is true is that no crop p
against any bank is computed and nothing in the verdict path reads them.
A raw-line fire on the flat control blocks the session pending diagnosis;
it does not by itself diagnose an environment failure.

Left open, tracked for the next increment: a bin-level wiring test
through null_and_controls with the real generators, and verifying the
leaky control's 40k/60k work survives release-profile DCE.

Gates: fmt, clippy pedantic+nursery clean, 24 falcon-ct tests green.

Security Impact: harness only. The changes narrow (NaN guard, pre-reg
holes closed) or correct the record (retractions); no rule is loosened.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

A6. controls.null_reason is now serialised. It existed only as a console line, so a reader
holding report.json alone saw null_ok: false with no way to tell a too-noisy environment from
sessions that never ran — and the console is exactly what does not survive (the CI job publishes
to an expiring summary; a local run keeps it only if the launcher redirected it).

A7. One line per null session as it lands, with an explicit marker when a session trips the gate.
The null is two thirds of a long session's wall-clock and used to print its start and then
nothing for hours: a crash inside it was diagnosable only as 'it died somewhere in the null', and
a session drifting toward the gate was invisible until the end. On the ubuntu runner, where 5 of
20 sessions trip, this now shows as it happens instead of in a post-mortem.

A8. With no usable null the min/max folds printed 'crop-stat range inf..0.00' — a range that
reads like a measurement and is the empty set. Now 'none (null rejected)'.

The fold is extracted into fold_null() so null_and_controls stays under the line limit and the
empty-null display lives next to the decision that produces it.

40 tests green, fmt + clippy -D warnings clean. No decision rule touched; this is entirely about
what the artifact tells a reader who was not present when it ran.

Security Impact: none - no vendored C, no flags, no signer path.

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.

Distilled from METHODOLOGY-v4-DRAFT.md after two reviews (council 5 CONFIRMED / 1 OVERSTATED; an
independent statistics audit that reproduced report.json exactly and withdrew four of the
author's own claims). This file is the rules; the reasoning stays in the draft.

In force: NOTHING CHANGES for any session that does not pass --null-design ss. v3 + v3.1 remain
the operative rules. This commit exists so that the rules are on the branch BEFORE the harness
change that makes them selectable, and before any measurement under them.

What v4 says, in one table: match each reference to the class structure of what it judges.
- environment gate: 20x null-ss (ONE pool, both classes, independent index draws), raw |t| < 4.5
- sign-kk-* crop reference: repeated sign-aa (N >= 20 for a verdict session)
- sign-rr crop reference: null-rr sessions, EMPIRICALLY — and its raw statistic is flagged: a
  pool-vs-pool raw t carries the same inflation as the old null, so at ~10x v3.1's samples it
  would cross 4.5 with no leak present; a sign-rr raw FAIL reads "delta +- CI is resolvable between
  two pools", never a leak; v4.1 decides a null-referenced raw threshold BEFORE any such session.
- everything else unchanged: primary statistic, 4.5, per-class floor, warm-up, crops, SHAPE rule,
  >=2-of-3 combination, session fold, A/A downgrade-only gate, INCONCLUSIVE never PASS.

Session 1 is a VALIDATION run, pre-registered as such: --samples 4800, 20 null-ss + 20 sign-aa
repeats + 20 null-rr, ~1 h, laptop. Nothing in it is read as evidence about the signer. The
deciding number is controls.null_raw_t_sd, the sample sd of the 20 null-ss raw t values, with the
reading fixed now: <= 1.25 proceed; 1.25-1.60 partial, v4.1 must add a null-referenced raw
threshold first; > 1.60 the mechanism is wrong or incomplete, stop and re-derive. (v3.1 under rr
was 1.742; the chi-square band on a 20-value sd is roughly x0.76-x1.46, so the lines are coarse on
purpose.) A null-ss session tripping 4.5 is a RESULT, published INCONCLUSIVE, not a failure.

After session 1, sequenced and gated: re-judge v3.1's committed experiment CSVs against the 20
sign-aa repeats under the three pre-registered branches (>= 5.8405 nothing moves; 5.3584-5.8405
kk-1 alone SHAPE, session PASS unchanged, one CT_REPORT row corrected; < 5.3584 session SHAPE),
stating that the reference is a LATER null on different keys in a different thermal state; then
size a verdict session in a v4.1 addendum before running it; then the machine decision, as a
separate change so a failed session can be attributed.

Implementation status: the harness change (--null-design, --aa-repeats, --rr-sessions,
null_raw_t_sd, schema 5) is NOT yet written — an agent run to implement it failed to start
(account usage limit), the Rust tree is untouched, and nothing was left half-done. This file
therefore deliberately precedes the code. The order is the point.

Security Impact: none — a rules document that changes nothing in force. No code, no vendored C,
no flags.

An addendum to METHODOLOGY-v3, NOT a replacement: every decision rule is unchanged and
restated. v3b ended in PASS, and a methodology edited after a favourable result in the
direction of keeping it is worthless. Only the sample size moves, and it moves UP.

1. THE CORRECTION. CT_REPORT §4b read the 95% CI half-width as the session's resolution.
   The pre-registered rule is |t| >= 4.5, not 1.96, so the effect detected with probability
   P is (4.5 + z_P)*SE — about 2.95x the CI half-width at 90%, not equal to it. Recomputed
   from v3b's own report.json, its real resolution was MDE90 = 72–175 µs per pair (not the
   "±15 µs" claimed), and reaching 15 µs needs ~320k measurements/experiment (~22 h), not
   the "40–80k" estimated — low by ~4x. The v3b VERDICT is unchanged; the size of the claim
   it supports is not. CT_REPORT corrected in this commit.

2. THE SIZE: --samples 82000, --null-sessions 20, ~5.9 h. MDE90 30 µs (median-sd pairs) to
   42 µs (widest pair); CI ±10–14 µs. Derivation and measured wall-clock scaling in §2 so it
   can be checked rather than believed. 82k is a budget and is stated as one.

3. NEW CONTROL — sign-aa. Across v2/v3/v3b, 8 of 9 INDEPENDENT key pairs put class 1 slower,
   mean +13.9 µs (binomial p ~= 0.04): the offset follows the ARM, not the key. Candidate
   mechanism is in the harness, not in Falcon — a sign-kk pair is one tuple, so class 0's sk
   sits at offset 0 and class 1's at +4098 B, a different cache alignment every measurement;
   sign-rr, whose arms are separate allocations, shows the opposite sign. At 82k the CI on
   that offset is ±10 µs, so the session would have measured a possible artefact precisely
   with no control able to say so. sign-aa signs with copies of the SAME keypair in both
   arms, laid out exactly as a kk pair: true difference zero by construction. Informational,
   never gated, and DOWNGRADE-ONLY — only a PASS on sign-aa lets the session's key verdicts
   be read (FAIL/SHAPE/INCONCLUSIVE force them all INCONCLUSIVE). Enforced by a pure
   function with a property test asserting the rule can never invent a verdict.

4. STATED IN ADVANCE, because high power exposes it: the gated experiments have NO true null.
   Two fixed keys almost certainly differ in mean work, so a large enough n eventually FAILs
   by construction. A FAIL therefore reads "an effect of size Δ ± CI is now resolvable",
   never "a key-dependent leak was found", and never an exploitable channel without a
   separate argument. Also recorded before the run: the null gate's own t spreads as
   sd(t)^2 ~= 1 + (σ_key/σ_tot)^2·(n/32), giving a ~0.1–2% chance any of the 20 sessions
   trips 4.5 here — expected to hold, a real ceiling at ~10x these samples, and if it does
   trip the session is INCONCLUSIVE under the rules as written, not re-run under a looser gate.

Harness (falcon-ct), no decision rule touched:
- welch_se, inverse_normal_cdf (Acklam; NO Halley step — the local A&S erfc is ~1.5e-7,
  two orders worse than Acklam, so refining with it moves the answer away from the published
  quantiles; measured both ways, comment kept so it is not "fixed" back), and
  min_detectable_effect. Unit-tested against published quantiles and for 1/sqrt(n) scaling.
- Every experiment reports se_ns / mde80_ns / mde90_ns in report.json and on the console,
  under a printed reminder that PASS means "nothing at or above MDE90 was detected". After
  this, a session cannot publish a non-detection without publishing what it could have seen.
- controls.null_detail: the full judged result of all 20 null sessions. The null costs two
  thirds of the session and previously survived as 20 bare floats.
- The undocumented --samples >= 4600 admission rule is now pre-registered (it lived only in
  a code comment citing a §1 that did not contain it).
- schema_version 4; additive and serde(default), so schema-3 readers still parse.

38 tests green, fmt + clippy -D warnings clean. Session to follow, published whatever it says.

Security Impact: none to the signer — no vendored C touched, no build flag changed, compiled
bytes still the pinned bytes. This changes what the evidence layer is allowed to claim, in the
restrictive direction: one previously published resolution figure was too generous by ~4x and
is corrected, a new control can force verdicts to INCONCLUSIVE and can never lift one, and
Phase E stays blocked. Nothing here is a constant-time claim in either direction.

Ran 2026-08-18 16:39-22:10 (5 h 31 m, inside the 5.5-5.9 h predicted band) under
METHODOLOGY-v3.md + METHODOLOGY-v3.1-POWER.md, which were committed BEFORE it started and whose
decision rules it did not touch. Artifacts: report.json (schema 4), console.log, ten raw CSVs,
SHA256SUMS. Raw data is 8.4 MB and is committed rather than summarised: this is the session an
external auditor will want to recompute.

ALL FIVE PRE-REGISTERED GATES PASS:
1. schema_version == 4 (the v3.1 binary ran).
2. null_ok, 20/20 null_detail entries, none with |raw t| >= 4.5 (max 3.94), all splits within
   +-170 of 40 180/class. The null gate held, as predicted for this machine (~0.1-2%) - and the
   3.94 max is itself consistent with the predicted sd(t) ~= 1.1-1.4 rather than 1.0.
3. controls_ok: flat PASS (t = -0.15), leaky FAIL (t = -296.34).
4. sign-aa PASS.
5. sign-aa delta = +1.40 us, CI [-3.53, +6.33].

THE ARM-LAYOUT HYPOTHESIS IS EXCLUDED ON THE MACHINE WHERE THE PATTERN WAS SEEN. sign-aa - the
same keypair in both arms, laid out exactly as a sign-kk pair - puts the arm offset at
+1.40 us with a CI that excludes +13.9 us outright (upper bound +6.33 us). The control added
yesterday because 8 of 9 pairs had put class 1 slower has answered its question in one session.
And the pattern itself did not reproduce: this session's three pairs are +4.05, -7.22, -6.94 us
- one positive, two negative - taking the pooled count to 9 of 12 (two-sided binomial p ~= 0.15,
no longer significant).

GATED RESULT: sign-kk combined PASS from [PASS, PASS, PASS]; sign-rr PASS. Every gated line's
raw |t| <= 2.9 against the 4.5 rule, and every crop p_emp >= 0.476 against the real-operation
null. Achieved resolution MDE90 = 14.3-14.5 us, roughly TWICE the planned 30-42 us, because the
observed sd was 350-357 us against the 425-1039 us planning band - the machine was quieter than
during v3b. The session therefore resolves the ~12-17 us range the earlier sessions could not.

PREDICTIONS SCORECARD (METHODOLOGY-v3.1-POWER.md §7, written before any experiment ran):
- Null gate holds: CORRECT (max 3.94).
- verify-ctrl and keygen cross 4.5: CORRECT (t = -25.5 predicted ~33; t = -161 predicted ~151).
  Both informational, both pre-stated, neither a finding.
- sign-key near-certain FAIL (E|t| ~= 12.5): WRONG. Observed t = 2.36, PASS. The prediction
  assumed v3b's delta of -46.4 us was true; the observed delta is -5.9 us.
- P(at least one kk pair FAILs) ~= 44%: no FAIL, same cause.
The mechanism-based predictions held; the two that treated v3b point estimates as true both
failed. THAT IS THE SESSION'S METHODOLOGICAL RESULT: the "+12-17 us fixed-key deltas" that three
rounds of council review forced this repository to withdraw as claims have now failed to
reproduce at 17x the samples, including their sign. The discipline was right, and sub-threshold
t with a CI excluding zero is confirmed as a shape that does not survive replication.

Two gated pairs again show sub-threshold t (2.88, 2.79) with CIs excluding zero, now NEGATIVE
(-7.22, -6.94 us). By the pre-registered rules these are descriptive only and are not read.
On the record before anyone reads them as a finding: that is the fourth session in a row to
produce this shape, and the first three did not replicate.

Also: .gitattributes now pins -text on evidence CSVs, report.json, console.log and SHA256SUMS.
The blobs are already stored LF, so nothing in the index changes; it stops a Windows checkout
rewriting LF to CRLF and invalidating every published hash on a fresh clone - the same failure
already fixed for the vendored tree.

Security Impact: no code, no vendored C, no build flags. This is measurement output plus a
line-ending attribute. It does NOT establish that the signer is constant-time and is not read
that way anywhere: a PASS here means no per-key location difference at or above ~14.5 us was
detected on this machine and build. Phase E remains blocked pending the team reading.

Written while the session was still in its 3.7 h null phase — no experiment had run — so that
none of it can be offered afterwards as insight. From the pre-run audit (4 auditors + 16
adversarial verifiers; 2 findings survived refutation).

§7, new:
- sign-key (E|t| ~= 12.5), verify-ctrl (~33) and keygen (~151) are EXPECTED to cross the 4.5
  line at n = 40,180/class. None is gated; sign-key's point-mass-vs-mixture design was demoted
  in v2 and a bigger n does not decorrelate it. A raw FAIL there is a prediction met, not a
  discovery — pre-stated so the first one is not read as one.
- P(at least one sign-kk pair FAILs) ~= 44% under v3b's own point deltas (whose CIs all span
  zero). By the combination rule that is a session FAIL. The FAIL sentence §3 licenses is the
  one that must survive a 44% event.
- sign-aa's gate fires at |delta| >= 23.3 us but the arm offset it tests is ~+13.9 us, so it
  will most likely PASS while still MEASURING the artefact. Read its delta and CI, not its
  verdict word; the three readings are spelled out.
- The binary was not smoke-run end-to-end before launch (19 min of load cannot be spent during
  a timing session). Recorded as a mistake in ordering rather than quietly fixed.

Corrections to text already in this file:
- Resolution is 17-42 us MDE90 / +-5.9 to +-14.4 us CI, per experiment. The "30-42 us / +-10-14
  us" first published here and in CT_REPORT §4b is median-to-worst and drops sign-kk-1, the
  narrowest pair. Under-claims rather than overstates, but a range that is not the range is
  still wrong; each experiment's own mde90_ns is authoritative over any advance table.
- Wall-clock ~= 5.5 h (band 5.5-5.9). The earlier 5.7 h scaled from a six-signing-experiment
  session; sign-aa makes it seven.
- console.log is captured by the launch command's redirect, not by the harness. An earlier
  draft implied the harness writes it; it does not.

Known reporting defect, disclosed and deliberately NOT fixed mid-session: with an empty null,
judge_v2 stores crop_empirical_p = 1.0 and its SHAPE arm (guarded by n > 0) cannot fire, so an
experiment falls through to PASS — visible in the committed session-...-v3/report.json beside
null_ok: false. It cannot change this session's verdicts (an unfit null already forces every key
verdict INCONCLUSIVE through the flat-control lever) but it would silently disable sign-aa's
SHAPE arm in that state. Fix after the run; the harness is not rebuilt while a session measures.

Security Impact: none — documentation and predictions only, no code, no vendored C, no flags.

Adopts the five-seat review of the v1 session. Primary statistic is the raw
Welch t (|t| >= 4.5, n >= 2000/class); the crop statistic max|t| becomes a
secondary diagnostic judged against an empirical null from N >= 20 flat-control
sessions in the same run (empirical p), never against 4.5 alone. New verdict
word SHAPE (raw t null, crop p < 1/N) = distributions differ in shape/scale, not
means; never PASS, never FAIL. New gated designs: sign-kk (two fixed keys, three
pairs — the per-key fingerprint measured directly) and sign-rr (two random
pools — symmetric-variance control); v1's fixed-vs-random demoted to screening.
Reports df, p, mean difference with 95% CI, per-crop counts; timer resolution
stated per OS; best-effort CPU pinning recorded. v1 file left unchanged as the
record the first session was judged by.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Five seats (4 honest / 1 no) asked for tighter labels, not a different verdict:
'no location dependence' -> 'not detected at this power; insensitive to ~±15 us;
bounded only within the reported CIs'; 'v2 SHAPE were artefacts' -> 'non-
evidentiary under the corrected null (compatible with, not proven)'; sign-key
point-mass-vs-mixture explanation labelled hypothesis and the SHAPE word
reserved for gated designs; the '~20k' figure replaced by an honest estimate at
v3's variance (~40k per class, 40-80k per experiment; not a pre-specified power
calculation); raw-t vs dmean sign convention and the 1/21 null resolution stated.

Security Impact: none to code; tightens what the evidence may claim.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Five seats (GPT-5.6 Sol, Grok 4.6, DeepSeek V4 Pro, Hermes, Kimi K3) reviewed
the first session. All five converged: max|t| over ten correlated crops against
dudect's single-test 4.5 cutoff has no multiplicity control; a raw Welch t near
zero (-0.73 / +0.83) that becomes 9-11 only under one-sided pooled-percentile
cropping, with the higher-variance class losing more samples to the crop, is
the signature of variance-by-crop asymmetry (and point-mass-vs-mixture), not of
a location leak; core pinning / turbo were not controlled; Windows Instant is
QPC at ~100 ns ticks, not "~ns"; the sampler-loop attribution is a hypothesis.
Overclaim vote 3 yes / 2 no; resolved in the critics' favour.

The pre-registered verdict word stays FAIL (rules are not rewritten after the
run). What it SUPPORTS is downgraded, in the headline and in a new section 3a:
the two classes' timing distributions differ in shape/scale on this machine;
the means do not measurably differ; the v1 statistic is not fit to call that a
leak; exploitability INCONCLUSIVE; nothing here may be cited as "Falcon leaks
the key through timing". Section 5 becomes the METHODOLOGY v2 list: one primary
statistic (raw Welch t / permutation), crops as diagnostics against an
empirical null from >=20 flat-control sessions, fixed-vs-fixed and
random-vs-random designs, df/p/effect sizes with CIs, environment controls,
modality test, source-level reading as supporting evidence.

Security Impact: none to code; this tightens what the evidence is allowed to
claim.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

evidence/ct/METHODOLOGY.md fixes, before the first Falcon run: Welch's t on
raw + nine percentile-cropped variants with the reported statistic max|t|;
threshold |t| >= 4.5 in ABSOLUTE value (the ZUSS draft's one-sided rule was
rejected in adversarial review — a large negative t is a leak too); minimum
2,000 samples per class; per-measurement randomised class order; 2% warm-up
discard; the six experiments (flat control, leaky control, sign-key,
sign-msg, verify-ctrl, keygen) with what each FAIL means; and the verdict
words PASS / FAIL / INCONCLUSIVE — INCONCLUSIVE never reported as PASS.

Observation, not a product gate: a FAIL/INCONCLUSIVE blocks the self-KAT
signer default and any CT claim; it never patches the vendored primitive.

Also adds `prng_extract` (shake256_extract) to trelyan-pq-ffi so the harness
draws class bits and random messages from the audited SHAKE PRNG instead of
taking a new dependency.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

session-2026-08-18-local-v3b (4 800 per experiment, 20 real-operation null
sessions, no other load): null OK (crop-stat null min 0.67 / median 1.84 / max
5.75 — v2's flat-loop null max 1.89 was far too benign, as concluded), controls
OK; all three message-balanced fixed-key pairs and the pool-vs-pool control PASS
on the raw statistic (|t| <= 1.04, every CI spanning zero) and on the crop
diagnostic against a same-kind null (p_emp 0.10-0.29); kk combined PASS; session
PASS. Screening fixed-vs-random still SHAPE (point-mass-vs-mixture asymmetry —
the reason it was demoted), not read as key-dependence.

Power caveat stated: the four-message rotation widens each class (sd 0.41-1.06
ms vs 0.21-0.23 in v2), so CIs on dmean are ±25-60 us vs ±10 us; the ~12-17 us
fixed-key deltas v2 recorded are neither confirmed nor excluded; resolving them
under v3 needs ~20k samples per experiment (next run, same rule).

Consequences: Phase E stays blocked (one PASS at limited power on one machine is
not "a sound PASS exists"; PASS is not a proof); direction of the evidence
after three pre-registered iterations: no location dependence on the key at the
tested power; earlier FAIL/SHAPE readings understood as artefacts of the
statistic and null. Raw CSVs committed. No security claim in either direction.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The CI job on eb2ea04 ran the v3.1 binary end-to-end (sign-aa, null_detail, power fields,
schema_version 4) and completed — the smoke test the pre-run audit asked for and that could not
be run locally while the 82k session measures. It ended INCONCLUSIVE, and no Falcon verdict is
read from it. Three things it DOES establish, in evidence/ct/OBSERVATION_ci-ubuntu-2026-08-18.md:

1. THE NULL GATE FAILED ON A QUIET MACHINE AT LOW n. 5 of 20 null sessions tripped raw |t| >= 4.5
   while both synthetic controls behaved perfectly (flat passes, leaky fails at t = -226). The
   pre-registered mechanism fired from the unexpected direction: sd(t_null)^2 ~= 1 +
   (sigma_key/sigma_tot)^2*(n/32) blows up when sigma_tot is SMALL. This runner's per-signature
   sd is ~32 us vs the laptop's 733 us, so the null t stops being standard normal at n = 2350.
   Predicted ~92% chance across twenty sessions; 5 of 20 observed. The gate as written PENALISES
   PRECISION - the better the environment, the likelier the session is voided - which is why
   every CI session has been INCONCLUSIVE. v4 item C4 promoted from future concern to evidenced
   defect blocking current runs. The local 82k run is unaffected (~0.1-2%), as pre-registered.

2. DEFECT A1 IS VISIBLE, INCLUDING ON THE NEW CONTROL. With the null rejected, every line printed
   p_emp = 1.000 from an empty null - one line reads 'crop max|t| = 38.17  p_emp=1.000'. The key
   experiments are saved by the control rule, but sign-aa is not routed through it and so reported
   Pass with its SHAPE arm never run. A1 moves to fix-first, with this session as its regression
   fixture. A8 added (the empty-null summary prints 'crop-stat range inf..0.00').

3. ENVIRONMENT CONTROL IS THE LARGEST LEVER, MEASURED: 20 minutes on that runner reaches MDE90
   ~= 5.3 us; 5.5 hours locally at 82k reaches ~30-42 us. Quadrupling samples buys 2x; changing
   machine bought 23x. The next session's design question is 'on what machine', not 'how many
   samples' - and it cannot be answered until C4 is fixed.

sign-aa there: delta = -648 ns, CI [-2452, +1156], SE 920 ns => no arm offset at the ~5 us level
on that machine, which disfavours a universal struct-layout explanation for the laptop's +13.9 us
class-1 pattern while leaving open that it is real on the laptop. The local sign-aa is the
measurement that speaks to the laptop.

Explicitly NOT concluded: anything about key-dependence. That session's three sign-kk pairs are
freshly generated keys, its crop arm is void, and its verdict is INCONCLUSIVE.

Security Impact: none - documentation only. No code, no vendored C, no flags. The observation
tightens what the evidence layer may claim and promotes a known defect; it withdraws nothing.

First Tier-1 code in the flagship, and the first step of the Rust port the
ecosystem audit recommends (trelyan-pq core → Rust with zeroize, pyo3 shim
later). Two crates under rust/:

* trelyan-pq-ffi — the ONLY crate allowed `unsafe`. Its build script first
  recomputes the pinned tree digest over third_party/falcon-det1024/src
  (same sha512/256 construction as sdk/ci/verify_pinned_digest.py; expected
  c6adf487…, 27 files) and refuses to compile anything else; then compiles
  the eleven library sources with the pinned config.h (FALCON_FPEMU=1) plus
  exactly the flags CI already proves byte-identical to the goldens
  (-DFALCON_UNALIGNED=0, -fno-strict-aliasing on non-MSVC). Every extern is
  declared as falcon.h/deterministic.h declare it; every wrapper's argument
  types ARE the memory-safety proof — fixed-size arrays for the buffers the C
  side writes or reads without checking (sign_compressed writes up to 1423
  bytes and never consults the caller's capacity; get_salt_version reads
  sig[1] unconditionally). Miri cannot execute FFI; the gap is stated and
  covered by the KATs + the SDK's ASan/UBSan gate on the same C.

* trelyan-pq-core — #![forbid(unsafe_code)]. SecretKey zeroized on drop with
  no Debug/Display/Clone/Serialize and one greppable `expose()`; PublicKey;
  Signature::from_bytes as the SDK's encoding rejection matrix in constructor
  form (header 0xBA, salt version 0x00, length in [2,1423]); keygen from the
  OS CSPRNG (the C library's system PRNG path, same as the audited SDK);
  deterministic sign; verify; error enums via thiserror.

Tests (11, all green locally on Windows/MinGW and to be confirmed on the 3-OS
CI matrix): unit tests for determinism, wrong key/message, flipped byte,
encoding matrix, seeded reproducibility, OS-RNG keygen, bounded Debug; and
tests/kat_det1024.rs — the byte-identity KAT against
sdk/tests/vectors/det1024_kat.json: fixture bound to the same pinned commit
and deterministic.c digest this crate compiles, every golden reproduced BYTE
FOR BYTE by the Rust signer, verified, and rejected under a changed message,
a flipped byte, and the randomised 0x3A header. That is the property that
makes a Rust port safe to introduce: not "it verifies" but "it produces the
same bytes" as the Python SDK and, transitively, as what falcon_verify
accepted on-chain.

Workspace: edition 2024, rust-version 1.90, toolchain 1.97.1 for dev,
clippy pedantic+nursery at warn with unwrap/expect/panic denied, deny.toml
with an explicit licence policy, dependency justifications in Cargo.toml
(cc, sha2 build-only, zeroize, thiserror; serde/serde_json/sha2 dev-only).
CI: .github/workflows/rust-ci.yml — fmt+clippy -D warnings, test on
ubuntu/macos/windows with an assertion that the KAT ran by name and the ffi
pin verification was printed, MSRV build on 1.90, cargo audit + cargo deny.

Not in this commit, on purpose: inscription message layout (trelyan_pq.message
port), pyo3 shim, sealed signer, and any constant-time claim — the reference
signer's timing is measured in the falcon-ct evidence work, not asserted here.

Security Impact: adds a second, independent consumer of the pinned Falcon
tree; the compiled bytes are the pinned bytes by construction (build-time
digest gate) and the produced signatures are the golden bytes by test.
Introduces `unsafe` in exactly one crate with SAFETY proofs; nothing here
touches the deployed contract, the SDK, or any key path.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

third_party/falcon-det1024/src is the deterministic Falcon-1024 reference tree
at commit ce15e75bceb372867daf6b8e81918ab6978686eb — the commit go-algorand's
release vendors, the one the AVM falcon_verify opcode runs, and the one the
SDK's det1024 KAT goldens were produced from. Fetched as the GitHub source
tarball (1,391,487 bytes, sha256 dfac3e6f…), verified byte-identical to the
independent pin evidence kept since 2026-08-11, and vendored EXACTLY: 27 files
including the four Go binding files that TRELYAN never compiles, so that the
existing sdk/ci/verify_pinned_digest.py passes on the vendored tree unchanged
(tree digest c6adf487…, deterministic.c 601390dc…, FALCON_FPEMU=1). "Vendored"
and "pinned" are therefore one claim, checkable with one tool.

Why: every CI job that builds the signer downloaded that tarball on every run.
A build that depends on GitHub serving an archive is not hermetic, and a
supply-chain review asks first "which bytes did you compile?" — the answer is
now in the repository, per-file (SHA256SUMS, 27 lines) and as a tree digest.

CI: new job `vendored-falcon-integrity` (sha256sum -c + manifest completeness
+ the digest/FPEMU gate); the three fetch steps in signature-kat,
contract-tests and the TestNet job now `cp -r third_party/falcon-det1024/src
falcon-src` and run the same digest gate as before; third_party/** added to
the path filters so a change to those bytes runs the KAT and sanitizer gates.
`.gitattributes` marks the tree `-text` so a Windows checkout with
core.autocrlf=true can no longer rewrite LF→CRLF and break the digest (the
failure that originally forced the tarball approach).

PROVENANCE.md states the licence position exactly: 18 files carry the
upstream MIT header, four Algorand-authored deterministic-layer files carry no
header at all, and upstream has no LICENSE file (known open ask, issue #4).
Zero-patch ledger is empty and must stay empty; the tree is consumed, never
edited (constitution §0 Tier 2, §2.6).

Security Impact: no source or flag change to the signer; the compiled bytes
are identical to before (same tree, same -DFALCON_UNALIGNED=0
-fno-strict-aliasing flags). What changed is provenance: the source is now
in-tree and integrity-checked on every push, instead of fetched. Nothing to
re-verify cryptographically; the digest gate is the re-verification and it
runs in the new job and in every builder.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Stop blind-retrying inscribe() — it is a write-once on-chain call

The isolated signer could never run on Python 3.10, and blamed the Falcon build

Make --recompile work: it could never complete, and would have lied

Combines open dependabot PRs #6713, #6689, #6688, #6687 into a single
commit.

Upgrades across main module, tools/block-generator, and
tools/debug/algodump:
- github.com/labstack/echo/v4 v4.13.3 -> v4.15.3
- github.com/pion/dtls/v3 v3.1.1 -> v3.1.4
- github.com/pion/stun/v3 v3.0.0 -> v3.1.5

The pion bumps were applied to the main module as well, so all three
modules stay on matching versions.

Transitive bumps pulled in by go mod tidy:
- github.com/labstack/gommon v0.4.2 -> v0.5.0
- github.com/mattn/go-colorable v0.1.13 -> v0.1.14
- github.com/mattn/go-isatty v0.0.20 -> v0.0.22
- github.com/pion/transport/v4 v4.0.1 -> v4.0.2
- golang.org/x/time v0.12.0 -> v0.15.0