docs(v0.5-cuda): correct overclaim — Qwen3-4B run was a wrapper SMOKE TEST, not engine validation

Honest correction: the Qwen3-4B H200 run validated only the KakeyaVLLM Python
wrapper plumbing (builds vLLM, override reaches config, CUDA graphs capture,
generate returns). It is NOT validation of Kakeya Attention: Qwen3-4B has no
trained f_theta/proposer, so restoration never ran, and prompts were inside the
68-token window so nothing was evicted.

v0.5-cuda's real engine evidence is the committed gemma-4-26B KIE-v2 numbers,
which hold at recall 1.0 @ sw=68 BECAUSE gemma-4's 5/30 native full-attention
layers carry recall (S5 free lunch) — no trained f_theta/proposer needed. The
full-attention path (where restoration IS required and must be trained) is v0.6.

- report §5 rewritten as is/is-not validated
- README v0.5 note + ADR 0015 milestone reframed
- artifact relabeled as wrapper smoke test

Co-authored-by: FluffyAIcode <FluffyAIcode@users.noreply.github.com>

Author: cursoragent

README.md

@@ -390,13 +390,18 @@ H200, gemma-4-26B-A4B, recall **1.0**:
 | **Parallel inference** | bounded window on vLLM measured to **N=70** @16k (recall 1.0); eager research engine reached **N=75 @62k** (≈4.8× vLLM concurrency) |
 | **Memory saving** | gemma-4 hybrid: **~7 % @ 62k** (vLLM already bounds 25/30 layers; the 5 full layers dominate both); **~6×** edge needs a **full-attention** model + the v0.6 restoration backend |
 
-> **Honest scope.** v0.5-cuda is the **gemma-4 bounded-window** instantiation
-> (gemma-4's hybrid needs **no per-token restoration** — the S5 "free lunch" —
-> delivered via vLLM `hf_overrides`). The `KakeyaVLLM` wrapper itself was validated
-> end-to-end on an H200 (CUDA graphs captured, window applied, coherent generation,
-> 777 tok/s on Qwen3-4B — the model that fit the box). The **restoration backend**
-> (f_θ + dLLM-proposer at prefill + quantized-exact attention) for **full-attention**
-> models — the large ~6× memory differentiator — is the **v0.6** roadmap item.
+> **Honest scope.** v0.5-cuda is the **gemma-4 bounded-window** instantiation, and
+> it works **without a trained f_θ/proposer**: gemma-4's 5/30 native full-attention
+> layers carry recall, so recall is **1.0 at `sliding_window=68` with no restoration**
+> (the S5 "free lunch"), delivered via vLLM `hf_overrides`. The gemma-4 throughput /
+> concurrency / recall numbers above are the measured KIE-v2 results. The
+> `KakeyaVLLM` wrapper *plumbing* was separately smoke-tested on an H200 (builds
+> vLLM, window→config, CUDA graphs capture, generate returns) using Qwen3-4B —
+> that is a **wrapper smoke test only, not engine validation**: Qwen3 has no
+> trained f_θ/proposer, so restoration never ran. The **restoration backend** (f_θ
+> + dLLM-proposer training + quantized-exact attention) for **full-attention**
+> models — the large ~6× memory differentiator, where a bounded window *without*
+> restoration would destroy recall — is the **v0.6** roadmap item.
 
 ## v0.4 for Mac — MLX speculative-decode port (the journey to parity)
 

docs/adr/0015-kakeya-attention-and-engine-substrate.md

