paper: fix protocol self-contradiction + bit-accounting inconsistencies

[FluffyAIcode]

Review findings addressed

Two internal-credibility issues flagged in review:

(1) Protocol boundaries were self-contradictory

• §5 D4 headline results run snapshot-mode, n=4 passages, boundary k=2.
• §6 E8 results run in-forward, no-boundary, n=32, 95% CI.
• But §7.2 caveat used to declare "All numbers in this paper are snapshot-mode" — directly contradicting §6.

Fix:

• §1 adds a new paragraph "Strict-GPU, live-vLLM; two measurement protocols" that declares both protocols up-front and maps each to the question it answers.
• §1 paper-structure paragraph rewritten to explicitly mark §5 as snapshot-protocol and §6 as in-forward-rigorous-protocol.
• §4 gains a new §4.4 "In-forward rigorous evaluation" subsection defining in-forward application, boundary policy (k=0 default, k=2 only where a codec is structurally undeployable at k=0), sample size (n=32, mean ± 95% CI via Student-t), and harness (benchmarks/rigorous_eval.py + frozen sha256 parity gate).
• §4.3 "Boundary-layer protection" explicitly tagged (snapshot protocol) and notes that the rigorous protocol uses k=0 by default.
• Every results-table caption now cites the protocol it was produced under: Tables 2, 3, 4, 5 tagged "snapshot-mode"; Tables 7, 8, 9 already tagged "in-forward rigorous"; Table 6 (latency) unchanged because it is a codec-isolation benchmark.
• §5 title renamed to "Main results: D4 variant, snapshot protocol" and the overview paragraph explicitly states that all tables in §5 use snapshot.
• §6 preamble explicitly links every result in §6 to "in-forward rigorous evaluation" and explains why (the E8 upgrade's practical benefit manifests under cross-layer accumulation).
• §7.2 caveat rewritten to map each protocol to the question it answers instead of falsely claiming global snapshot.

(2) Bit-accounting was inconsistent

D4 side:

• eq:bits-d4 prose said q=152 → 1056 bits.
• Table 2 reported 1088 bits at q=152.
• Table 4 footnoted "1056 exact, reported rounded to 1088".
• Appendix C reported 1088 as canonical.
• §8.6 admitted KakeyaLattice pays 3–11% more bits, but §5/§6 still called the comparison "matched bits".

E8 side:

• Abstract said E8 costs "fixed +32 bits per vector" vs D4.
• Table 7 showed +32 at q≤10 but +16 at q≥38.
• Appendix C agreed with Table 7.

Fix: distinguish exact (information-theoretic) from packed (integer-aligned deployment) bit rates everywhere.

• §3 "Bit budget" paragraph rewritten to cover both: 4·log₂(2q+1) − 1 is the per-block exact rate; ⌈·⌉ is the packed value; at q=152 this is 1056.3 exact → 1088 packed.
• §3.2 "Matched bit budget" lever updated: q_range=152 → 1056.3 bits exact, 1088 slot-packed.
• Table 4 row previously Bit cost (exact) | 1056 | 1056 (reported rounded to 1088) split into two clean rows: Bit cost (exact, Eq. (5)) | 1056.3 | 1056.3 and Bit cost (slot-packed, deployment) | — | 1088 (paired against TQ b=8 at 1056).
• §8.4 renamed "Positioning: near-matched-rate fidelity improvement" — the comparison is explicitly declared near-matched-rate, not iso-rate.
• §8.6 renamed "Near-matched rate: the 3–11% premium" with a quantitative per-q-tier premium table in prose: +11% at q=10, +4% at q=38, +3% at q=152.
• §5.1 preamble and Pareto observation Kakeya KV cache: bug fix, Gemma 4 benchmark standard, cross-model reports (4 models) #1 now explicitly say "near-matched rate, not iso-rate".

E8 cost abstract + Table 7 caption + §6 design-facts bullet + "overhead differential shrinks" parenthetical all rewritten to say:

In exact (information-theoretic) rate the E8 variant pays +D/4 = +32 bits/vector at every q_range. In packed (integer-aligned deployment) rate the gap is +32 at low q_range (parity saving still visible above the rounding floor) and +16 at high q_range (parity saving absorbed into ceiling arithmetic).

The ceiling arithmetic is shown explicitly:

• ⌈4·log₂(2q+1) − 1⌉ = 9, 13, 17, 21, 25, 29, 33 at q = 2, 5, 10, 19, 38, 76, 152 for D4.
• ⌈8·log₂(2q+1)⌉ = 19, 26, 36, 51, 67 at q = 2, 4, 10, 38, 152 for E8.

Per-vector packed cost (D=128 head, 32 bits fp16 overhead) matches Table 7 / Appendix C exactly: D4 = {320, 448, 576, 704, 832, 960, 1088} and E8 = {336, 448, 608, 848, 1104}.

Build

cd reports/paper
rm -f *.aux *.log *.out *.toc *.fls *.fdb_latexmk *.pdf
latexmk -pdf -interaction=nonstopmode -halt-on-error kakeyalattice.tex

Result: 27 pages, 433 KB (+1 page vs previous commit, from the expanded protocol + bit-accounting prose). Zero undefined references, zero LaTeX errors. Only cosmetic hyperref "Token not allowed in a PDF string (Unicode)" warnings from math-mode $D_4$ / $E_8$ in PDF-outline bookmark strings; the printed document itself is unaffected.

Section outline after fix

§1  Introduction + two-protocols paragraph + paper-structure paragraph
§2  Design philosophy: Kakeya–Brascamp–Lieb–Tropp chain
§3  The KakeyaLattice codec  (bit-budget now distinguishes exact / packed)
§4  Experimental methodology
      §4.1  Models and environment
      §4.2  Snapshot-mode capture and replace
      §4.3  Boundary-layer protection (snapshot protocol)
      §4.4  In-forward rigorous evaluation           ← NEW
      §4.5  Quality metrics
§5  Main results: D4 variant, snapshot protocol     ← title renamed
§6  Measured performance of the E8 nested lattice variant  (in-forward rigorous)
§7  Caveats  (§7.2 no longer falsely claims global snapshot)
§8  Comparison with TurboQuant
      §8.4  Positioning: near-matched-rate fidelity improvement    ← renamed
      §8.6  Near-matched rate: the 3–11% premium                   ← renamed

Files

• reports/paper/kakeyalattice.tex (329 insertions, 123 deletions)
• reports/paper/kakeyalattice.pdf (rebuilt)

No code / hook / codec / benchmark / release-artifact changes in this PR.