@@ -146,7 +146,7 @@ PR, so development context stays per-task:
 | **KIE-v1.1.z** | throughput + N=75 | **N=75 MET** (recall 1.0, 126.7 GB, ≈4.8× vLLM; int8+quant-attn). kakeyalattice v1.6.1 gemma-4 fix verified (recall 1.0). **decode ≥ vLLM NOT met**: ~31 tok/s aggregate (eager 26B-MoE forward dominates; torch.compile-attn 6.6× but 0% e2e; static-cache auto-compile segfaults). | #139 |
 | **KIE-v1.1.z2** | fused-MoE + graph-captured full-forward decode (rebuild vLLM's runtime) | **abandoned — superseded by KIE-v2** (run on vLLM instead of rebuilding it) | — |
 | **KIE-v2** | **Kakeya Attention on the vLLM runtime** (bounded window + restoration + quantized-exact as a vLLM backend) | **decode-parity MET + EXCEEDED**: gemma-4 bounded-window (sw=68) on vLLM = **195.6/231.9/539/1079 tok/s vs vLLM-default 159.3/198.6/467.5/894.9 @N=1/4/8/70, ~1.15–1.23× faster, recall 1.0** (ctx16k). Full backend (restoration + quantized-exact for full-attn models) = next. | #140 |
-| **v0.5-cuda** | **release**: package KIE-v2 as `inference_engine.engine.KakeyaVLLM` (Kakeya window on vLLM's Apache-2.0 fused-MoE + CUDA-graph + scheduler), consolidate reports, README | **done** — entrypoint validated end-to-end on H200 (CUDA graphs captured, window→vLLM config, coherent generation, 777 tok/s on Qwen3-4B); model-aware `text_config` nesting (gemma nested / Qwen flat); 13 config unit tests. Scorecard: `docs/reports/kakeya-inference-engine-v0.5-cuda.md`. | this PR |
+| **v0.5-cuda** | **release**: package KIE-v2 as `inference_engine.engine.KakeyaVLLM` (Kakeya window on vLLM's Apache-2.0 fused-MoE + CUDA-graph + scheduler), consolidate reports, README | **done (gemma-4 instantiation)** — engine evidence = committed gemma-4 KIE-v2 numbers (recall 1.0 @ sw=68 via the S5 free lunch, **no trained f_θ/proposer needed** on gemma-4). `KakeyaVLLM` wrapper **plumbing** smoke-tested on H200 (CUDA graphs captured, window→vLLM config, generate returns) on Qwen3-4B — **smoke test only, NOT engine validation** (Qwen3 has no trained f_θ/proposer → restoration never ran). Model-aware `text_config` nesting (gemma nested / Qwen flat); 13 config unit tests. Scorecard: `docs/reports/kakeya-inference-engine-v0.5-cuda.md`. | this PR |
 
 **KIE-v1.1.z2 port attempt (2026-06-16) — all clean paths blocked:**
 - **HF `kernels` hub** (lowest-surgery kernelize): `kernels` is **version-incompatible

docs/reports/kakeya-inference-engine-v0.5-cuda.md

@@ -110,23 +110,40 @@ out = engine.generate(prompts, SamplingParams(temperature=0.0, max_tokens=128))
 fused-MoE on). The pure config layer (`kakeya_hf_overrides`, `KakeyaVLLMConfig`)
 is torch/vllm-free and unit-tested (`tests/inference_engine/engine/test_kakeya_vllm.py`).
 
-## 5. Verification status
+## 5. Verification status — what is and is **not** validated
+
+**The engine claim (gemma-4) — validated, and it does NOT depend on a trained
+f_θ/proposer.**
 
 - ✅ **Throughput / concurrency / recall numbers** (gemma-4-26B) above were measured
   on H200 (Vast.ai) and committed in the KIE-v2 integration
   (`scripts/research/vllm_multitenant_parallel_bench.py --sliding-window 68`;
-  commits `7ec3a03`, `48ded1e`, `e2cf137`).
-- ✅ **`KakeyaVLLM` entrypoint validated end-to-end on H200** (vLLM 0.23.0): it builds
-  the vLLM engine with **CUDA graphs captured** (PIECEWISE + FULL), the Kakeya window
-  (68) **reaches vLLM's model config** (`hf_config.sliding_window == 68`), and
-  generation is coherent (Paris / 2+2=4 / story) at **777 tok/s** (batch 3). The
-  validation used **Qwen/Qwen3-4B** — the 26B model does not fit this box's 4 GB free
-  disk, so the wrapper *mechanism* is validated here and the 26B *performance* is the
-  committed measured path above. Evidence:
+  commits `7ec3a03`, `48ded1e`, `e2cf137`). Recall **1.0 at sliding_window=68**
+  holds on gemma-4 **because its 5/30 native full-attention layers carry recall
+  with no restoration** (the "S5 free lunch") — so this instantiation genuinely
+  needs **no trained f_θ/proposer**. That is the entire reason v0.5-cuda is a
+  gemma-4 release.
+
+**The Qwen3-4B run was a wrapper PLUMBING smoke test — NOT engine/algorithm
+validation. Read this honestly:**
+
+- ✅ It proves only the **`KakeyaVLLM` Python wrapper plumbing**: it constructs a
+  vLLM engine, the override value lands in vLLM's config
+  (`hf_config.sliding_window == 68`), CUDA graphs capture, and `generate()`
+  returns coherent text (Paris / 2+2=4 / story) at 777 tok/s. It also caught a
+  real bug (`text_config` injection crashing text-only models).
+- ❌ It does **NOT** validate Kakeya Attention on Qwen3. **Qwen3-4B has no trained
+  f_θ and no trained proposer**, so **restoration never ran** — a bounded window
+  without restoration is naive truncation, not Kakeya Attention. The test prompts
+  were also `< 68` tokens (inside the window), so **nothing was even evicted**;
+  recall/memory were not exercised at all. On a **full-attention** model,
+  window=68 without trained restoration would *destroy* recall — which is exactly
+  why the full-attention path is **v0.6 (after f_θ/proposer training)**, not v0.5.
+- Evidence (clearly labelled as a wrapper smoke test):
   `kakeya_vllm_v05_h200_validation.log`.
-- ✅ The wrapper auto-detects `text_config` nesting (multimodal gemma-4 → nested;
-  text-only Qwen/Llama → flat), fixing a crash where unconditional `text_config`
-  injection broke text-only models. Config layer unit-tested (13 tests).
+
+**Bug fix:** the wrapper auto-detects `text_config` nesting (multimodal gemma-4 →
+nested; text-only Qwen/Llama → flat). Config layer unit-tested (13 tests).
 
 ## 6. What's next (v0.6)