Runtime p3d (fast2 + dual-NoC decode matmuls): new runtime archive and image pin, re-recorded proofs, p3d evidence; p3c evidence moved to evidence/previous-p3c

README.md

@@ -28,14 +28,14 @@ All-BFP8: every text matrix (attention, MLP, LM head) is stored as TTNN `bfloat8
 
 `tensors/tensor_cache_bf16/*.tensorbin` holds the exact TTNN host tensors that the runtime uploads to device DRAM. The directory name comes from the runtime's tensor-cache writer. The files are not a regenerable cache: they are the checkpoint. Every file is hashed in the manifest, and the loader refuses to start if any file is missing or changed. The drafter (`gemma-4-12B-it-assistant/`) stores its tensors the same way. Its recorded dtype is `bfp8-lm4`: BFP8 weights and a BFP4 drafter LM head.
 
-The loader requires two proofs, both bound to the manifests:
+The loader requires two proofs, both bound to the manifests and recorded on the current runtime (p3d, see [Runtime](#runtime)):
 
 - [`gemma-4-12B-it/equivalence.json`](gemma-4-12B-it/equivalence.json): the full logits of the native reload are bit-exact to quantizing the original weights at load time, over 4,093 teacher-forced tokens (`exact_logits_equal: true`).
 - [`gemma-4-12B-it-assistant/spec_equivalence.json`](gemma-4-12B-it-assistant/spec_equivalence.json): greedy speculative decoding with draft length 5 produced token streams identical to non-speculative greedy decoding on the same proven runtime (`streams_identical: true`, 3,130 tokens compared).
 
 ## Quality versus the original BF16 model
 
-Teacher-forced comparison against the original model run in BF16 on CPU ([`evidence/quality/quant_table.json`](evidence/quality/quant_table.json)). dPPL is the perplexity change relative to BF16, top-1 is argmax agreement with BF16, and KL is the mean KL divergence on the short-prompt set:
+This table is the precision-selection study. It is a teacher-forced comparison against the original model run in BF16 on CPU, measured on the exact (unfused) TT build ([`evidence/quality/quant_table.json`](evidence/quality/quant_table.json)). For the shipped runtime's own gate, see [Runtime](#runtime). dPPL is the perplexity change relative to BF16, top-1 is argmax agreement with BF16, and KL is the mean KL divergence on the short-prompt set:
 
 | Plan | Weight read | chat dPPL / top-1 | code dPPL / top-1 | 16K book dPPL / top-1 | KL | GSM8K-50 |
 |---|---:|---:|---:|---:|---:|---:|
@@ -46,24 +46,42 @@ Teacher-forced comparison against the original model run in BF16 on CPU ([`evide
 
 **Why BFP8 and not BFP4:** with the MLP in BFP4, perplexity rises about 5% and top-1 agreement falls to about 87%. All-BFP4 is worse still. BFP8 stays within about 1–2% of BF16 perplexity.
 
-The shipped runtime adds batched speculative verification and a fused GELU×up kernel. It passed a decode-path quality gate against the exact (unfused) build ([`evidence/quality/runtime-gate-dtf-score.json`](evidence/quality/runtime-gate-dtf-score.json)): argmax agreement with the exact build was 98.8% on chat, 98.8% on code and 98.4% on long-book text. The NLL change versus the exact build was +0.0017 ± 0.0012 on chat, −0.0004 ± 0.0030 on code and −0.0061 ± 0.0096 on long-book. The two proofs above were recorded with this shipped runtime configuration.
+## Runtime
+
+The current runtime is **p3d**: image `lottolabs/gemma4-12b-tt-p150:p3d`, ID `sha256:331e79b24fa2575c436158be994c6bc0e184d776d15305e82538d2e4d646f544`. Its Gemma 4 tree is at git commit `061e48d`. On top of the earlier runtime it adds batched speculative verification, a fused GELU×up kernel, a decode KV write through a rows kernel, and dual-NoC weight reads for the decode matmuls (the TTNN in1 reader overlay, `dn` branch `efc465f`).
+
+These fast paths are numerics switches, and the proofs bind them (`runtime_env`: `GEMMA4_VERIFY_SDPA=batched`, `GEMMA4_FUSE_GELU_MUL=1`, `GEMMA4_DECODE_KV_ROWS=1`, `GEMMA4_DECODE_MM_DN=1`). They change floating-point rounding relative to the previous runtime p3c, so greedy outputs are not token-identical to p3c's. Within p3d, speculative output is identical to non-speculative output, and HTTP output is identical to the direct runtime (see below). The checkpoint tensors are byte-identical to the p3c release. Only `equivalence.json` and `spec_equivalence.json` were re-recorded on p3d.
+
+**Quality gate for p3d.** Decode-path teacher forcing was compared against the original model in BF16 on CPU ([`evidence/quality/p3d-gate/`](evidence/quality/p3d-gate/)):
+
+| Domain | Positions | dPPL vs BF16 | top-1 vs BF16 | argmax agreement with exact build |
+|---|---:|---:|---:|---:|
+| chat | 5,888 | +1.00% | 98.2% | 98.5% |
+| code | 3,328 | +0.61% | 98.7% | 98.9% |
+| long book | 2,048 | +1.15% | 96.5% | 97.9% |
+
+GSM8K-100 scored 97/100 on p3d. The exact (unfused) build and the BF16 CPU reference also scored 97/100.
+
+**Previous runtime:** p3c, image `lottolabs/gemma4-12b-tt-p150:p3c`, ID `sha256:53428e7f60a705b75b51b5166f44a912b19c3032981013fb788dd1ce9757aa73`. It was published at repo revision [`3d9001d5`](https://huggingface.co/Lottolabs/gemma-4-12B-it-TT-BFP8-P150/tree/3d9001d5f52a5f3350b90e87703440a44255bd95), and its evidence is under [`evidence/previous-p3c/`](evidence/previous-p3c/). On that runtime, HTTP decode ran at 50.6 / 49.3 / 46.9 / 45.1 / 29.7 / 21.8 tok/s at the prompt lengths in the table below. To serve p3c, use the `launch.py` from that revision; each launcher pins its own runtime image.
 
 ## Performance
 
-These numbers were measured over HTTP on one P150 with greedy decoding, 512-token outputs, chat prompts, one user and speculative decoding on ([`evidence/http-p3c/`](evidence/http-p3c/)):
+These numbers were measured on runtime p3d over HTTP on one P150 with greedy decoding, 512-token outputs, chat prompts, one user and speculative decoding on ([`evidence/http-p3d/`](evidence/http-p3d/)):
 
 | Prompt tokens | 128 | 2K | 8K | 32K | 131K | 262K (261,632) |
 |---|---:|---:|---:|---:|---:|---:|
-| Decode tok/s | 50.6 | 49.3 | 46.9 | 45.1 | 29.7 | 21.8 |
-| TTFT (s) | 0.09 | 0.64 | 3.2 | 17.0 | 124 | 395 |
+| Decode tok/s | 63.1 | 52.4 | 53.9 | 43.4 | 30.9 | 24.6 |
+| TTFT (s) | 0.09 | 0.65 | 3.2 | 17.0 | 124 | 395 |
 
-With the LocalMaxxing official prompt (a local run of the official protocol, not submitted), the server reached **49.9 output tok/s** with a **95 ms** TTFT (median of 5, 256 output tokens; [`evidence/localmaxxing/speed-test.json`](evidence/localmaxxing/speed-test.json)).
+Decode speed with speculative decoding depends on how many drafted tokens the content lets the model accept. That is why it does not fall monotonically with prompt length.
 
-## Serving correctness
+**LocalMaxxing, 2K prompt (p3d).** The server reached **53.9 output tok/s** (median of 5), 3,063 tok/s prefill and a 651 ms TTFT, with 1,996 prompt and 256 output tokens. The run was submitted as `cmuosddj10kd1lq010lf2ahkj` and approved as an unverified run ([`evidence/localmaxxing/p3d-2k/speed-test.json`](evidence/localmaxxing/p3d-2k/speed-test.json); the prompt is included).
 
-- **HTTP matches the direct runtime token for token.** All 28 of 28 checks passed ([`evidence/http-p3c/exact.json`](evidence/http-p3c/exact.json)). They cover chat and completion outputs on 10 prompts, request isolation, sampled requests followed by greedy ones, cancellation mid-prefill and mid-decode, and rejection of image input. The 512-token outputs at 32K and 261,632 prompt tokens were also identical to the direct runtime ([`evidence/http-p3c/tput_vs_direct.json`](evidence/http-p3c/tput_vs_direct.json)).
-- **Long context works to the native limit.** Passkeys at the beginning, middle and end of the prompt were retrieved at 32,768, 131,072 and 262,016 prompt tokens. A request totalling 262,145 tokens was rejected with HTTP 400 before generation started ([`evidence/http-p3c/long.json`](evidence/http-p3c/long.json)).
-- **The public package was verified end to end.** It was downloaded fresh and served on a P150 ([`evidence/public-download-verification.json`](evidence/public-download-verification.json), [`evidence/public-serving-smoke.json`](evidence/public-serving-smoke.json)).
+## Serving correctness (p3d)
+
+- **HTTP matches the direct runtime token for token.** All 28 of 28 checks passed ([`evidence/http-p3d/exact.json`](evidence/http-p3d/exact.json)). They cover chat and completion outputs on 10 prompts, request isolation, sampled requests followed by greedy ones, cancellation mid-prefill and mid-decode, and rejection of image input. The 512-token outputs at 32K and 261,632 prompt tokens were also identical to the direct runtime ([`evidence/http-p3d/tput_vs_direct.json`](evidence/http-p3d/tput_vs_direct.json)).
+- **Long context works to the native limit.** Passkeys at the beginning, middle and end of the prompt were retrieved at 32,768, 131,072 and 262,016 prompt tokens. A request totalling 262,145 tokens was rejected with HTTP 400 before generation started ([`evidence/http-p3d/long.json`](evidence/http-p3d/long.json)).
+- **The public package was verified end to end.** It was downloaded fresh, anonymously, and served on a P150 ([`evidence/public-download-verification.json`](evidence/public-download-verification.json), [`evidence/public-serving-smoke.json`](evidence/public-serving-smoke.json)).
 
 ## Download and serve
 
@@ -131,7 +149,13 @@ curl http://127.0.0.1:8000/v1/chat/completions -H 'Content-Type: application/jso
 - [`release-manifest.json`](release-manifest.json): the complete repository inventory with size and sha256 for every file.
 - [`SHA256SUMS`](SHA256SUMS): file checksums.
 - [`reproduction.json`](reproduction.json): source, runtime, serving and evidence contract.
-- [`runtime/`](runtime/): source of the runtime image layers, recorded in [`runtime/source.json`](runtime/source.json). It contains the Gemma 4 TT model tree (`runtime/gemma4/`, git commit `ce67960382fffed8550b38717cedf574e821da06`, byte-identical to the tree in the image), the vLLM/TT-plugin serving overlay, the TTNN matmul overlay, the Dockerfile chain and the build script. This is provenance: serving uses the checksum-pinned `runtime-image.tar.gz`.
+- [`runtime/`](runtime/): source of the runtime image layers, recorded in [`runtime/source.json`](runtime/source.json). It contains:
+  - the Gemma 4 TT model tree (`runtime/gemma4/`, git commit `061e48ddf6a0eab5dac1f958731fcb70768231d1`, byte-identical to the tree in the image);
+  - the TTNN overlay (`runtime/ttnn-overlay/`: 1D matmul factory and the dual-NoC in1 reader, `dn` commit `efc465f4b1a44025ae4a33e4dbc7d371b3f9266c`, byte-identical to the image);
+  - the vLLM/TT-plugin serving overlay;
+  - the Dockerfile chain (p2b → p2c → ttnn-dn1 → fast2 → p3d) and the build script.
+
+  This is provenance: serving uses the checksum-pinned `runtime-image.tar.gz`.
 - [`native_checkpoint.py`](native_checkpoint.py) and [`provenance/build_native_checkpoint.py`](provenance/build_native_checkpoint.py): the manifest, proof and verification tool, and the checkpoint builder.
 
 ## License and attribution

SHA256SUMS

@@ -1,39 +1,66 @@
 cfc7749b96f63bd31c3c42b5c471bf756814053e847c10f3eb003417bc523d30  LICENSE
-98ed9bdcd1983193f71e4d7e327eebe72a3be34c6d19e8f378aa5b7e5e370a54  README.md
-dcd509a51cd400fd48f042a8147c99df5381132386b53347b7b37a5f48b16094  evidence/http-p3c/exact.json
-67124b62e2fd13138863abda1b821e6e66e066541e572e5ec321a4b275b0e959  evidence/http-p3c/long.json
-dfc6acee93d6a341f92e453592fd2ee5b52329a229be413fa4407f7bb681c7c0  evidence/http-p3c/tput-128/requests-128-c1.json
-316fb623119a50661ae7e768c3bf8ad8733683ceb56953cdbdf2a2d963a5df9f  evidence/http-p3c/tput-128/summary.json
-44bdcbb47481b62ab615f72a2bc29c2a4d2524a4ec318f8fd19159ef4ac00c5f  evidence/http-p3c/tput-128/warmup-128.json
-fdb5caa830280f0ba36b1045a905cfeb02bee98e54d72bfa8a0f54f712ea4c20  evidence/http-p3c/tput-131072/requests-131072-c1.json
-ea4fa34dd27a8011fe1cdad7cf26f5acd3af67c0d7cab5c1dd8a3f7c680005c4  evidence/http-p3c/tput-131072/summary.json
-9aa37602c1c2ddfbe18be1c210ed50c953a20eda00f1a94b14fb3e2c249dedbd  evidence/http-p3c/tput-131072/warmup-131072.json
-d73bc532e74a494cb908c00f98f3745e465472e6fa66290b3de69ea0d673849a  evidence/http-p3c/tput-2048/requests-2048-c1.json
-b0b79e75d5f23f31261ff91863a7737dc9e0849476eac663e7577b587daa7cf8  evidence/http-p3c/tput-2048/summary.json
-abc0819a5df996ee123cba52233fc2d81c16df49fffc0c2e1bd8e934eb28333c  evidence/http-p3c/tput-2048/warmup-2048.json
-e211831e0530c7b1cd1aa356a95beaec3a2215a7fe77d9908e858b9f3b453c05  evidence/http-p3c/tput-261632/requests-261632-c1.json
-9ebdbacd8886c3faf8e2753fb010cd2a87d00d3da3a085051b9663265b6bcff5  evidence/http-p3c/tput-261632/summary.json
-94a93fe15d162528cb287df6f4ff7f95244e05ea8cfaae89076b4b518eaf39d4  evidence/http-p3c/tput-261632/warmup-261632.json
-37e1fc84216f03c5db76d35995054e367adc55c4fa6f2892dabb61ed6be1c12b  evidence/http-p3c/tput-32768/requests-32768-c1.json
-6862ec9e00ddad920c0324a442ee5d28737a2e839de8e89c693c0cd809df1774  evidence/http-p3c/tput-32768/summary.json
-e4f3cc40e54e56410341d29bd26d9102f06dbd00e35901c4a05b2a05f085c3bd  evidence/http-p3c/tput-32768/warmup-32768.json
-e67e8fbe22e47880715b26cee62f0d999a6395388d36774117c880f6ff6e4842  evidence/http-p3c/tput-8192/requests-8192-c1.json
-af278ee14869619894a8ff9a4c12c69f155d35c26f3b7868190d9559ec001981  evidence/http-p3c/tput-8192/summary.json
-957010a8c724f2a1f82ce7ffc5dcbdabfeb2e1420c5a9274fda0faa8c85c05bb  evidence/http-p3c/tput-8192/warmup-8192.json
-1c7778066e729cf8e2f302418c63f1640eba7d88a6b943b9681f3819c1579adb  evidence/http-p3c/tput_vs_direct.json
-f03041863057e793e816ded6f048899034e04f11a3a4dd0fd102a04d40e7b5de  evidence/localmaxxing/speed-test.json
-92c92f98fb43b89ff04bd970974f23a3647264a722da2e674b033cf0d8523a32  evidence/public-download-verification.json
-791d5b2dff0a130024200ab016e671c1d74495229b3461f83464bb35124478a9  evidence/public-serving-smoke.json
-07b8133a548b886bc30794b9f984f0a5dee9b9301f7c90ff671806cbb4ce766c  evidence/public-serving-smoke/requests-2048-c1.json
-a386aef5e382c304cc3c5315b8021166dfadec3d256b6af7887acf35383262e2  evidence/public-serving-smoke/summary.json
-3cb6e6002631824144551034aeed233081c44182771b51d8c3ade48555ff7426  evidence/public-serving-smoke/warmup-2048.json
+fb17f137237deb11b801ab11ca09a446b02e6a35c9a278f294daee9a82faedfb  README.md
+2d2a52c8c9dab817a10c4bec4c9d483ee1214b3a22cc883fb754549dac8dbf0e  evidence/http-p3d/exact.json
+4ae89585c639211abecfb7347a476c18d43f809385b0eb2a8077d3e994e80c8e  evidence/http-p3d/long.json
+534ef3c7105f7f2d8fc7e0bad4836b6d5507139c0a18a0b97377d4a8051ba035  evidence/http-p3d/tput-128/requests-128-c1.json
+4d213e69b02e4b71062c358b3cda4a8db94a615b43c16f3dfd619c053788dac6  evidence/http-p3d/tput-128/summary.json
+7a94e4f69a9e5ac6de2d96cd7eb9647fda3c50ba406cdaa2c68bba7aba5c74ad  evidence/http-p3d/tput-128/warmup-128.json
+2bbf64804564dfaf71c0f5b78db64db026eaf16ab5d515125e295f145c137548  evidence/http-p3d/tput-131072/requests-131072-c1.json
+3b5fc67ff3e95a6ba8fc59f721fb79ba6df82993af27b8f6b1ef280cdd134ddf  evidence/http-p3d/tput-131072/summary.json
+3b0071bad4dda913079bd8d853d419220e5c6cb58b34618f3059d3e4c305d0a4  evidence/http-p3d/tput-131072/warmup-131072.json
+2f6176f102977e953ddd33a8d938fe0cbf1661c1466a287e406c2f1ac7215174  evidence/http-p3d/tput-2048/requests-2048-c1.json
+4206f0885321e0cd121e2efbbb91daf2c87bb3343081e81709fb2f80b9d7fcb0  evidence/http-p3d/tput-2048/summary.json
+cc417c28c2a3952197e27e516b10c358665bd9792ef1cebb990de8037287292f  evidence/http-p3d/tput-2048/warmup-2048.json
+1cfdf00f237dccc9e9ddfed7d0f64f224f574b048d5b395edb0f81ced7a0dfdb  evidence/http-p3d/tput-261632/requests-261632-c1.json
+bad5d6e144e98944b706ad12b62017d4355f4148b3ff2d6ee72543f3cefe72c8  evidence/http-p3d/tput-261632/summary.json
+c6a74eafe2f81e64b185d4327d79ca49bcc52f52a9572d353d55cf054656c196  evidence/http-p3d/tput-261632/warmup-261632.json
+91e11398058527c1d04f3911de6218b2f3f183dfadd3977280e738dd59907aa2  evidence/http-p3d/tput-32768/requests-32768-c1.json
+89effe9fecb4560388df68a68cba91117c9861f68be7991c3f89773c1e515117  evidence/http-p3d/tput-32768/summary.json
+7de3bc8246a36dfcd42b9802f4312874fa5a4919f93c01552326727bcb14b3e3  evidence/http-p3d/tput-32768/warmup-32768.json
+7aa5cf9a79ccd791f80a4ddb1350d3da0ecc7a14901a4cee7ec81df8e2fc1fa3  evidence/http-p3d/tput-8192/requests-8192-c1.json
+2657f8971531b9f9bb940856f83740aebf1fdd7f1c6f313356ad13c102b54ac3  evidence/http-p3d/tput-8192/summary.json
+5df2100d05536b268b8a811e814d66628320eca6016f7968d46f9747eeba74a1  evidence/http-p3d/tput-8192/warmup-8192.json
+1c7778066e729cf8e2f302418c63f1640eba7d88a6b943b9681f3819c1579adb  evidence/http-p3d/tput_vs_direct.json
+cd754ee70eca7fe4db4c243e6ca985e46e46dd89157735b8ebadd92dafcff4a1  evidence/localmaxxing/p3d-2k/prompt-2k.txt
+e341a88dd41612504017df8c950b3670d8dc01b057887f697a8b761dd8a32106  evidence/localmaxxing/p3d-2k/speed-test.json
+dcd509a51cd400fd48f042a8147c99df5381132386b53347b7b37a5f48b16094  evidence/previous-p3c/http/exact.json
+67124b62e2fd13138863abda1b821e6e66e066541e572e5ec321a4b275b0e959  evidence/previous-p3c/http/long.json
+dfc6acee93d6a341f92e453592fd2ee5b52329a229be413fa4407f7bb681c7c0  evidence/previous-p3c/http/tput-128/requests-128-c1.json
+316fb623119a50661ae7e768c3bf8ad8733683ceb56953cdbdf2a2d963a5df9f  evidence/previous-p3c/http/tput-128/summary.json
+44bdcbb47481b62ab615f72a2bc29c2a4d2524a4ec318f8fd19159ef4ac00c5f  evidence/previous-p3c/http/tput-128/warmup-128.json
+fdb5caa830280f0ba36b1045a905cfeb02bee98e54d72bfa8a0f54f712ea4c20  evidence/previous-p3c/http/tput-131072/requests-131072-c1.json
+ea4fa34dd27a8011fe1cdad7cf26f5acd3af67c0d7cab5c1dd8a3f7c680005c4  evidence/previous-p3c/http/tput-131072/summary.json
+9aa37602c1c2ddfbe18be1c210ed50c953a20eda00f1a94b14fb3e2c249dedbd  evidence/previous-p3c/http/tput-131072/warmup-131072.json
+d73bc532e74a494cb908c00f98f3745e465472e6fa66290b3de69ea0d673849a  evidence/previous-p3c/http/tput-2048/requests-2048-c1.json
+b0b79e75d5f23f31261ff91863a7737dc9e0849476eac663e7577b587daa7cf8  evidence/previous-p3c/http/tput-2048/summary.json
+abc0819a5df996ee123cba52233fc2d81c16df49fffc0c2e1bd8e934eb28333c  evidence/previous-p3c/http/tput-2048/warmup-2048.json
+e211831e0530c7b1cd1aa356a95beaec3a2215a7fe77d9908e858b9f3b453c05  evidence/previous-p3c/http/tput-261632/requests-261632-c1.json
+9ebdbacd8886c3faf8e2753fb010cd2a87d00d3da3a085051b9663265b6bcff5  evidence/previous-p3c/http/tput-261632/summary.json
+94a93fe15d162528cb287df6f4ff7f95244e05ea8cfaae89076b4b518eaf39d4  evidence/previous-p3c/http/tput-261632/warmup-261632.json
+37e1fc84216f03c5db76d35995054e367adc55c4fa6f2892dabb61ed6be1c12b  evidence/previous-p3c/http/tput-32768/requests-32768-c1.json
+6862ec9e00ddad920c0324a442ee5d28737a2e839de8e89c693c0cd809df1774  evidence/previous-p3c/http/tput-32768/summary.json
+e4f3cc40e54e56410341d29bd26d9102f06dbd00e35901c4a05b2a05f085c3bd  evidence/previous-p3c/http/tput-32768/warmup-32768.json
+e67e8fbe22e47880715b26cee62f0d999a6395388d36774117c880f6ff6e4842  evidence/previous-p3c/http/tput-8192/requests-8192-c1.json
+af278ee14869619894a8ff9a4c12c69f155d35c26f3b7868190d9559ec001981  evidence/previous-p3c/http/tput-8192/summary.json
+957010a8c724f2a1f82ce7ffc5dcbdabfeb2e1420c5a9274fda0faa8c85c05bb  evidence/previous-p3c/http/tput-8192/warmup-8192.json
+1c7778066e729cf8e2f302418c63f1640eba7d88a6b943b9681f3819c1579adb  evidence/previous-p3c/http/tput_vs_direct.json
+f03041863057e793e816ded6f048899034e04f11a3a4dd0fd102a04d40e7b5de  evidence/previous-p3c/localmaxxing-speed-test.json
+92c92f98fb43b89ff04bd970974f23a3647264a722da2e674b033cf0d8523a32  evidence/previous-p3c/public-download-verification.json
+791d5b2dff0a130024200ab016e671c1d74495229b3461f83464bb35124478a9  evidence/previous-p3c/public-serving-smoke.json
+07b8133a548b886bc30794b9f984f0a5dee9b9301f7c90ff671806cbb4ce766c  evidence/previous-p3c/public-serving-smoke/requests-2048-c1.json
+a386aef5e382c304cc3c5315b8021166dfadec3d256b6af7887acf35383262e2  evidence/previous-p3c/public-serving-smoke/summary.json
+3cb6e6002631824144551034aeed233081c44182771b51d8c3ade48555ff7426  evidence/previous-p3c/public-serving-smoke/warmup-2048.json
+b118bf712e7d70058213f378920c0b129a2366b554f23d489c441ecbb2e5f2ba  evidence/previous-p3c/runtime-gate-dtf-score.json
+156ecb1746f24b3c6c7d6143e74034caf533b286270baab8f9bb7ad117fc8750  evidence/quality/p3d-gate/book-2048-score.json
+51c580756dd62962bcad40d1cf53100319f8d9615902f2a5db24f78af42f510a  evidence/quality/p3d-gate/dtf-score.json
+9bb6af5e16abd148f7b7d528e045587bec96b94249a89be227352840257fb703  evidence/quality/p3d-gate/gsm8k-100-exact-build.json
+82c012ee2d4dd6f5986f7a7bbbec425589405c98e487b93747457b0180e220ab  evidence/quality/p3d-gate/gsm8k-100.json
 32904d8e6be2daea2b797cc71b8d587e06605dc23421d96e1912c8593ed4b991  evidence/quality/quant_table.json
-b118bf712e7d70058213f378920c0b129a2366b554f23d489c441ecbb2e5f2ba  evidence/quality/runtime-gate-dtf-score.json
 b6f19209588fcefe41f65b193fad6148446253c470d36e29441ecc5158a54e6d  gemma-4-12B-it-assistant/config.json
 2db4559e6ec51d81a7cd51b003743ca689fed5220d41b6a403b8d6947e1c74b7  gemma-4-12B-it-assistant/drafter_manifest.json
 02b56bd11e1cd1e363e701a85a2fd7fbaa2992ec3358c1cd7cc44ead7208f505  gemma-4-12B-it-assistant/generation_config.json
 3279c173daddd7186e79d652ad94022415736d3a1370625696c898429b06d6df  gemma-4-12B-it-assistant/model.safetensors
-032cc468d6bf33bca7267be0e70d1d6932e7dcc4dfb97acb5a75e736f2ee8d0d  gemma-4-12B-it-assistant/spec_equivalence.json
+1c09aae0f94d18ae7075800ccf55a7866769bec1fe41475ec781c054ad4ee489  gemma-4-12B-it-assistant/spec_equivalence.json
 70eb60efff28b3606bbc91b35a3311e7b4ccae3b70e0f3787c9c0b32cc4ebf3c  gemma-4-12B-it-assistant/tensors/assistant_tensor_cache_bfp8/final_norm/weight_dtype_BFLOAT16_layout_ROW_MAJOR.tensorbin
 1179fa4a06ab8e4bae470dce5c4848d5b3b5eca1a3c87d8a02001bfb1aacf02f  gemma-4-12B-it-assistant/tensors/assistant_tensor_cache_bfp8/layer_0/layer_0/input_layernorm/weight_dtype_BFLOAT16_layout_ROW_MAJOR.tensorbin
 bc68d0c960e2782993ff0d354800e3f4d67dd80d1b31f0775dc5574114402787  gemma-4-12B-it-assistant/tensors/assistant_tensor_cache_bfp8/layer_0/layer_0/mlp/down_proj.weight_bfp8_dtype_BFLOAT8_B_layout_TILE.tensorbin
@@ -84,7 +111,7 @@ a926c8853869f484c379a9d5b3397488c04905b15d90082ac679ecf7e6466479  gemma-4-12B-it
 ba02924ee433b4f9689d504ddadc0e3247d23972021668dc03bd9e27c17670dc  gemma-4-12B-it-assistant/tensors/assistant_tensor_cache_bfp8/pre_projection_weight_dtype_BFLOAT8_B_layout_TILE.tensorbin
 ae53464bf3be25802b3a5b37def7fd89667067d7577049b3b2d74c4d8de4c6d4  gemma-4-12B-it/chat_template.jinja
 478c46e8d2c52d5c2d85bf67e3b3e8c90e7c9d91086cee27e3c267907e936bd9  gemma-4-12B-it/config.json
-1bd70995c42ce9d484c717d4169a000df36ce5181798c6f54b26138128daf296  gemma-4-12B-it/equivalence.json
+824b1705373431eb0a79dd3774eaf1890a1849cc1de06375b1506a2f2073abd2  gemma-4-12B-it/equivalence.json
 a8349d9bd64cc5841297fcb5002f0fdc4749c473c8f1b10ea337f9ce4ee7014e  gemma-4-12B-it/generation_config.json
 007d9f3da8d54363a75e8af84cf0c9b762eafd6edf23679de48b08c62d584d55  gemma-4-12B-it/native_manifest.json
 612f5da6a29a50dea769db21923d2bd7b828a94f2f25cc41f28a33abac9cb990  gemma-4-12B-it/precision_plan.json
@@ -622,17 +649,18 @@ e5656d7f88172fb4add6d5969a1c15d5d50f0eb3c5e0223a448c90816ec43e8e  gemma-4-12B-it
 dfeaed45d94523cd991122388b8ca2e0cbeeb5fe34d3d3b37c047c26bfc715e3  gemma-4-12B-it/tensors/tensor_cache_bf16/lm_head.weight_bfp8_dtype_BFLOAT8_B_layout_TILE.tensorbin
 cc8d3a0ce36466ccc1278bf987df5f71db1719b9ca6b4118264f45cb627bfe0f  gemma-4-12B-it/tokenizer.json
 a62f4e85a47c0c136edaaa3a4f591fd6783717299a9def47e5ad03a49f6a5eb9  gemma-4-12B-it/tokenizer_config.json
-dd9ce6c7f2776f93acd7091dcd7c60eb0460a7d18e8c655e44e11846fc5d5df6  launch.py
+22186ea9c0c9fb94823f666c740555459728d5750278315ac2ab364ccbb4cbfb  launch.py
 cc507fe91c3279813aa4bdf697e7a2a811d5f67ea25afe90206830ec4c3db9cd  native_checkpoint.py
 3aa234a04e768e734a8ede9cdd9da1716366b06ea47b22a5ca466a49ad4fb56f  provenance/build_native_checkpoint.py
-1d0b9b438090dbbc63e1e40d5ef8e5a2cd0c5d8f91356d1d21c08db7bb4dea08  release-manifest.json
-30578daa4ad6a0e529ac99470c5131c7738ed2a60e70fbaedb32ac0de5736d0a  reproduction.json
-782cab35025b19b55fe2212a2619cd97dfd5f6da6c04a00e68b9c69a8f92d2dd  runtime-image.tar.gz
-48fdc1e0b7cb088fcd12c56de79300f90cb6a5a79a49e029f3ec6deec565b66a  runtime-release.json
-d9e47832fb3354959883d3069a9f1c7e2cc8be0a6e2b9d37f22c36c154749fdd  runtime/Dockerfile.fast1
+8d60ffcd6654cce863901b4f0a5f0d5fc25b46d0fa65c58911a1832486460f04  release-manifest.json
+2f916687347fd9b47ddb7dc18585a80a7285aacf4bb727db4fe8b52218d203fa  reproduction.json
+59074c4431d616cd56e0a001684f320825cb3f5ade7d16d6e3e58667d127e6ce  runtime-image.tar.gz
+7d4c57f97b7ab4f2f353b4e4dffcd56899b24e73a459d5fc14578aaf48ae59e9  runtime-release.json
+b99769e8cd55f06640377a142de2199d0a2cda7830081cab5a1974c15915d14d  runtime/Dockerfile.fast2
 46eb8d5cca3549b243d6014e9aa6eca8e1d7ac940c32d423f480eca69b96290c  runtime/Dockerfile.p2b
 91fdd9a2cae0bffb6715422bfda322e47e9b05d40d99e3a6cc962aba89132b9e  runtime/Dockerfile.p2c
-abaee1bb49548bf7b8abebe6519e68d9d7bc3fa9e86e3ef76f1ea9a86e64337c  runtime/Dockerfile.p3c
+70c93a67b96223c1f0bcfdee039ba1ffb2e17ed1725678d9bad98fb1dd19ee18  runtime/Dockerfile.p3d
+005744b93e3b95864bd6152c3084226c448b48aa124311855fa4896dbfaa6fe6  runtime/Dockerfile.ttnn-dn1
 93ce271364dd8bac7ccd0e01e1d20fa3f950ce279ca076b6a272ee3ea039073a  runtime/build.sh
 8a8a3b18e19e275cd5039ea176d0931a6a5f3797985472c8d03366613b99ecc2  runtime/gemma4/README.md
 501d5b563ca412fa21db82bf39117b5480ecf99bcaf11996b9c3d5f1093bb9a8  runtime/gemma4/__init__.py
@@ -679,15 +707,15 @@ adbf13ab702a97058e31b3822d2bede9aac7f76dd109c86286061e2522f4e392  runtime/gemma4
 0e3247c34a359a73bd4c8ecc7365e028372084554eeeba41682d1fd818c296af  runtime/gemma4/tt/assistant/model.py
 df24b2bf4311ffaee781692ff8f465dea0f415e2323cf87fba4ce22227edb8ae  runtime/gemma4/tt/attention/__init__.py
 01b0f3e14c31aae5ed01104aee7f4cb03913007c0d0018f9d35d341d3fe049ef  runtime/gemma4/tt/attention/config.py
-0ec303ff75ded2a03f773c22aba27c719e2f055c71b9560fe18661d0272fd3db  runtime/gemma4/tt/attention/decode.py
+df1f33dce05739d867ff0f4f11facabfa5625818118d8cf4d5fc8e97df36c4ac  runtime/gemma4/tt/attention/decode.py
 3a1e9f520cdde61dd49550dbfca1072d009ee34878bafe5923c655821c09bff7  runtime/gemma4/tt/attention/kv_cache.py
 9074a2d1de4b3a65d11271370f1fce39a78e5523b841752bcaa87dccb4b56470  runtime/gemma4/tt/attention/kv_cache_hybrid.py
-f5cda2ade4031a66e631a732199f3b4b9a00b45ef2e252aee0d3138406bbcc43  runtime/gemma4/tt/attention/operations.py
+8e87380345b46db028f882df1df2ea05b59a4e0278ed8516a1f15b9663384a65  runtime/gemma4/tt/attention/operations.py
 32c6e1c9423b9c22f14558c33d76d9164cb8a27c939cb5d1ccb6da039b7c831f  runtime/gemma4/tt/attention/prefill.py
 3ec94d60c6d1085bed0bf83fbc450aa9599a476341d3c6d77466b1b2e17c00d6  runtime/gemma4/tt/attention/weights.py
 3580f2e25950381465e55dd2886d2832c33d8d6fc618b5a2b94088d0b1a91105  runtime/gemma4/tt/ccl.py
 e4369b067c3c2e7930fb538a34ab04b237940048e771f2f8f0560776f03a578f  runtime/gemma4/tt/common.py
-93ebedf2eb3b0c78ebbddfc00c630b13c726d9b13bb07fb53a073a207731bae4  runtime/gemma4/tt/decode_mm.py
+85e5a625134c36925d559c4b7557b0139e824a77c4e724bf3b647015b77f7fac  runtime/gemma4/tt/decode_mm.py
 567aef533a30a692e4c0b28695c15d13e2cfc024ee621e4147c836b63220d5c3  runtime/gemma4/tt/experts/__init__.py
 80bd7d18ffd0e0b6bd969d05a8e9972ff8473dc63631f1cb6de0bd619a50f33b  runtime/gemma4/tt/experts/config.py
 112b9df4b88e8395053fdbf69315e3a43e9f3f4877e699ca5a48462ccd8e804b  runtime/gemma4/tt/experts/decode.py
@@ -727,9 +755,11 @@ fb0ab8fe2667f410bbe1afa8f09d3a3bbd2d159908d39ceccc4dd07068ccbd05  runtime/servin
 0925cd2054f881f59625c2cc31ddb8a8f7dc29a661acf720f303a2cb50366705  runtime/serving-overlay/home/container_app_user/vllm/vllm/config/speculative.py
 d0ab1698eab1d59203c777555e4457a6e11b3d141c898ffe2befcf8b972dbf65  runtime/serving-overlay/home/container_app_user/vllm/vllm/v1/engine/detokenizer.py
 e7e004902362d832cfea5f4e22eedcc530494c3e42ea1e720159712ae6d8e1d3  runtime/serving-overlay/home/container_app_user/vllm/vllm/v1/engine/output_processor.py
-03bfbc377872223a5aa72bee2148b941831969065e9241aa5dedd0d8ddb36c61  runtime/source.json
+dc0a865c919aecaee44bc113cced7f3be2d64172505f0a5c5fc166dcd8fb57f6  runtime/source.json
 288c44040187729651e90de21e4d270750eda3d05be109a699404327738e8e4a  runtime/tools/compare_gen.py
 cc507fe91c3279813aa4bdf697e7a2a811d5f67ea25afe90206830ec4c3db9cd  runtime/tools/native_checkpoint.py
-36485b68752f51c3642e3dd777f5da0cdb9de61ab819d5680f95402e1a24ede3  runtime/tools/tt_eval.py
-1de00fc9d9d9ca537d7a90af22dd61b4723c54b6ecd236f7053124963789a62b  runtime/ttnn-overlay/cpp/ttnn/operations/matmul/device/factory/matmul_multicore_reuse_mcast_1d_program_factory.cpp
+505baaad9c88ccfb2e4f264f557477b30ae066673837b6c7fe56f0dc197f0934  runtime/tools/tt_eval.py
+fa967085d4bccc78e448454911c38468415c1403e3138e11dbbf9d176ffd3c67  runtime/ttnn-overlay/cpp/ttnn/operations/matmul/device/factory/matmul_multicore_reuse_mcast_1d_program_factory.cpp
+a78857488315cac5257d5e8a93f03800bbf40acb528ba0edd0ad67660a2cbad1  runtime/ttnn-overlay/cpp/ttnn/operations/matmul/device/kernels/dataflow/reader_bmm_tile_layout_in0_sender_padding.cpp
+3620262683632718607446e2a8eba75ea74cd714eee00886d3b2a00ad4f08dc4  runtime/ttnn-overlay/cpp/ttnn/operations/matmul/device/kernels/dataflow/reader_bmm_tile_layout_in1_sender_writer_padding.cpp
 a9ae81f0f28d1f5c7c093817485cd72d28df4072714a1a30672c43e0166a88d9  serve_native.py

evidence/http-p3d/exact.json

@@ -0,0 +1,185 @@
+{
+ "checks": [
+  {
+   "name": "health",
+   "ok": true
+  },
+  {
+   "name": "chat_exact_story",
+   "ok": true,
+   "n": 250,
+   "ref_n": 250,
+   "finish": "stop",
+   "events": 110,
+   "first_divergence": null
+  },
+  {
+   "name": "chat_exact_explain",
+   "ok": true,
+   "n": 320,
+   "ref_n": 320,
+   "finish": "length",
+   "events": 107,
+   "first_divergence": null
+  },
+  {
+   "name": "chat_exact_code",
+   "ok": true,
+   "n": 320,
+   "ref_n": 320,
+   "finish": "length",
+   "events": 86,
+   "first_divergence": null
+  },
+  {
+   "name": "chat_exact_math",
+   "ok": true,
+   "n": 320,
+   "ref_n": 320,
+   "finish": "length",
+   "events": 67,
+   "first_divergence": null
+  },
+  {
+   "name": "chat_exact_logic",
+   "ok": true,
+   "n": 320,
+   "ref_n": 320,
+   "finish": "length",
+   "events": 94,
+   "first_divergence": null
+  },
+  {
+   "name": "chat_exact_code-lru",
+   "ok": true,
+   "n": 320,
+   "ref_n": 320,
+   "finish": "length",
+   "events": 86,
+   "first_divergence": null
+  },
+  {
+   "name": "chat_exact_code-c",
+   "ok": true,
+   "n": 320,
+   "ref_n": 320,
+   "finish": "length",
+   "events": 74,
+   "first_divergence": null
+  },
+  {
+   "name": "chat_exact_code-sql",
+   "ok": true,
+   "n": 320,
+   "ref_n": 320,
+   "finish": "length",
+   "events": 91,
+   "first_divergence": null
+  },
+  {
+   "name": "chat_exact_long-summary",
+   "ok": true,
+   "n": 320,
+   "ref_n": 320,
+   "finish": "length",
+   "events": 115,
+   "first_divergence": null
+  },
+  {
+   "name": "chat_exact_long-code",
+   "ok": true,
+   "n": 320,
+   "ref_n": 320,
+   "finish": "length",
+   "events": 106,
+   "first_divergence": null
+  },
+  {
+   "name": "completion_exact_story",
+   "ok": true,
+   "n": 250
+  },
+  {
+   "name": "completion_exact_explain",
+   "ok": true,
+   "n": 320
+  },
+  {
+   "name": "completion_exact_code",
+   "ok": true,
+   "n": 320
+  },
+  {
+   "name": "completion_exact_math",
+   "ok": true,
+   "n": 320
+  },
+  {
+   "name": "completion_exact_logic",
+   "ok": true,
+   "n": 320
+  },
+  {
+   "name": "completion_exact_code-lru",
+   "ok": true,
+   "n": 320
+  },
+  {
+   "name": "completion_exact_code-c",
+   "ok": true,
+   "n": 320
+  },
+  {
+   "name": "completion_exact_code-sql",
+   "ok": true,
+   "n": 320
+  },
+  {
+   "name": "completion_exact_long-summary",
+   "ok": true,
+   "n": 320
+  },
+  {
+   "name": "completion_exact_long-code",
+   "ok": true,
+   "n": 320
+  },
+  {
+   "name": "isolation_ABA",
+   "ok": true,
+   "n": 128
+  },
+  {
+   "name": "sampled_request",
+   "ok": true,
+   "n": 64
+  },
+  {
+   "name": "greedy_after_sampled",
+   "ok": true
+  },
+  {
+   "name": "cancel_mid_decode",
+   "ok": true,
+   "cancelled_after": 42,
+   "next_request_s": 2.9789515789889265
+  },
+  {
+   "name": "cancel_mid_prefill",
+   "ok": true,
+   "cancelled_after_s": 8.169508557009976,
+   "next_request_s": 11.751794009993318
+  },
+  {
+   "name": "image_rejected",
+   "ok": true,
+   "status": 400,
+   "body": "{\"error\":{\"message\":\"/model is not a multimodal model\",\"type\":\"BadRequestError\",\"param\":null,\"code\":400}}"
+  },
+  {
+   "name": "health_end",
+   "ok": true
+  }
+ ],
+ "exact_seconds": 100.73274602601305
+}

evidence/http-p3d/long.json

@@ -0,0 +1,231 @@
+[
+  {
+    "name": "configuration",
+    "url": "http://127.0.0.1:8000",
+    "model": "google/gemma-4-12B-it",
+    "contexts": [
+      32768,
+      131072,
+      262016
+    ],
+    "tokens": 128,
+    "native_max_len": 262144,
+    "request_timeout_seconds": 3600,
+    "cases": [
+      {
+        "input_tokens": 32768,
+        "output_tokens": 128
+      },
+      {
+        "input_tokens": 131072,
+        "output_tokens": 128
+      },
+      {
+        "input_tokens": 262016,
+        "output_tokens": 128
+      }
+    ],
+    "begin_key_token_region": [
+      0,
+      43
+    ],
+    "end_key_suffix_tokens": 65,
+    "timing_basis": "Client first/last non-empty SSE text arrival; MTP may emit multiple tokens per event"
+  },
+  {
+    "name": "short_before",
+    "input_tokens": 25,
+    "requested_output_tokens": 32,
+    "requested_total_tokens": 57,
+    "ttft_seconds": 0.09304460400016978,
+    "decode_wall_seconds": 0.04858210598467849,
+    "seconds": 0.18983703898265958,
+    "decode_tokens_per_second": 144.08597276963692,
+    "finish_reason": "stop",
+    "sse_done": true,
+    "response": {
+      "text": "The capital of France is Paris.",
+      "usage": {
+        "prompt_tokens": 25,
+        "total_tokens": 33,
+        "completion_tokens": 8
+      }
+    },
+    "expected_keys": {
+      "known_answer": "Paris"
+    },
+    "retrieved_keys": {
+      "known_answer": true
+    },
+    "accuracy": true
+  },
+  {
+    "name": "layout_32768",
+    "input_tokens": 32768,
+    "begin_key_offset": 35,
+    "middle_key_offset": 16021,
+    "end_key_offset": 32707
+  },
+  {
+    "name": "stream_32768_128",
+    "input_tokens": 32768,
+    "requested_output_tokens": 128,
+    "requested_total_tokens": 32896,
+    "ttft_seconds": 16.924654099013424,
+    "decode_wall_seconds": 0.43388441897695884,
+    "seconds": 17.35861225798726,
+    "decode_tokens_per_second": 78.36188282623154,
+    "finish_reason": "stop",
+    "sse_done": true,
+    "response": {
+      "text": "CEDAR-7419-QUARTZ\nHARBOR-5096-VIOLET\nORBIT-2863-MARBLE",
+      "usage": {
+        "prompt_tokens": 32768,
+        "total_tokens": 32803,
+        "completion_tokens": 35
+      }
+    },
+    "expected_keys": {
+      "begin": "CEDAR-7419-QUARTZ",
+      "middle": "HARBOR-5096-VIOLET",
+      "end": "ORBIT-2863-MARBLE"
+    },
+    "retrieved_keys": {
+      "begin": true,
+      "middle": true,
+      "end": true
+    },
+    "accuracy": true
+  },
+  {
+    "name": "layout_131072",
+    "input_tokens": 131072,
+    "begin_key_offset": 35,
+    "middle_key_offset": 65832,
+    "end_key_offset": 131011
+  },
+  {
+    "name": "stream_131072_128",
+    "input_tokens": 131072,
+    "requested_output_tokens": 128,
+    "requested_total_tokens": 131200,
+    "ttft_seconds": 123.8322498589987,
+    "decode_wall_seconds": 0.5941902149934322,
+    "seconds": 124.42653353299829,
+    "decode_tokens_per_second": 57.22073360022567,
+    "finish_reason": "stop",
+    "sse_done": true,
+    "response": {
+      "text": "CEDAR-7419-QUARTZ\nHARBOR-5096-VIOLET\nORBIT-2863-MARBLE",
+      "usage": {
+        "prompt_tokens": 131072,
+        "total_tokens": 131107,
+        "completion_tokens": 35
+      }
+    },
+    "expected_keys": {
+      "begin": "CEDAR-7419-QUARTZ",
+      "middle": "HARBOR-5096-VIOLET",
+      "end": "ORBIT-2863-MARBLE"
+    },
+    "retrieved_keys": {
+      "begin": true,
+      "middle": true,
+      "end": true
+    },
+    "accuracy": true
+  },
+  {
+    "name": "layout_262016",
+    "input_tokens": 262016,
+    "begin_key_offset": 35,
+    "middle_key_offset": 130632,
+    "end_key_offset": 261955
+  },
+  {
+    "name": "stream_262016_128",
+    "input_tokens": 262016,
+    "requested_output_tokens": 128,
+    "requested_total_tokens": 262144,
+    "ttft_seconds": 394.9077806400019,
+    "decode_wall_seconds": 0.9461079349857755,
+    "seconds": 395.9787403039809,
+    "decode_tokens_per_second": 35.9367031421327,
+    "finish_reason": "stop",
+    "sse_done": true,
+    "response": {
+      "text": "CEDAR-7419-QUARTZ\nHARBOR-5096-VIOLET\nORBIT-2863-MARBLE",
+      "usage": {
+        "prompt_tokens": 262016,
+        "total_tokens": 262051,
+        "completion_tokens": 35
+      }
+    },
+    "expected_keys": {
+      "begin": "CEDAR-7419-QUARTZ",
+      "middle": "HARBOR-5096-VIOLET",
+      "end": "ORBIT-2863-MARBLE"
+    },
+    "retrieved_keys": {
+      "begin": true,
+      "middle": true,
+      "end": true
+    },
+    "accuracy": true
+  },
+  {
+    "name": "native_overflow_rejection",
+    "input_tokens": 262016,
+    "requested_output_tokens": 129,
+    "requested_total_tokens": 262145,
+    "native_max_len": 262144,
+    "status": 400,
+    "seconds": 0.014746526983799413,
+    "rejected_before_generation": true,
+    "response": {
+      "error": {
+        "message": "You passed 262016 input tokens and requested 129 output tokens. However, the model's context length is only 262144 tokens, resulting in a maximum input length of 262015 tokens. Please reduce the length of the input prompt. (parameter=input_tokens, value=262016)",
+        "type": "BadRequestError",
+        "param": "input_tokens",
+        "code": 400
+      }
+    }
+  },
+  {
+    "name": "mtp_acceptance",
+    "accepted_tokens_before": 10881.0,
+    "accepted_tokens_after": 10962.0,
+    "accepted_tokens_delta": 81.0
+  },
+  {
+    "name": "short_after",
+    "input_tokens": 25,
+    "requested_output_tokens": 32,
+    "requested_total_tokens": 57,
+    "ttft_seconds": 0.09321309201186523,
+    "decode_wall_seconds": 0.04820338898571208,
+    "seconds": 0.18969050902524032,
+    "decode_tokens_per_second": 145.21800535798144,
+    "finish_reason": "stop",
+    "sse_done": true,
+    "response": {
+      "text": "The capital of France is Paris.",
+      "usage": {
+        "prompt_tokens": 25,
+        "total_tokens": 33,
+        "completion_tokens": 8
+      }
+    },
+    "expected_keys": {
+      "known_answer": "Paris"
+    },
+    "retrieved_keys": {
+      "known_answer": true
+    },
+    "accuracy": true
+  },
+  {
+    "name": "state_isolation",
+    "exact_text_match": true
+  }
+]

evidence/http-p3d/tput-128/requests-128-c1.json

@@ -0,0 +1,34 @@
+[
+  {
+    "index": 0,
+    "start_seconds": 1.8349994206801057e-05,
+    "end_seconds": 8.190938635001658,
+    "ttft_seconds": 0.09066972200525925,
+    "latency_seconds": 8.19092028500745,
+    "decode_tokens_per_second": 63.08490319983218,
+    "text_sha256": "8b03541774e1f6be7b4c4473ed2e299b30efe7d684e4e280632204176904b0e4",
+    "usage": {
+      "prompt_tokens": 128,
+      "total_tokens": 640,
+      "completion_tokens": 512
+    },
+    "error": null,
+    "text": "# Understanding Database Transactions: The Foundation of Data Integrity\n\nIn the realm of database management systems (DBMS), a **transaction** is the fundamental unit of work. It is a sequence of one or more operations (such as inserting, updating, deleting, or querying data) that are executed as a single logical unit. The primary purpose of a transaction is to ensure that even in the event of system failures, power outages, or concurrent access by multiple users, the database remains in a consistent and reliable state.\n\nTo understand transactions deeply, we must explore the **ACID properties**, the lifecycle of a transaction, concurrency control, and practical real-world examples.\n\n---\n\n### 1. The ACID Properties: The Gold Standard\nFor a database to be considered reliable, every transaction must adhere to the ACID properties. These four principles ensure that data remains accurate and protected.\n\n#### A - Atomicity (\"All or Nothing\")\nAtomicity dictates that a transaction must be treated as an indivisible unit. Either every single operation within the transaction succeeds, or none of them do. If any part of the transaction fails (due to a crash, a constraint violation, or a power failure), the entire transaction is \"rolled back,\" and the database is returned to its state prior to the start of the transaction.\n\n*   **Example:** Imagine a bank transfer where \\$100 is moved from Account A to Account B. This involves two steps: (1) Subtracting \\$100 from A, and (2) Adding \\$100 to B. If the system crashes after step 1 but before step 2, the money would vanish into thin air. Atomicity ensures that if step 2 fails, step 1 is undone.\n\n#### C - Consistency\nConsistency ensures that a transaction brings the database from one valid state to another, maintaining all predefined rules, including constraints, foreign keys, and triggers. A transaction cannot leave the database in a \"broken\" state where data violates the business logic.\n\n*   **Example:** If a database has a rule that an account balance cannot drop below zero, and a transaction attempts to withdraw \\$500 from an account containing only \\$200, the database will reject the transaction to maintain consistency.\n\n#### I - Isolation\nIn modern systems, thousands of transactions happen simultaneously. Isolation ensures that concurrent transactions do not interfere with each other. The result of running multiple transactions at the same time should be the same as if they were executed sequentially (one after the"
+  },
+  {
+    "index": 1,
+    "start_seconds": 8.190989373979392,
+    "end_seconds": 16.381804777978687,
+    "ttft_seconds": 0.09145842600264587,
+    "latency_seconds": 8.190815403999295,
+    "decode_tokens_per_second": 63.091868561597515,
+    "text_sha256": "8b03541774e1f6be7b4c4473ed2e299b30efe7d684e4e280632204176904b0e4",
+    "usage": {
+      "prompt_tokens": 128,
+      "total_tokens": 640,
+      "completion_tokens": 512
+    },
+    "error": null,
+    "text": "# Understanding Database Transactions: The Foundation of Data Integrity\n\nIn the realm of database management systems (DBMS), a **transaction** is the fundamental unit of work. It is a sequence of one or more operations (such as inserting, updating, deleting, or querying data) that are executed as a single logical unit. The primary purpose of a transaction is to ensure that even in the event of system failures, power outages, or concurrent access by multiple users, the database remains in a consistent and reliable state.\n\nTo understand transactions deeply, we must explore the **ACID properties**, the lifecycle of a transaction, concurrency control, and practical real-world examples.\n\n---\n\n### 1. The ACID Properties: The Gold Standard\nFor a database to be considered reliable, every transaction must adhere to the ACID properties. These four principles ensure that data remains accurate and protected.\n\n#### A - Atomicity (\"All or Nothing\")\nAtomicity dictates that a transaction must be treated as an indivisible unit. Either every single operation within the transaction succeeds, or none of them do. If any part of the transaction fails (due to a crash, a constraint violation, or a power failure), the entire transaction is \"rolled back,\" and the database is returned to its state prior to the start of the transaction.\n\n*   **Example:** Imagine a bank transfer where \\$100 is moved from Account A to Account B. This involves two steps: (1) Subtracting \\$100 from A, and (2) Adding \\$100 to B. If the system crashes after step 1 but before step 2, the money would vanish into thin air. Atomicity ensures that if step 2 fails, step 1 is undone.\n\n#### C - Consistency\nConsistency ensures that a transaction brings the database from one valid state to another, maintaining all predefined rules, including constraints, foreign keys, and triggers. A transaction cannot leave the database in a \"broken\" state where data violates the business logic.\n\n*   **Example:** If a database has a rule that an account balance cannot drop below zero, and a transaction attempts to withdraw \\$500 from an account containing only \\$200, the database will reject the transaction to maintain consistency.\n\n#### I - Isolation\nIn modern systems, thousands of transactions happen simultaneously. Isolation ensures that concurrent transactions do not interfere with each other. The result of running multiple transactions at the same time should be the same as if they were executed sequentially (one after the"
+  }
+]

evidence/http-p3d/tput-128/summary.json

@@ -0,0 +1,24 @@
+{
+  "model": "google/gemma-4-12B-it",
+  "output_tokens": 512,
+  "method": "Closed loop; synchronized initial clients; max(min_requests,2*concurrency) requests; nearest-rank percentiles; aggregate includes prefill and queue drain",
+  "cases": [
+    {
+      "input_tokens": 128,
+      "concurrency": 1,
+      "requests": 2,
+      "successes": 2,
+      "errors": 0,
+      "wall_seconds": 16.38178642798448,
+      "matching_single_request_outputs": 2,
+      "aggregate_output_tokens_per_second": 62.508445248116146,
+      "requests_per_second": 0.12208680712522685,
+      "ttft_seconds_p50": 0.09066972200525925,
+      "ttft_seconds_p95": 0.09145842600264587,
+      "latency_seconds_p50": 8.190815403999295,
+      "latency_seconds_p95": 8.19092028500745,
+      "decode_tokens_per_second_p50": 63.08490319983218,
+      "decode_tokens_per_second_p95": 63.091868561597515
+    }
+  ]
+}

evidence/http-p3d/tput-128/warmup-128.json

@@ -0,0 +1,16 @@
+{
+  "index": -1,
+  "start_seconds": 3.100140020251274e-07,
+  "end_seconds": 8.237141543999314,
+  "ttft_seconds": 0.09195410198299214,
+  "latency_seconds": 8.237141233985312,
+  "decode_tokens_per_second": 62.73699920467591,
+  "text_sha256": "8b03541774e1f6be7b4c4473ed2e299b30efe7d684e4e280632204176904b0e4",
+  "usage": {
+    "prompt_tokens": 128,
+    "total_tokens": 640,
+    "completion_tokens": 512
+  },
+  "error": null,
+  "text": "# Understanding Database Transactions: The Foundation of Data Integrity\n\nIn the realm of database management systems (DBMS), a **transaction** is the fundamental unit of work. It is a sequence of one or more operations (such as inserting, updating, deleting, or querying data) that are executed as a single logical unit. The primary purpose of a transaction is to ensure that even in the event of system failures, power outages, or concurrent access by multiple users, the database remains in a consistent and reliable state.\n\nTo understand transactions deeply, we must explore the **ACID properties**, the lifecycle of a transaction, concurrency control, and practical real-world examples.\n\n---\n\n### 1. The ACID Properties: The Gold Standard\nFor a database to be considered reliable, every transaction must adhere to the ACID properties. These four principles ensure that data remains accurate and protected.\n\n#### A - Atomicity (\"All or Nothing\")\nAtomicity dictates that a transaction must be treated as an indivisible unit. Either every single operation within the transaction succeeds, or none of them do. If any part of the transaction fails (due to a crash, a constraint violation, or a power failure), the entire transaction is \"rolled back,\" and the database is returned to its state prior to the start of the transaction.\n\n*   **Example:** Imagine a bank transfer where \\$100 is moved from Account A to Account B. This involves two steps: (1) Subtracting \\$100 from A, and (2) Adding \\$100 to B. If the system crashes after step 1 but before step 2, the money would vanish into thin air. Atomicity ensures that if step 2 fails, step 1 is undone.\n\n#### C - Consistency\nConsistency ensures that a transaction brings the database from one valid state to another, maintaining all predefined rules, including constraints, foreign keys, and triggers. A transaction cannot leave the database in a \"broken\" state where data violates the business logic.\n\n*   **Example:** If a database has a rule that an account balance cannot drop below zero, and a transaction attempts to withdraw \\$500 from an account containing only \\$200, the database will reject the transaction to maintain consistency.\n\n#### I - Isolation\nIn modern systems, thousands of transactions happen simultaneously. Isolation ensures that concurrent transactions do not interfere with each other. The result of running multiple transactions at the same time should be the same as if they were executed sequentially (one after the"
+}

evidence/http-p3d/tput-131072/requests-131072-c1.json

@@ -0,0 +1,34 @@
+[
+  {
+    "index": 0,
+    "start_seconds": 3.928999649360776e-05,
+    "end_seconds": 140.3550663930073,
+    "ttft_seconds": 123.82656395100639,
+    "latency_seconds": 140.3550271030108,
+    "decode_tokens_per_second": 30.91648280188757,
+    "text_sha256": "372e489ce2a70556e81cd2e3a391d7f7ae934471533aa26b7720c790c8d94c3e",
+    "usage": {
+      "prompt_tokens": 131072,
+      "total_tokens": 131584,
+      "completion_tokens": 512
+    },
+    "error": null,
+    "text": "### Understanding Database Transactions: A Comprehensive Guide\n\nIn the world of data management, a **database transaction** is the fundamental unit of work. It is a sequence of one or more operations performed on a database that must be treated as a single, indivisible logical unit. The core philosophy behind transactions is simple: either the entire sequence of operations succeeds, or none of them do. This prevents the database from ending up in a \"half-baked\" or corrupted state where some data is updated while related data remains unchanged.\n\nTo understand transactions deeply, we must explore the **ACID properties**, the **transaction lifecycle**, and real-world **concurrency scenarios**.\n\n---\n\n### 1. The Pillars of Transactions: ACID Properties\n\nThe reliability of any relational database management system (RDBMS) like MySQL, PostgreSQL, or Oracle rests on the ACID acronym. These four properties ensure that even in the event of a power failure, system crash, or simultaneous access by thousands of users, the data remains accurate.\n\n#### A. Atomicity (\"All or Nothing\")\nAtomicity guarantees that a transaction is treated as a single \"atom.\" If a transaction consists of five different SQL statements (e.g., deducting money from one account, adding it to another, and logging the history), and the system crashes after the third statement, the database must \"roll back\" the first two. The database should look as if nothing ever happened.\n*   **Analogy:** Think of an ATM withdrawal. If the machine gives you the cash but fails to update your balance, the transaction failed. Atomicity ensures that if the balance isn't updated, the cash isn't dispensed.\n\n#### B. Consistency (\"Follow the Rules\")\nConsistency ensures that a transaction brings the database from one valid state to another. Every transaction must follow the predefined rules of the database, such as constraints (e.g., \"Age must be over 18\"), triggers, and cascades. If a transaction would result in a violation of these rules, the database will reject it.\n*   **Example:** If a database rule states that a bank account balance cannot be negative, and a transaction tries to withdraw more money than is available, the transaction is aborted to maintain consistency.\n\n#### C. Isolation (\"Don't Peek\")\nIsolation ensures that concurrent transactions (multiple people using the database at the same time) do not interfere with each other. Even though many transactions might be running simultaneously, the result should be the same as if they were executed one"
+  },
+  {
+    "index": 1,
+    "start_seconds": 140.35510921300738,
+    "end_seconds": 280.67249108300894,
+    "ttft_seconds": 123.78938921200461,
+    "latency_seconds": 140.31738187000155,
+    "decode_tokens_per_second": 30.91739205383985,
+    "text_sha256": "372e489ce2a70556e81cd2e3a391d7f7ae934471533aa26b7720c790c8d94c3e",
+    "usage": {
+      "prompt_tokens": 131072,
+      "total_tokens": 131584,
+      "completion_tokens": 512
+    },
+    "error": null,
+    "text": "### Understanding Database Transactions: A Comprehensive Guide\n\nIn the world of data management, a **database transaction** is the fundamental unit of work. It is a sequence of one or more operations performed on a database that must be treated as a single, indivisible logical unit. The core philosophy behind transactions is simple: either the entire sequence of operations succeeds, or none of them do. This prevents the database from ending up in a \"half-baked\" or corrupted state where some data is updated while related data remains unchanged.\n\nTo understand transactions deeply, we must explore the **ACID properties**, the **transaction lifecycle**, and real-world **concurrency scenarios**.\n\n---\n\n### 1. The Pillars of Transactions: ACID Properties\n\nThe reliability of any relational database management system (RDBMS) like MySQL, PostgreSQL, or Oracle rests on the ACID acronym. These four properties ensure that even in the event of a power failure, system crash, or simultaneous access by thousands of users, the data remains accurate.\n\n#### A. Atomicity (\"All or Nothing\")\nAtomicity guarantees that a transaction is treated as a single \"atom.\" If a transaction consists of five different SQL statements (e.g., deducting money from one account, adding it to another, and logging the history), and the system crashes after the third statement, the database must \"roll back\" the first two. The database should look as if nothing ever happened.\n*   **Analogy:** Think of an ATM withdrawal. If the machine gives you the cash but fails to update your balance, the transaction failed. Atomicity ensures that if the balance isn't updated, the cash isn't dispensed.\n\n#### B. Consistency (\"Follow the Rules\")\nConsistency ensures that a transaction brings the database from one valid state to another. Every transaction must follow the predefined rules of the database, such as constraints (e.g., \"Age must be over 18\"), triggers, and cascades. If a transaction would result in a violation of these rules, the database will reject it.\n*   **Example:** If a database rule states that a bank account balance cannot be negative, and a transaction tries to withdraw more money than is available, the transaction is aborted to maintain consistency.\n\n#### C. Isolation (\"Don't Peek\")\nIsolation ensures that concurrent transactions (multiple people using the database at the same time) do not interfere with each other. Even though many transactions might be running simultaneously, the result should be the same as if they were executed one"
+  }
+]

evidence/http-p3d/tput-131072/summary.json

@@ -0,0 +1,24 @@
+{
+  "model": "google/gemma-4-12B-it",
+  "output_tokens": 512,
+  "method": "Closed loop; synchronized initial clients; max(min_requests,2*concurrency) requests; nearest-rank percentiles; aggregate includes prefill and queue drain",
+  "cases": [
+    {
+      "input_tokens": 131072,
+      "concurrency": 1,
+      "requests": 2,
+      "successes": 2,
+      "errors": 0,
+      "wall_seconds": 280.67245179301244,
+      "matching_single_request_outputs": 2,
+      "aggregate_output_tokens_per_second": 3.6483808562557805,
+      "requests_per_second": 0.007125743859874571,
+      "ttft_seconds_p50": 123.78938921200461,
+      "ttft_seconds_p95": 123.82656395100639,
+      "latency_seconds_p50": 140.31738187000155,
+      "latency_seconds_p95": 140.3550271030108,
+      "decode_tokens_per_second_p50": 30.91648280188757,
+      "decode_tokens_per_second_p95": 30.91739205383985
+    }
+  ]
+}

evidence/http-p3d/tput-131072/warmup-131072.json

@@ -0,0 +1,16 @@
+{
+  "index": -1,
+  "start_seconds": 1.00000761449337e-06,
+  "end_seconds": 143.09652435599128,
+  "ttft_seconds": 126.40863994599204,
+  "latency_seconds": 143.09652335598366,
+  "decode_tokens_per_second": 30.621160536435426,
+  "text_sha256": "372e489ce2a70556e81cd2e3a391d7f7ae934471533aa26b7720c790c8d94c3e",
+  "usage": {
+    "prompt_tokens": 131072,
+    "total_tokens": 131584,
+    "completion_tokens": 512
+  },
+  "error": null,
+  "text": "### Understanding Database Transactions: A Comprehensive Guide\n\nIn the world of data management, a **database transaction** is the fundamental unit of work. It is a sequence of one or more operations performed on a database that must be treated as a single, indivisible logical unit. The core philosophy behind transactions is simple: either the entire sequence of operations succeeds, or none of them do. This prevents the database from ending up in a \"half-baked\" or corrupted state where some data is updated while related data remains unchanged.\n\nTo understand transactions deeply, we must explore the **ACID properties**, the **transaction lifecycle**, and real-world **concurrency scenarios**.\n\n---\n\n### 1. The Pillars of Transactions: ACID Properties\n\nThe reliability of any relational database management system (RDBMS) like MySQL, PostgreSQL, or Oracle rests on the ACID acronym. These four properties ensure that even in the event of a power failure, system crash, or simultaneous access by thousands of users, the data remains accurate.\n\n#### A. Atomicity (\"All or Nothing\")\nAtomicity guarantees that a transaction is treated as a single \"atom.\" If a transaction consists of five different SQL statements (e.g., deducting money from one account, adding it to another, and logging the history), and the system crashes after the third statement, the database must \"roll back\" the first two. The database should look as if nothing ever happened.\n*   **Analogy:** Think of an ATM withdrawal. If the machine gives you the cash but fails to update your balance, the transaction failed. Atomicity ensures that if the balance isn't updated, the cash isn't dispensed.\n\n#### B. Consistency (\"Follow the Rules\")\nConsistency ensures that a transaction brings the database from one valid state to another. Every transaction must follow the predefined rules of the database, such as constraints (e.g., \"Age must be over 18\"), triggers, and cascades. If a transaction would result in a violation of these rules, the database will reject it.\n*   **Example:** If a database rule states that a bank account balance cannot be negative, and a transaction tries to withdraw more money than is available, the transaction is aborted to maintain consistency.\n\n#### C. Isolation (\"Don't Peek\")\nIsolation ensures that concurrent transactions (multiple people using the database at the same time) do not interfere with each other. Even though many transactions might be running simultaneously, the result should be the same as if they were executed one"
+}

evidence/http-p3d/tput-2048/requests-2048-c1.json

@@ -0,0 +1,34 @@
+[
+  {
+    "index": 0,
+    "start_seconds": 1.8780003301799297e-05,
+    "end_seconds": 10.399938565999037,
+    "ttft_seconds": 0.6453376279969234,
+    "latency_seconds": 10.399919785995735,
+    "decode_tokens_per_second": 52.386027641385155,
+    "text_sha256": "02f0d03a55e50a19e8fd9e605f9812f55ef641b9e2ebacc042e79c1c4837431c",
+    "usage": {
+      "prompt_tokens": 2048,
+      "total_tokens": 2560,
+      "completion_tokens": 512
+    },
+    "error": null,
+    "text": "### Understanding Database Transactions: A Comprehensive Guide\n\nIn the world of data management, a **database transaction** is a fundamental concept that ensures data integrity and reliability. At its simplest, a transaction is a sequence of one or more operations performed as a single logical unit of work. The core philosophy of a transaction is \"all or nothing\": either every operation within the transaction succeeds and the changes are permanently saved, or if any single part fails, the entire transaction is undone, leaving the database in its original state.\n\nTo understand why this is critical, we must look at the **ACID properties**, the mechanisms that govern transactions, and real-world applications.\n\n---\n\n### 1. The ACID Properties\nThe reliability of a database system is measured by its adherence to the ACID model. These four properties ensure that even in the event of system crashes, power failures, or concurrent access by thousands of users, the data remains accurate.\n\n#### A. Atomicity\nAtomicity treats a transaction as an indivisible unit. Think of it like a physical atom\u2014it cannot be split. If a transaction involves five different SQL queries (e.g., updating a balance, creating a log entry, updating an inventory count, etc.), atomicity guarantees that if the fourth query fails, the first three are \"rolled back\" (undone).\n*   **Example:** If you are transferring money from Bank Account A to Bank Account B, two things must happen: money must be subtracted from A, and money must be added to B. If the system crashes after subtracting from A but before adding to B, the money would vanish. Atomicity prevents this by ensuring that if the addition to B fails, the subtraction from A is reversed.\n\n#### B. Consistency\nConsistency ensures that a transaction brings the database from one valid state to another, maintaining all predefined rules, including constraints, cascades, and triggers. A transaction must not violate the \"rules\" of the database.\n*   **Example:** Imagine a database rule that says \"Account balances cannot be negative.\" If a transaction attempts to withdraw \\$100 from an account that only has \\$50, the database will detect a violation of the consistency rule and abort the transaction.\n\n#### C. Isolation\nIn modern systems, thousands of transactions happen simultaneously. Isolation ensures that concurrent transactions do not interfere with each other. Even though they are running at the same time, the result should be the same as if they were executed one after another (sequentially).\n*   **"
+  },
+  {
+    "index": 1,
+    "start_seconds": 10.399984395015053,
+    "end_seconds": 20.804596664005658,
+    "ttft_seconds": 0.6470787139842287,
+    "latency_seconds": 10.404612268990604,
+    "decode_tokens_per_second": 52.37015888910936,
+    "text_sha256": "02f0d03a55e50a19e8fd9e605f9812f55ef641b9e2ebacc042e79c1c4837431c",
+    "usage": {
+      "prompt_tokens": 2048,
+      "total_tokens": 2560,
+      "completion_tokens": 512
+    },
+    "error": null,
+    "text": "### Understanding Database Transactions: A Comprehensive Guide\n\nIn the world of data management, a **database transaction** is a fundamental concept that ensures data integrity and reliability. At its simplest, a transaction is a sequence of one or more operations performed as a single logical unit of work. The core philosophy of a transaction is \"all or nothing\": either every operation within the transaction succeeds and the changes are permanently saved, or if any single part fails, the entire transaction is undone, leaving the database in its original state.\n\nTo understand why this is critical, we must look at the **ACID properties**, the mechanisms that govern transactions, and real-world applications.\n\n---\n\n### 1. The ACID Properties\nThe reliability of a database system is measured by its adherence to the ACID model. These four properties ensure that even in the event of system crashes, power failures, or concurrent access by thousands of users, the data remains accurate.\n\n#### A. Atomicity\nAtomicity treats a transaction as an indivisible unit. Think of it like a physical atom\u2014it cannot be split. If a transaction involves five different SQL queries (e.g., updating a balance, creating a log entry, updating an inventory count, etc.), atomicity guarantees that if the fourth query fails, the first three are \"rolled back\" (undone).\n*   **Example:** If you are transferring money from Bank Account A to Bank Account B, two things must happen: money must be subtracted from A, and money must be added to B. If the system crashes after subtracting from A but before adding to B, the money would vanish. Atomicity prevents this by ensuring that if the addition to B fails, the subtraction from A is reversed.\n\n#### B. Consistency\nConsistency ensures that a transaction brings the database from one valid state to another, maintaining all predefined rules, including constraints, cascades, and triggers. A transaction must not violate the \"rules\" of the database.\n*   **Example:** Imagine a database rule that says \"Account balances cannot be negative.\" If a transaction attempts to withdraw \\$100 from an account that only has \\$50, the database will detect a violation of the consistency rule and abort the transaction.\n\n#### C. Isolation\nIn modern systems, thousands of transactions happen simultaneously. Isolation ensures that concurrent transactions do not interfere with each other. Even though they are running at the same time, the result should be the same as if they were executed one after another (sequentially).\n*   **"
+  }
+]

evidence/http-p3d/tput-2048/summary.json

@@ -0,0 +1,24 @@
+{
+  "model": "google/gemma-4-12B-it",
+  "output_tokens": 512,
+  "method": "Closed loop; synchronized initial clients; max(min_requests,2*concurrency) requests; nearest-rank percentiles; aggregate includes prefill and queue drain",
+  "cases": [
+    {
+      "input_tokens": 2048,
+      "concurrency": 1,
+      "requests": 2,
+      "successes": 2,
+      "errors": 0,
+      "wall_seconds": 20.804577884002356,
+      "matching_single_request_outputs": 2,
+      "aggregate_output_tokens_per_second": 49.21993638656822,
+      "requests_per_second": 0.09613268825501606,
+      "ttft_seconds_p50": 0.6453376279969234,
+      "ttft_seconds_p95": 0.6470787139842287,
+      "latency_seconds_p50": 10.399919785995735,
+      "latency_seconds_p95": 10.404612268990604,
+      "decode_tokens_per_second_p50": 52.37015888910936,
+      "decode_tokens_per_second_p95": 52.386027641385155
+    }
+  ]
+}

evidence/http-p3d/tput-2048/warmup-2048.json

@@ -0,0 +1,16 @@
+{
+  "index": -1,
+  "start_seconds": 4.00003045797348e-07,
+  "end_seconds": 10.159259158011992,
+  "ttft_seconds": 0.6454166269977577,
+  "latency_seconds": 10.159258758008946,
+  "decode_tokens_per_second": 53.711591469489335,
+  "text_sha256": "02f0d03a55e50a19e8fd9e605f9812f55ef641b9e2ebacc042e79c1c4837431c",
+  "usage": {
+    "prompt_tokens": 2048,
+    "total_tokens": 2560,
+    "completion_tokens": 512
+  },
+  "error": null,
+  "text": "### Understanding Database Transactions: A Comprehensive Guide\n\nIn the world of data management, a **database transaction** is a fundamental concept that ensures data integrity and reliability. At its simplest, a transaction is a sequence of one or more operations performed as a single logical unit of work. The core philosophy of a transaction is \"all or nothing\": either every operation within the transaction succeeds and the changes are permanently saved, or if any single part fails, the entire transaction is undone, leaving the database in its original state.\n\nTo understand why this is critical, we must look at the **ACID properties**, the mechanisms that govern transactions, and real-world applications.\n\n---\n\n### 1. The ACID Properties\nThe reliability of a database system is measured by its adherence to the ACID model. These four properties ensure that even in the event of system crashes, power failures, or concurrent access by thousands of users, the data remains accurate.\n\n#### A. Atomicity\nAtomicity treats a transaction as an indivisible unit. Think of it like a physical atom\u2014it cannot be split. If a transaction involves five different SQL queries (e.g., updating a balance, creating a log entry, updating an inventory count, etc.), atomicity guarantees that if the fourth query fails, the first three are \"rolled back\" (undone).\n*   **Example:** If you are transferring money from Bank Account A to Bank Account B, two things must happen: money must be subtracted from A, and money must be added to B. If the system crashes after subtracting from A but before adding to B, the money would vanish. Atomicity prevents this by ensuring that if the addition to B fails, the subtraction from A is reversed.\n\n#### B. Consistency\nConsistency ensures that a transaction brings the database from one valid state to another, maintaining all predefined rules, including constraints, cascades, and triggers. A transaction must not violate the \"rules\" of the database.\n*   **Example:** Imagine a database rule that says \"Account balances cannot be negative.\" If a transaction attempts to withdraw \\$100 from an account that only has \\$50, the database will detect a violation of the consistency rule and abort the transaction.\n\n#### C. Isolation\nIn modern systems, thousands of transactions happen simultaneously. Isolation ensures that concurrent transactions do not interfere with each other. Even though they are running at the same time, the result should be the same as if they were executed one after another (sequentially).\n*   **"
+}

evidence/http-p3d/tput-261632/requests-261632-c1.json

@@ -0,0 +1,34 @@
+[
+  {
+    "index": 0,
+    "start_seconds": 1.9529979908838868e-05,
+    "end_seconds": 415.5554907670012,
+    "ttft_seconds": 394.7760664890229,
+    "latency_seconds": 415.55547123702127,
+    "decode_tokens_per_second": 24.59174523194995,
+    "text_sha256": "886da530a6b8ed5f967b0ceebe827d949fabefbce66a9a71c5076273db38c59d",
+    "usage": {
+      "prompt_tokens": 261632,
+      "total_tokens": 262144,
+      "completion_tokens": 512
+    },
+    "error": null,
+    "text": "### Understanding Database Transactions: A Comprehensive Guide\n\nIn the world of data management, a **database transaction** is the fundamental unit of work. It is not merely a single action, like inserting one row into a table; rather, it is a logical sequence of operations that must be treated as a single, indivisible unit. To ensure that data remains accurate and reliable\u2014especially in multi-user environments where thousands of people might be accessing the same information simultaneously\u2014databases rely on the concept of transactions.\n\nTo understand transactions deeply, we must explore the **ACID properties**, the **transaction lifecycle**, and **concurrency control mechanisms**.\n\n---\n\n### 1. The Core Philosophy: The ACID Properties\nThe gold standard for any database transaction is the **ACID** acronym. If a system cannot guarantee these four properties, it cannot be considered a reliable relational database management system (RDBMS).\n\n#### A. Atomicity (\"All or Nothing\")\nAtomicity ensures that a transaction is treated as a single \"atom.\" Either every single operation within the transaction succeeds, or none of them do. If a transaction involves five steps and the fourth step fails (due to a power outage, a constraint violation, or a network error), the database must \"roll back\" the first three steps so that the data remains in its original state.\n\n*   **Example:** Imagine you are transferring \\$100 from your Savings Account to your Checking Account.\n    1.  Subtract \\$100 from Savings.\n    2.  Add \\$100 to Checking.\n    If the system crashes after step 1 but before step 2, your money would simply vanish. Atomicity prevents this by ensuring that if step 2 fails, step 1 is undone.\n\n#### B. Consistency (Rules of the Game)\nConsistency ensures that a transaction brings the database from one valid state to another. Every database has predefined rules (constraints), such as \"account balances cannot be negative\" or \"every order must have a valid Customer ID.\" A transaction must never violate these rules. If a transaction attempts to perform an action that would break a rule, the database will reject the entire transaction.\n\n*   **Example:** If you try to transfer \\$500 from an account that only has \\$200, and the database has a \"minimum balance\" constraint, the transaction will fail because it would result in an inconsistent state (a negative balance).\n\n#### C. Isolation (The \"Privacy\" of Transactions)\n"
+  },
+  {
+    "index": 1,
+    "start_seconds": 415.55553735699505,
+    "end_seconds": 831.1073085209937,
+    "ttft_seconds": 394.76245176198427,
+    "latency_seconds": 415.55177116399864,
+    "decode_tokens_per_second": 24.580007387981023,
+    "text_sha256": "886da530a6b8ed5f967b0ceebe827d949fabefbce66a9a71c5076273db38c59d",
+    "usage": {
+      "prompt_tokens": 261632,
+      "total_tokens": 262144,
+      "completion_tokens": 512
+    },
+    "error": null,
+    "text": "### Understanding Database Transactions: A Comprehensive Guide\n\nIn the world of data management, a **database transaction** is the fundamental unit of work. It is not merely a single action, like inserting one row into a table; rather, it is a logical sequence of operations that must be treated as a single, indivisible unit. To ensure that data remains accurate and reliable\u2014especially in multi-user environments where thousands of people might be accessing the same information simultaneously\u2014databases rely on the concept of transactions.\n\nTo understand transactions deeply, we must explore the **ACID properties**, the **transaction lifecycle**, and **concurrency control mechanisms**.\n\n---\n\n### 1. The Core Philosophy: The ACID Properties\nThe gold standard for any database transaction is the **ACID** acronym. If a system cannot guarantee these four properties, it cannot be considered a reliable relational database management system (RDBMS).\n\n#### A. Atomicity (\"All or Nothing\")\nAtomicity ensures that a transaction is treated as a single \"atom.\" Either every single operation within the transaction succeeds, or none of them do. If a transaction involves five steps and the fourth step fails (due to a power outage, a constraint violation, or a network error), the database must \"roll back\" the first three steps so that the data remains in its original state.\n\n*   **Example:** Imagine you are transferring \\$100 from your Savings Account to your Checking Account.\n    1.  Subtract \\$100 from Savings.\n    2.  Add \\$100 to Checking.\n    If the system crashes after step 1 but before step 2, your money would simply vanish. Atomicity prevents this by ensuring that if step 2 fails, step 1 is undone.\n\n#### B. Consistency (Rules of the Game)\nConsistency ensures that a transaction brings the database from one valid state to another. Every database has predefined rules (constraints), such as \"account balances cannot be negative\" or \"every order must have a valid Customer ID.\" A transaction must never violate these rules. If a transaction attempts to perform an action that would break a rule, the database will reject the entire transaction.\n\n*   **Example:** If you try to transfer \\$500 from an account that only has \\$200, and the database has a \"minimum balance\" constraint, the transaction will fail because it would result in an inconsistent state (a negative balance).\n\n#### C. Isolation (The \"Privacy\" of Transactions)\n"
+  }
+]

evidence/http-p3d/tput-261632/summary.json

@@ -0,0 +1,24 @@
+{
+  "model": "google/gemma-4-12B-it",
+  "output_tokens": 512,
+  "method": "Closed loop; synchronized initial clients; max(min_requests,2*concurrency) requests; nearest-rank percentiles; aggregate includes prefill and queue drain",
+  "cases": [
+    {
+      "input_tokens": 261632,
+      "concurrency": 1,
+      "requests": 2,
+      "successes": 2,
+      "errors": 0,
+      "wall_seconds": 831.1072889910138,
+      "matching_single_request_outputs": 2,
+      "aggregate_output_tokens_per_second": 1.2320912276478324,
+      "requests_per_second": 0.0024064281789996727,
+      "ttft_seconds_p50": 394.76245176198427,
+      "ttft_seconds_p95": 394.7760664890229,
+      "latency_seconds_p50": 415.55177116399864,
+      "latency_seconds_p95": 415.55547123702127,
+      "decode_tokens_per_second_p50": 24.580007387981023,
+      "decode_tokens_per_second_p95": 24.59174523194995
+    }
+  ]
+}

evidence/http-p3d/tput-261632/warmup-261632.json

@@ -0,0 +1,16 @@
+{
+  "index": -1,
+  "start_seconds": 1.200009137392044e-06,
+  "end_seconds": 417.3713296529895,
+  "ttft_seconds": 396.3232168069808,
+  "latency_seconds": 417.3713284529804,
+  "decode_tokens_per_second": 24.27779241951352,
+  "text_sha256": "886da530a6b8ed5f967b0ceebe827d949fabefbce66a9a71c5076273db38c59d",
+  "usage": {
+    "prompt_tokens": 261632,
+    "total_tokens": 262144,
+    "completion_tokens": 512
+  },
+  "error": null,
+  "text": "### Understanding Database Transactions: A Comprehensive Guide\n\nIn the world of data management, a **database transaction** is the fundamental unit of work. It is not merely a single action, like inserting one row into a table; rather, it is a logical sequence of operations that must be treated as a single, indivisible unit. To ensure that data remains accurate and reliable\u2014especially in multi-user environments where thousands of people might be accessing the same information simultaneously\u2014databases rely on the concept of transactions.\n\nTo understand transactions deeply, we must explore the **ACID properties**, the **transaction lifecycle**, and **concurrency control mechanisms**.\n\n---\n\n### 1. The Core Philosophy: The ACID Properties\nThe gold standard for any database transaction is the **ACID** acronym. If a system cannot guarantee these four properties, it cannot be considered a reliable relational database management system (RDBMS).\n\n#### A. Atomicity (\"All or Nothing\")\nAtomicity ensures that a transaction is treated as a single \"atom.\" Either every single operation within the transaction succeeds, or none of them do. If a transaction involves five steps and the fourth step fails (due to a power outage, a constraint violation, or a network error), the database must \"roll back\" the first three steps so that the data remains in its original state.\n\n*   **Example:** Imagine you are transferring \\$100 from your Savings Account to your Checking Account.\n    1.  Subtract \\$100 from Savings.\n    2.  Add \\$100 to Checking.\n    If the system crashes after step 1 but before step 2, your money would simply vanish. Atomicity prevents this by ensuring that if step 2 fails, step 1 is undone.\n\n#### B. Consistency (Rules of the Game)\nConsistency ensures that a transaction brings the database from one valid state to another. Every database has predefined rules (constraints), such as \"account balances cannot be negative\" or \"every order must have a valid Customer ID.\" A transaction must never violate these rules. If a transaction attempts to perform an action that would break a rule, the database will reject the entire transaction.\n\n*   **Example:** If you try to transfer \\$500 from an account that only has \\$200, and the database has a \"minimum balance\" constraint, the transaction will fail because it would result in an inconsistent state (a negative balance).\n\n#### C. Isolation (The \"Privacy\" of Transactions)\n"
+}

evidence/http-p3d/tput-32768/requests-32768-c1.json

@@ -0,0 +1,34 @@
+[
+  {
+    "index": 0,
+    "start_seconds": 2.0428997231647372e-05,
+    "end_seconds": 28.759651961998316,
+    "ttft_seconds": 16.977761214016937,
+    "latency_seconds": 28.759631533001084,
+    "decode_tokens_per_second": 43.37198960875458,
+    "text_sha256": "1506d9360ed3ea7ef3017e332c703f80b9171cdd9b987634b75b4789218ad98d",
+    "usage": {
+      "prompt_tokens": 32768,
+      "total_tokens": 33280,
+      "completion_tokens": 512
+    },
+    "error": null,
+    "text": "### Understanding Database Transactions: A Comprehensive Guide\n\nIn the world of software engineering and data management, a **database transaction** is a fundamental concept that ensures data integrity. At its simplest, a transaction is a sequence of one or more operations performed as a single logical unit of work. The core philosophy of a transaction is \"all or nothing\": either every operation within the transaction succeeds and is permanently saved to the database, or none of them are applied.\n\nTo understand why this is critical, we must look at the **ACID properties**, the mechanisms that enforce them, and real-world scenarios where transactions prevent catastrophic data loss.\n\n---\n\n### 1. The ACID Properties\nThe reliability of a database management system (DBMS) is measured by its adherence to the ACID model. These four properties are the \"gold standard\" for transaction management.\n\n#### A. Atomicity (\"All or Nothing\")\nAtomicity ensures that a transaction is treated as an indivisible unit. If a transaction consists of five different SQL statements (e.g., updating a balance, creating a log entry, updating an inventory count, etc.), and the fourth statement fails due to a power outage or a constraint violation, the database must \"roll back\" the first three statements. The database should return to the exact state it was in before the transaction started.\n\n#### B. Consistency (Valid State to Valid State)\nConsistency ensures that a transaction brings the database from one valid state to another, maintaining all predefined rules, including-defined constraints (like unique keys),s, and foreign key relationships. For example, if a rule states that an account balance cannot drop below zero, any transaction that would result in a negative balance must be rejected by the system.\n\n#### C. Isolation (Independence of Concurrent Transactions)\nIn modern applications, thousands of users may access a database simultaneously. Isolation ensures that the concurrent execution of transactions results in a system state that is the same as if the transactions were executed sequentially (one after the other). Without isolation, \"dirty reads\" or \"lost updates\" could occur\u2014where one user sees half-finished data from another user's ongoing transaction.\n\n#### D. Durability (Permanence)\nOnce a transaction has been committed (successfully completed), it must remain committed even in the event of a system failure, such as a crash or a power loss. This is usually achieved by recording the transaction in non-volatile memory (like a hard drive or SSD) via transaction logs before confirming success to the user."
+  },
+  {
+    "index": 1,
+    "start_seconds": 28.759694711014163,
+    "end_seconds": 57.533709167008055,
+    "ttft_seconds": 17.023219919996336,
+    "latency_seconds": 28.774014455993893,
+    "decode_tokens_per_second": 43.48662823635663,
+    "text_sha256": "1506d9360ed3ea7ef3017e332c703f80b9171cdd9b987634b75b4789218ad98d",
+    "usage": {
+      "prompt_tokens": 32768,
+      "total_tokens": 33280,
+      "completion_tokens": 512
+    },
+    "error": null,
+    "text": "### Understanding Database Transactions: A Comprehensive Guide\n\nIn the world of software engineering and data management, a **database transaction** is a fundamental concept that ensures data integrity. At its simplest, a transaction is a sequence of one or more operations performed as a single logical unit of work. The core philosophy of a transaction is \"all or nothing\": either every operation within the transaction succeeds and is permanently saved to the database, or none of them are applied.\n\nTo understand why this is critical, we must look at the **ACID properties**, the mechanisms that enforce them, and real-world scenarios where transactions prevent catastrophic data loss.\n\n---\n\n### 1. The ACID Properties\nThe reliability of a database management system (DBMS) is measured by its adherence to the ACID model. These four properties are the \"gold standard\" for transaction management.\n\n#### A. Atomicity (\"All or Nothing\")\nAtomicity ensures that a transaction is treated as an indivisible unit. If a transaction consists of five different SQL statements (e.g., updating a balance, creating a log entry, updating an inventory count, etc.), and the fourth statement fails due to a power outage or a constraint violation, the database must \"roll back\" the first three statements. The database should return to the exact state it was in before the transaction started.\n\n#### B. Consistency (Valid State to Valid State)\nConsistency ensures that a transaction brings the database from one valid state to another, maintaining all predefined rules, including-defined constraints (like unique keys),s, and foreign key relationships. For example, if a rule states that an account balance cannot drop below zero, any transaction that would result in a negative balance must be rejected by the system.\n\n#### C. Isolation (Independence of Concurrent Transactions)\nIn modern applications, thousands of users may access a database simultaneously. Isolation ensures that the concurrent execution of transactions results in a system state that is the same as if the transactions were executed sequentially (one after the other). Without isolation, \"dirty reads\" or \"lost updates\" could occur\u2014where one user sees half-finished data from another user's ongoing transaction.\n\n#### D. Durability (Permanence)\nOnce a transaction has been committed (successfully completed), it must remain committed even in the event of a system failure, such as a crash or a power loss. This is usually achieved by recording the transaction in non-volatile memory (like a hard drive or SSD) via transaction logs before confirming success to the user."
+  }
+]

evidence/http-p3d/tput-32768/summary.json

@@ -0,0 +1,24 @@
+{
+  "model": "google/gemma-4-12B-it",
+  "output_tokens": 512,
+  "method": "Closed loop; synchronized initial clients; max(min_requests,2*concurrency) requests; nearest-rank percentiles; aggregate includes prefill and queue drain",
+  "cases": [
+    {
+      "input_tokens": 32768,
+      "concurrency": 1,
+      "requests": 2,
+      "successes": 2,
+      "errors": 0,
+      "wall_seconds": 57.533688738010824,
+      "matching_single_request_outputs": 2,
+      "aggregate_output_tokens_per_second": 17.79826780554526,
+      "requests_per_second": 0.03476224180770559,
+      "ttft_seconds_p50": 16.977761214016937,
+      "ttft_seconds_p95": 17.023219919996336,
+      "latency_seconds_p50": 28.759631533001084,
+      "latency_seconds_p95": 28.774014455993893,
+      "decode_tokens_per_second_p50": 43.37198960875458,
+      "decode_tokens_per_second_p95": 43.48662823635663
+    }
+  ]
+}

evidence/http-p3d/tput-32768/warmup-32768.json

@@ -0,0 +1,16 @@
+{
+  "index": -1,
+  "start_seconds": 8.200004231184721e-07,
+  "end_seconds": 28.692602641007397,
+  "ttft_seconds": 16.91264510701876,
+  "latency_seconds": 28.692601821006974,
+  "decode_tokens_per_second": 43.37904968705863,
+  "text_sha256": "1506d9360ed3ea7ef3017e332c703f80b9171cdd9b987634b75b4789218ad98d",
+  "usage": {
+    "prompt_tokens": 32768,
+    "total_tokens": 33280,
+    "completion_tokens": 512
+  },
+  "error": null,
+  "text": "### Understanding Database Transactions: A Comprehensive Guide\n\nIn the world of software engineering and data management, a **database transaction** is a fundamental concept that ensures data integrity. At its simplest, a transaction is a sequence of one or more operations performed as a single logical unit of work. The core philosophy of a transaction is \"all or nothing\": either every operation within the transaction succeeds and is permanently saved to the database, or none of them are applied.\n\nTo understand why this is critical, we must look at the **ACID properties**, the mechanisms that enforce them, and real-world scenarios where transactions prevent catastrophic data loss.\n\n---\n\n### 1. The ACID Properties\nThe reliability of a database management system (DBMS) is measured by its adherence to the ACID model. These four properties are the \"gold standard\" for transaction management.\n\n#### A. Atomicity (\"All or Nothing\")\nAtomicity ensures that a transaction is treated as an indivisible unit. If a transaction consists of five different SQL statements (e.g., updating a balance, creating a log entry, updating an inventory count, etc.), and the fourth statement fails due to a power outage or a constraint violation, the database must \"roll back\" the first three statements. The database should return to the exact state it was in before the transaction started.\n\n#### B. Consistency (Valid State to Valid State)\nConsistency ensures that a transaction brings the database from one valid state to another, maintaining all predefined rules, including-defined constraints (like unique keys),s, and foreign key relationships. For example, if a rule states that an account balance cannot drop below zero, any transaction that would result in a negative balance must be rejected by the system.\n\n#### C. Isolation (Independence of Concurrent Transactions)\nIn modern applications, thousands of users may access a database simultaneously. Isolation ensures that the concurrent execution of transactions results in a system state that is the same as if the transactions were executed sequentially (one after the other). Without isolation, \"dirty reads\" or \"lost updates\" could occur\u2014where one user sees half-finished data from another user's ongoing transaction.\n\n#### D. Durability (Permanence)\nOnce a transaction has been committed (successfully completed), it must remain committed even in the event of a system failure, such as a crash or a power loss. This is usually achieved by recording the transaction in non-volatile memory (like a hard drive or SSD) via transaction logs before confirming success to the user."
+}

evidence/http-p3d/tput-8192/requests-8192-c1.json

@@ -0,0 +1,34 @@
+[
+  {
+    "index": 0,
+    "start_seconds": 2.2149994038045406e-05,
+    "end_seconds": 12.67971995798871,
+    "ttft_seconds": 3.2031257979979273,
+    "latency_seconds": 12.679697807994671,
+    "decode_tokens_per_second": 53.92284405708368,
+    "text_sha256": "ed6c97ae9c6aa59779ca029eff53e380a46050f750027f929e9644ef5075218c",
+    "usage": {
+      "prompt_tokens": 8192,
+      "total_tokens": 8704,
+      "completion_tokens": 512
+    },
+    "error": null,
+    "text": "### Understanding Database Transactions: A Comprehensive Guide\n\nIn the world of data management, a **database transaction** is a fundamental concept that ensures data integrity and reliability. At its simplest, a transaction is a sequence of one or more operations performed as a single logical unit of work. The core philosophy of a transaction is \"all or nothing\": either every operation within the transaction succeeds and is permanently saved to the database, or, if any single part fails, the entire transaction is undone, leaving the database in its original state.\n\nTo understand why this is critical, we must look at the **ACID properties**, which serve as the gold standard for ensuring that database transactions are processed reliably.\n\n---\n\n### The ACID Properties\n\nFor a database management system (DBMS) to be considered reliable, it must adhere to the following four principles:\n\n#### 1. Atomicity (\"All or Nothing\")\nAtomicity ensures that a transaction is treated as an indivisible unit. If a transaction consists of five different SQL queries (e.g., updating a balance, creating a log entry, updating an inventory count, etc.), and the system crashes during the third query, the first two queries must be \"rolled back\" (undone). The database should not be left in a \"half-finished\" state.\n\n#### 2. Consistency\nConsistency ensures that a transaction brings the database from one valid state to another, maintaining all predefined rules, including constraints, cascades, and triggers. For example, if a database rule states that an account balance cannot drop below zero, any transaction that would result in a negative balance must be rejected by the system.\n\n#### 3. Isolation\nIn modern applications, thousands of users may access a database simultaneously. Isolation ensures that concurrent transactions do not interfere with each other. Even though multiple transactions are happening at the same time, the result should be the same as if they were executed one after another (sequentially). This prevents \"dirty reads\" (reading uncommitted data) or \"lost updates\" (where two people update the same row at the exact same millisecond and one update is overwritten).\n\n#### 4. Durability\nDurability guarantees that once a transaction has been committed (successfully completed), it will remain committed even in the event of a system failure, power outage, or crash. This is usually achieved by recording the transaction in non-volatile memory (like a hard drive or SSD) via a transaction log before confirming success to the user.\n\n---\n\n### Real-World Example: The"
+  },
+  {
+    "index": 1,
+    "start_seconds": 12.679757648002123,
+    "end_seconds": 25.362715021008626,
+    "ttft_seconds": 3.206180963985389,
+    "latency_seconds": 12.682957373006502,
+    "decode_tokens_per_second": 53.92168694176561,
+    "text_sha256": "ed6c97ae9c6aa59779ca029eff53e380a46050f750027f929e9644ef5075218c",
+    "usage": {
+      "prompt_tokens": 8192,
+      "total_tokens": 8704,
+      "completion_tokens": 512
+    },
+    "error": null,
+    "text": "### Understanding Database Transactions: A Comprehensive Guide\n\nIn the world of data management, a **database transaction** is a fundamental concept that ensures data integrity and reliability. At its simplest, a transaction is a sequence of one or more operations performed as a single logical unit of work. The core philosophy of a transaction is \"all or nothing\": either every operation within the transaction succeeds and is permanently saved to the database, or, if any single part fails, the entire transaction is undone, leaving the database in its original state.\n\nTo understand why this is critical, we must look at the **ACID properties**, which serve as the gold standard for ensuring that database transactions are processed reliably.\n\n---\n\n### The ACID Properties\n\nFor a database management system (DBMS) to be considered reliable, it must adhere to the following four principles:\n\n#### 1. Atomicity (\"All or Nothing\")\nAtomicity ensures that a transaction is treated as an indivisible unit. If a transaction consists of five different SQL queries (e.g., updating a balance, creating a log entry, updating an inventory count, etc.), and the system crashes during the third query, the first two queries must be \"rolled back\" (undone). The database should not be left in a \"half-finished\" state.\n\n#### 2. Consistency\nConsistency ensures that a transaction brings the database from one valid state to another, maintaining all predefined rules, including constraints, cascades, and triggers. For example, if a database rule states that an account balance cannot drop below zero, any transaction that would result in a negative balance must be rejected by the system.\n\n#### 3. Isolation\nIn modern applications, thousands of users may access a database simultaneously. Isolation ensures that concurrent transactions do not interfere with each other. Even though multiple transactions are happening at the same time, the result should be the same as if they were executed one after another (sequentially). This prevents \"dirty reads\" (reading uncommitted data) or \"lost updates\" (where two people update the same row at the exact same millisecond and one update is overwritten).\n\n#### 4. Durability\nDurability guarantees that once a transaction has been committed (successfully completed), it will remain committed even in the event of a system failure, power outage, or crash. This is usually achieved by recording the transaction in non-volatile memory (like a hard drive or SSD) via a transaction log before confirming success to the user.\n\n---\n\n### Real-World Example: The"
+  }
+]

evidence/http-p3d/tput-8192/summary.json

@@ -0,0 +1,24 @@
+{
+  "model": "google/gemma-4-12B-it",
+  "output_tokens": 512,
+  "method": "Closed loop; synchronized initial clients; max(min_requests,2*concurrency) requests; nearest-rank percentiles; aggregate includes prefill and queue drain",
+  "cases": [
+    {
+      "input_tokens": 8192,
+      "concurrency": 1,
+      "requests": 2,
+      "successes": 2,
+      "errors": 0,
+      "wall_seconds": 25.362692871014588,
+      "matching_single_request_outputs": 2,
+      "aggregate_output_tokens_per_second": 40.374261724008996,
+      "requests_per_second": 0.07885597992970507,
+      "ttft_seconds_p50": 3.2031257979979273,
+      "ttft_seconds_p95": 3.206180963985389,
+      "latency_seconds_p50": 12.679697807994671,
+      "latency_seconds_p95": 12.682957373006502,
+      "decode_tokens_per_second_p50": 53.92168694176561,
+      "decode_tokens_per_second_p95": 53.92284405708368
+    }
+  ]
+}

evidence/http-p3d/tput-8192/warmup-8192.json

@@ -0,0 +1,16 @@
+{
+  "index": -1,
+  "start_seconds": 3.00002284348011e-07,
+  "end_seconds": 12.817421763000311,
+  "ttft_seconds": 3.203757772978861,
+  "latency_seconds": 12.817421462998027,
+  "decode_tokens_per_second": 53.15396023562198,
+  "text_sha256": "ed6c97ae9c6aa59779ca029eff53e380a46050f750027f929e9644ef5075218c",
+  "usage": {
+    "prompt_tokens": 8192,
+    "total_tokens": 8704,
+    "completion_tokens": 512
+  },
+  "error": null,
+  "text": "### Understanding Database Transactions: A Comprehensive Guide\n\nIn the world of data management, a **database transaction** is a fundamental concept that ensures data integrity and reliability. At its simplest, a transaction is a sequence of one or more operations performed as a single logical unit of work. The core philosophy of a transaction is \"all or nothing\": either every operation within the transaction succeeds and is permanently saved to the database, or, if any single part fails, the entire transaction is undone, leaving the database in its original state.\n\nTo understand why this is critical, we must look at the **ACID properties**, which serve as the gold standard for ensuring that database transactions are processed reliably.\n\n---\n\n### The ACID Properties\n\nFor a database management system (DBMS) to be considered reliable, it must adhere to the following four principles:\n\n#### 1. Atomicity (\"All or Nothing\")\nAtomicity ensures that a transaction is treated as an indivisible unit. If a transaction consists of five different SQL queries (e.g., updating a balance, creating a log entry, updating an inventory count, etc.), and the system crashes during the third query, the first two queries must be \"rolled back\" (undone). The database should not be left in a \"half-finished\" state.\n\n#### 2. Consistency\nConsistency ensures that a transaction brings the database from one valid state to another, maintaining all predefined rules, including constraints, cascades, and triggers. For example, if a database rule states that an account balance cannot drop below zero, any transaction that would result in a negative balance must be rejected by the system.\n\n#### 3. Isolation\nIn modern applications, thousands of users may access a database simultaneously. Isolation ensures that concurrent transactions do not interfere with each other. Even though multiple transactions are happening at the same time, the result should be the same as if they were executed one after another (sequentially). This prevents \"dirty reads\" (reading uncommitted data) or \"lost updates\" (where two people update the same row at the exact same millisecond and one update is overwritten).\n\n#### 4. Durability\nDurability guarantees that once a transaction has been committed (successfully completed), it will remain committed even in the event of a system failure, power outage, or crash. This is usually achieved by recording the transaction in non-volatile memory (like a hard drive or SSD) via a transaction log before confirming success to the user.\n\n---\n\n### Real-World Example: The"
+}

evidence/localmaxxing/p3d-2k/prompt-2k.txt

@@ -0,0 +1,216 @@
+Summarize the following passage from Newton’s Opticks, then explain its main experiment in plain language.
+
+ added
+about twelve Years after to complete the Theory; except the third Book,
+and the last Proposition of the Second, which were since put together
+out of scatter'd Papers. To avoid being engaged in Disputes about these
+Matters, I have hitherto delayed the printing, and should still have
+delayed it, had not the Importunity of Friends prevailed upon me. If any
+other Papers writ on this Subject are got out of my Hands they are
+imperfect, and were perhaps written before I had tried all the
+Experiments here set down, and fully satisfied my self about the Laws of
+Refractions and Composition of Colours. I have here publish'd what I
+think proper to come abroad, wishing that it may not be translated into
+another Language without my Consent._
+
+_The Crowns of Colours, which sometimes appear about the Sun and Moon, I
+have endeavoured to give an Account of; but for want of sufficient
+Observations leave that Matter to be farther examined. The Subject of
+the Third Book I have also left imperfect, not having tried all the
+Experiments which I intended when I was about these Matters, nor
+repeated some of those which I did try, until I had satisfied my self
+about all their Circumstances. To communicate what I have tried, and
+leave the rest to others for farther Enquiry, is all my Design in
+publishing these Papers._
+
+_In a Letter written to Mr._ Leibnitz _in the year 1679, and published
+by Dr._ Wallis, _I mention'd a Method by which I had found some general
+Theorems about squaring Curvilinear Figures, or comparing them with the
+Conic Sections, or other the simplest Figures with which they may be
+compared. And some Years ago I lent out a Manuscript containing such
+Theorems, and having since met with some Things copied out of it, I have
+on this Occasion made it publick, prefixing to it an_ Introduction, _and
+subjoining a_ Scholium _concerning that Method. And I have joined with
+it another small Tract concerning the Curvilinear Figures of the Second
+Kind, which was also written many Years ago, and made known to some
+Friends, who have solicited the making it publick._
+
+                                        _I. N._
+
+April 1, 1704.
+
+
+Advertisement II
+
+_In this Second Edition of these Opticks I have omitted the Mathematical
+Tracts publish'd at the End of the former Edition, as not belonging to
+the Subject. And at the End of the Third Book I have added some
+Questions. And to shew that I do not take Gravity for an essential
+Property of Bodies, I have added one Question concerning its Cause,
+chusing to propose it by way of a Question, because I am not yet
+satisfied about it for want of Experiments._
+
+                                        _I. N._
+
+July 16, 1717.
+
+
+Advertisement to this Fourth Edition
+
+_This new Edition of Sir_ Isaac Newton's Opticks _is carefully printed
+from the Third Edition, as it was corrected by the Author's own Hand,
+and left before his Death with the Bookseller. Since Sir_ Isaac's
+Lectiones Opticæ, _which he publickly read in the University of_
+Cambridge _in the Years 1669, 1670, and 1671, are lately printed, it has
+been thought proper to make at the bottom of the Pages several Citations
+from thence, where may be found the Demonstrations, which the Author
+omitted in these_ Opticks.
+
+       *       *       *       *       *
+
+Transcriber's Note: There are several greek letters used in the
+descriptions of the illustrations. They are signified by [Greek:
+letter]. Square roots are noted by the letters sqrt before the equation.
+
+       *       *       *       *       *
+
+THE FIRST BOOK OF OPTICKS
+
+
+
+
+_PART I._
+
+
+My Design in this Book is not to explain the Properties of Light by
+Hypotheses, but to propose and prove them by Reason and Experiments: In
+order to which I shall premise the following Definitions and Axioms.
+
+
+
+
+_DEFINITIONS_
+
+
+DEFIN. I.
+
+_By the Rays of Light I understand its least Parts, and those as well
+Successive in the same Lines, as Contemporary in several Lines._ For it
+is manifest that Light consists of Parts, both Successive and
+Contemporary; because in the same place you may stop that which comes
+one moment, and let pass that which comes presently after; and in the
+same time you may stop it in any one place, and let it pass in any
+other. For that part of Light which is stopp'd cannot be the same with
+that which is let pass. The least Light or part of Light, which may be
+stopp'd alone without the rest of the Light, or propagated alone, or do
+or suffer any thing alone, which the rest of the Light doth not or
+suffers not, I call a Ray of Light.
+
+
+DEFIN. II.
+
+_Refrangibility of the Rays of Light, is their Disposition to be
+refracted or turned out of their Way in passing out of one transparent
+Body or Medium into another. And a greater or less Refrangibility of
+Rays, is their Disposition to be turned more or less out of their Way in
+like Incidences on the same Medium._ Mathematicians usually consider the
+Rays of Light to be Lines reaching from the luminous Body to the Body
+illuminated, and the refraction of those Rays to be the bending or
+breaking of those lines in their passing out of one Medium into another.
+And thus may Rays and Refractions be considered, if Light be propagated
+in an instant. But by an Argument taken from the Æquations of the times
+of the Eclipses of _Jupiter's Satellites_, it seems that Light is
+propagated in time, spending in its passage from the Sun to us about
+seven Minutes of time: And therefore I have chosen to define Rays and
+Refractions in such general terms as may agree to Light in both cases.
+
+
+DEFIN. III.
+
+_Reflexibility of Rays, is their Disposition to be reflected or turned
+back into the same Medium from any other Medium upon whose Surface they
+fall. And Rays are more or less reflexible, which are turned back more
+or less easily._ As if Light pass out of a Glass into Air, and by being
+inclined more and more to the common Surface of the Glass and Air,
+begins at length to be totally reflected by that Surface; those sorts of
+Rays which at like Incidences are reflected most copiously, or by
+inclining the Rays begin soonest to be totally reflected, are most
+reflexible.
+
+
+DEFIN. IV.
+
+_The Angle of Incidence is that Angle, which the Line described by the
+incident Ray contains with the Perpendicular to the reflecting or
+refracting Surface at the Point of Incidence._
+
+
+DEFIN. V.
+
+_The Angle of Reflexion or Refraction, is the Angle which the line
+described by the reflected or refracted Ray containeth with the
+Perpendicular to the reflecting or refracting Surface at the Point of
+Incidence._
+
+
+DEFIN. VI.
+
+_The Sines of Incidence, Reflexion, and Refraction, are the Sines of the
+Angles of Incidence, Reflexion, and Refraction._
+
+
+DEFIN. VII
+
+_The Light whose Rays are all alike Refrangible, I call Simple,
+Homogeneal and Similar; and that whose Rays are some more Refrangible
+than others, I call Compound, Heterogeneal and Dissimilar._ The former
+Light I call Homogeneal, not because I would affirm it so in all
+respects, but because the Rays which agree in Refrangibility, agree at
+least in all those their other Properties which I consider in the
+following Discourse.
+
+
+DEFIN. VIII.
+
+_The Colours of Homogeneal Lights, I call Primary, Homogeneal and
+Simple; and those of Heterogeneal Lights, Heterogeneal and Compound._
+For these are always compounded of the colours of Homogeneal Lights; as
+will appear in the following Discourse.
+
+
+
+
+_AXIOMS._
+
+
+AX. I.
+
+_The Angles of Reflexion and Refraction, lie in one and the same Plane
+with the Angle of Incidence._
+
+
+AX. II.
+
+_The Angle of Reflexion is equal to the Angle of Incidence._
+
+
+AX. III.
+
+_If the refracted Ray be returned directly back to the Point of
+Incidence, it shall be refracted into the Line before described by the
+incident Ray._
+
+
+AX. IV.
+
+_Refraction out of the rarer Medium into the denser, is made towards the
+Perpendicular; that is, so that the Angle of Refraction be less than the
+Angle of Incidence._
+
+
+AX. V.
+
+_The Sine of Incidence is either accurately or very nearly in a given
+Ratio to the Sine of Refraction._
+
+Whence

evidence/localmaxxing/p3d-2k/speed-test.json

@@ -0,0 +1,212 @@
+{
+  "agentFeedback": {
+    "benchmarkStatus": "completed",
+    "canApiValidate": true,
+    "canSubmit": true,
+    "engine": "vllm",
+    "message": "Speed-test payload is ready for API validation.",
+    "mode": "remote",
+    "nextCommand": "lmx speed-test dry-run /var/tmp/gemma4-12b/runs/lmx-2k-p3d/speed-test.json",
+    "outputPath": "/var/tmp/gemma4-12b/runs/lmx-2k-p3d/speed-test.json",
+    "outputPathAbsolute": "/var/tmp/gemma4-12b/runs/lmx-2k-p3d/speed-test.json",
+    "requiresMetrics": false,
+    "runPersisted": true,
+    "savedRunPath": "/var/tmp/gemma4-12b/runs/lmx-2k-p3d/runs/Lottolabs-gemma-4-12B-it-TT-BFP8-P150/20261001T001840Z.json",
+    "savedRunPathAbsolute": "/var/tmp/gemma4-12b/runs/lmx-2k-p3d/runs/Lottolabs-gemma-4-12B-it-TT-BFP8-P150/20261001T001840Z.json",
+    "savedRunPathRelative": "/var/tmp/gemma4-12b/runs/lmx-2k-p3d/runs/Lottolabs-gemma-4-12B-it-TT-BFP8-P150/20261001T001840Z.json",
+    "status": "ready_for_api_validation",
+    "submissionId": "cmuosddj10kd1lq010lf2ahkj",
+    "submissionStatus": "approved",
+    "submitCommand": "lmx speed-test submit /var/tmp/gemma4-12b/runs/lmx-2k-p3d/speed-test.json"
+  },
+  "backend": "tt-metal",
+  "batchSize": 1,
+  "benchmarkMode": "remote",
+  "contextLength": 262144,
+  "detectedEngines": [
+    {
+      "binaries": {
+        "llama-bench": "/home/lotto/llama.cpp/build/bin/llama-bench",
+        "llama-cli": "/home/lotto/llama.cpp/build/bin/llama-cli",
+        "llama-server": "/home/lotto/llama.cpp/build/bin/llama-server"
+      },
+      "installed": true,
+      "name": "llama.cpp"
+    }
+  ],
+  "engineFlags": {
+    "baseUrl": "http://127.0.0.1:8002",
+    "concurrency": 1,
+    "iterations": 5,
+    "maxTokens": 256,
+    "mode": "remote",
+    "prefixCacheBust": "leading_nonce_per_request",
+    "promptFile": "/var/tmp/gemma4-12b/runs/prompt-2k.txt",
+    "promptSource": "file",
+    "servedModel": "google/gemma-4-12B-it",
+    "servedModelSource": "explicit",
+    "specDecoding": true,
+    "specDraftModel": "google/gemma-4-12B-it-assistant",
+    "specMethod": "assistant",
+    "specNumTokens": 5,
+    "stream": true,
+    "timeoutSeconds": 600,
+    "warmup": 2
+  },
+  "engineName": "vllm",
+  "hardware": {
+    "cpu": "AMD Ryzen 9 9950X",
+    "gpuCount": 1,
+    "gpuName": "Tenstorrent P150",
+    "hwClass": "DISCRETE_GPU",
+    "os": "Ubuntu 26.04 LTS",
+    "ramGb": 96,
+    "vramGb": 32
+  },
+  "hardwareSource": "file",
+  "hfId": "Lottolabs/gemma-4-12B-it-TT-BFP8-P150",
+  "id": "cmuosddj10kd1lq010lf2ahkj",
+  "metricSource": "remote_endpoint",
+  "modelResolution": {
+    "candidates": [
+      {
+        "benchmarkCount": 38,
+        "displayName": "gemma-4-12B-it",
+        "family": "Gemma",
+        "hfId": "google/gemma-4-12B-it",
+        "params": 12
+      },
+      {
+        "benchmarkCount": 9,
+        "displayName": "gemma-4-12B-it-qat-q4_0-gguf",
+        "family": "Gemma",
+        "hfId": "google/gemma-4-12B-it-qat-q4_0-gguf",
+        "params": 12
+      },
+      {
+        "benchmarkCount": 0,
+        "displayName": "gemma-4-12B-it-qat-q4_0-unquantized",
+        "family": "Gemma",
+        "hfId": "google/gemma-4-12B-it-qat-q4_0-unquantized",
+        "params": 12
+      }
+    ],
+    "hfId": "Lottolabs/gemma-4-12B-it-TT-BFP8-P150",
+    "searchCommand": "lmx model search google/gemma-4-12B-it",
+    "searchQuery": "google/gemma-4-12B-it",
+    "searchQuerySource": "served_model",
+    "servedModel": "google/gemma-4-12B-it",
+    "servedModelSource": "explicit",
+    "status": "alias"
+  },
+  "modelRevision": "main",
+  "notes": "Single Tenstorrent P150. Lottolabs/gemma-4-12B-it-TT-BFP8-P150, runtime p3d (image sha256:331e79b24fa2575c436158be994c6bc0e184d776d15305e82538d2e4d646f544, dual-NoC weight reader): all-BFP8 TT-native weights with exact equivalence proof, gemma-4-12B-it-assistant drafter K=5 with exact greedy verification, native 262144 context, greedy. ~2K-token natural-text prompt (Newton, Opticks).",
+  "outputText": "### Summary of the Passage\n\nIn this introductory section of *Opticks*, Isaac Newton establishes the foundational framework for his study of light. He begins by clarifying his intent: he aims to explain the properties of light through **reason and experimentation** rather than through abstract hypotheses. \n\nTo do this, he provides a series of formal **Definitions** and **Axioms**:\n*   **Definitions:** He defines \"Rays of Light\" as the smallest parts of light, \"Refrangibility\" (how light bends when moving between mediums), \"Reflexibility\" (how light bounces off surfaces), and the specific angles involved in these movements. Crucially, he distinguishes between **Homogeneal Light** (light where all rays bend the same way) and **Heterogeneal Light** (light made of different types of rays).\n*   **Axioms:** He lists the fundamental rules of optics, such as the fact that the angle of reflection equals the angle of incidence, and that light bends toward the perpendicular when moving from a \"rarer\" (thinner) medium to a \"denser\" one.\n\n---\n\n### The Main Experiment (Explained in Plain Language)\n\nWhile the text provided is primarily a list of definitions and rules,",
+  "outputTokens": 256,
+  "prefillTokens": 0,
+  "prompt": "Summarize the following passage from Newton’s Opticks, then explain its main experiment in plain language.\n\n added\nabout twelve Years after to complete the Theory; except the third Book,\nand the last Proposition of the Second, which were since put together\nout of scatter'd Papers. To avoid being engaged in Disputes about these\nMatters, I have hitherto delayed the printing, and should still have\ndelayed it, had not the Importunity of Friends prevailed upon me. If any\nother Papers writ on this Subject are got out of my Hands they are\nimperfect, and were perhaps written before I had tried all the\nExperiments here set down, and fully satisfied my self about the Laws of\nRefractions and Composition of Colours. I have here publish'd what I\nthink proper to come abroad, wishing that it may not be translated into\nanother Language without my Consent._\n\n_The Crowns of Colours, which sometimes appear about the Sun and Moon, I\nhave endeavoured to give an Account of; but for want of sufficient\nObservations leave that Matter to be farther examined. The Subject of\nthe Third Book I have also left imperfect, not having tried all the\nExperiments which I intended when I was about these Matters, nor\nrepeated some of those which I did try, until I had satisfied my self\nabout all their Circumstances. To communicate what I have tried, and\nleave the rest to others for farther Enquiry, is all my Design in\npublishing these Papers._\n\n_In a Letter written to Mr._ Leibnitz _in the year 1679, and published\nby Dr._ Wallis, _I mention'd a Method by which I had found some general\nTheorems about squaring Curvilinear Figures, or comparing them with the\nConic Sections, or other the simplest Figures with which they may be\ncompared. And some Years ago I lent out a Manuscript containing such\nTheorems, and having since met with some Things copied out of it, I have\non this Occasion made it publick, prefixing to it an_ Introduction, _and\nsubjoining a_ Scholium _concerning that Method. And I have joined with\nit another small Tract concerning the Curvilinear Figures of the Second\nKind, which was also written many Years ago, and made known to some\nFriends, who have solicited the making it publick._\n\n                                        _I. N._\n\nApril 1, 1704.\n\n\nAdvertisement II\n\n_In this Second Edition of these Opticks I have omitted the Mathematical\nTracts publish'd at the End of the former Edition, as not belonging to\nthe Subject. And at the End of the Third Book I have added some\nQuestions. And to shew that I do not take Gravity for an essential\nProperty of Bodies, I have added one Question concerning its Cause,\nchusing to propose it by way of a Question, because I am not yet\nsatisfied about it for want of Experiments._\n\n                                        _I. N._\n\nJuly 16, 1717.\n\n\nAdvertisement to this Fourth Edition\n\n_This new Edition of Sir_ Isaac Newton's Opticks _is carefully printed\nfrom the Third Edition, as it was corrected by the Author's own Hand,\nand left before his Death with the Bookseller. Since Sir_ Isaac's\nLectiones Opticæ, _which he publickly read in the University of_\nCambridge _in the Years 1669, 1670, and 1671, are lately printed, it has\nbeen thought proper to make at the bottom of the Pages several Citations\nfrom thence, where may be found the Demonstrations, which the Author\nomitted in these_ Opticks.\n\n       *       *       *       *       *\n\nTranscriber's Note: There are several greek letters used in the\ndescriptions of the illustrations. They are signified by [Greek:\nletter]. Square roots are noted by the letters sqrt before the equation.\n\n       *       *       *       *       *\n\nTHE FIRST BOOK OF OPTICKS\n\n\n\n\n_PART I._\n\n\nMy Design in this Book is not to explain the Properties of Light by\nHypotheses, but to propose and prove them by Reason and Experiments: In\norder to which I shall premise the following Definitions and Axioms.\n\n\n\n\n_DEFINITIONS_\n\n\nDEFIN. I.\n\n_By the Rays of Light I understand its least Parts, and those as well\nSuccessive in the same Lines, as Contemporary in several Lines._ For it\nis manifest that Light consists of Parts, both Successive and\nContemporary; because in the same place you may stop that which comes\none moment, and let pass that which comes presently after; and in the\nsame time you may stop it in any one place, and let it pass in any\nother. For that part of Light which is stopp'd cannot be the same with\nthat which is let pass. The least Light or part of Light, which may be\nstopp'd alone without the rest of the Light, or propagated alone, or do\nor suffer any thing alone, which the rest of the Light doth not or\nsuffers not, I call a Ray of Light.\n\n\nDEFIN. II.\n\n_Refrangibility of the Rays of Light, is their Disposition to be\nrefracted or turned out of their Way in passing out of one transparent\nBody or Medium into another. And a greater or less Refrangibility of\nRays, is their Disposition to be turned more or less out of their Way in\nlike Incidences on the same Medium._ Mathematicians usually consider the\nRays of Light to be Lines reaching from the luminous Body to the Body\nilluminated, and the refraction of those Rays to be the bending or\nbreaking of those lines in their passing out of one Medium into another.\nAnd thus may Rays and Refractions be considered, if Light be propagated\nin an instant. But by an Argument taken from the Æquations of the times\nof the Eclipses of _Jupiter's Satellites_, it seems that Light is\npropagated in time, spending in its passage from the Sun to us about\nseven Minutes of time: And therefore I have chosen to define Rays and\nRefractions in such general terms as may agree to Light in both cases.\n\n\nDEFIN. III.\n\n_Reflexibility of Rays, is their Disposition to be reflected or turned\nback into the same Medium from any other Medium upon whose Surface they\nfall. And Rays are more or less reflexible, which are turned back more\nor less easily._ As if Light pass out of a Glass into Air, and by being\ninclined more and more to the common Surface of the Glass and Air,\nbegins at length to be totally reflected by that Surface; those sorts of\nRays which at like Incidences are reflected most copiously, or by\ninclining the Rays begin soonest to be totally reflected, are most\nreflexible.\n\n\nDEFIN. IV.\n\n_The Angle of Incidence is that Angle, which the Line described by the\nincident Ray contains with the Perpendicular to the reflecting or\nrefracting Surface at the Point of Incidence._\n\n\nDEFIN. V.\n\n_The Angle of Reflexion or Refraction, is the Angle which the line\ndescribed by the reflected or refracted Ray containeth with the\nPerpendicular to the reflecting or refracting Surface at the Point of\nIncidence._\n\n\nDEFIN. VI.\n\n_The Sines of Incidence, Reflexion, and Refraction, are the Sines of the\nAngles of Incidence, Reflexion, and Refraction._\n\n\nDEFIN. VII\n\n_The Light whose Rays are all alike Refrangible, I call Simple,\nHomogeneal and Similar; and that whose Rays are some more Refrangible\nthan others, I call Compound, Heterogeneal and Dissimilar._ The former\nLight I call Homogeneal, not because I would affirm it so in all\nrespects, but because the Rays which agree in Refrangibility, agree at\nleast in all those their other Properties which I consider in the\nfollowing Discourse.\n\n\nDEFIN. VIII.\n\n_The Colours of Homogeneal Lights, I call Primary, Homogeneal and\nSimple; and those of Heterogeneal Lights, Heterogeneal and Compound._\nFor these are always compounded of the colours of Homogeneal Lights; as\nwill appear in the following Discourse.\n\n\n\n\n_AXIOMS._\n\n\nAX. I.\n\n_The Angles of Reflexion and Refraction, lie in one and the same Plane\nwith the Angle of Incidence._\n\n\nAX. II.\n\n_The Angle of Reflexion is equal to the Angle of Incidence._\n\n\nAX. III.\n\n_If the refracted Ray be returned directly back to the Point of\nIncidence, it shall be refracted into the Line before described by the\nincident Ray._\n\n\nAX. IV.\n\n_Refraction out of the rarer Medium into the denser, is made towards the\nPerpendicular; that is, so that the Angle of Refraction be less than the\nAngle of Incidence._\n\n\nAX. V.\n\n_The Sine of Incidence is either accurately or very nearly in a given\nRatio to the Sine of Refraction._\n\nWhence",
+  "promptTokens": 1996,
+  "provenance": {
+    "benchmarkMode": "remote",
+    "cli": "localmaxxing-go",
+    "createdAt": "2026-10-01T00:18:40Z",
+    "metricSource": "remote_endpoint",
+    "timingSource": "client_observed_http",
+    "ttftSource": "stream_first_token"
+  },
+  "quantization": "BFP8",
+  "quantizationResolution": {
+    "cli": "BFP8",
+    "status": "matched",
+    "trusted": "BFP8",
+    "trustedSource": "cli"
+  },
+  "sampleStats": {
+    "tokSOut": {
+      "count": 5,
+      "max": 59.8,
+      "mean": 54.2,
+      "min": 48.5,
+      "p50": 53.9,
+      "stddev": 4.6
+    },
+    "tokSTotal": {
+      "count": 5,
+      "max": 458.4,
+      "mean": 420.18,
+      "min": 381.7,
+      "p50": 417.9,
+      "stddev": 31.11
+    },
+    "ttftMs": {
+      "count": 5,
+      "max": 652.07,
+      "mean": 651.48,
+      "min": 650.74,
+      "p50": 651.49,
+      "stddev": 0.5
+    }
+  },
+  "samples": [
+    {
+      "iteration": 1,
+      "outputTokens": 256,
+      "promptTokens": 1993,
+      "request": 1,
+      "tokSOut": 53.9,
+      "tokSPrefill": 3062.7,
+      "ttftMs": 650.74
+    },
+    {
+      "iteration": 2,
+      "outputTokens": 256,
+      "promptTokens": 1998,
+      "request": 1,
+      "tokSOut": 48.5,
+      "tokSPrefill": 3065.3,
+      "ttftMs": 651.8
+    },
+    {
+      "iteration": 3,
+      "outputTokens": 256,
+      "promptTokens": 1994,
+      "request": 1,
+      "tokSOut": 57.6,
+      "tokSPrefill": 3060.7,
+      "ttftMs": 651.49
+    },
+    {
+      "iteration": 4,
+      "outputTokens": 256,
+      "promptTokens": 1997,
+      "request": 1,
+      "tokSOut": 51.2,
+      "tokSPrefill": 3062.6,
+      "ttftMs": 652.07
+    },
+    {
+      "iteration": 5,
+      "outputTokens": 256,
+      "promptTokens": 1996,
+      "request": 1,
+      "tokSOut": 59.8,
+      "tokSPrefill": 3064.6,
+      "ttftMs": 651.32
+    }
+  ],
+  "submissionId": "cmuosddj10kd1lq010lf2ahkj",
+  "submissionStatus": "approved",
+  "submittedAt": "2026-10-01T00:18:41.725Z",
+  "timingSource": "client_observed_http",
+  "tokSOut": 53.9,
+  "tokSOutSource": "inter_token",
+  "tokSPrefill": 3062.7,
+  "tokSPrefillSource": "estimated_from_ttft",
+  "tokSTotal": 417.9,
+  "tokenSources": {
+    "output": "endpoint_usage",
+    "prompt": "endpoint_usage"
+  },
+  "ttftMs": 651.49,
+  "ttftSource": "stream_first_token"
+}

evidence/previous-p3c/http/tput_vs_direct.json

@@ -0,0 +1,22 @@
+[
+ {
+  "ctx": 32768,
+  "direct_tokens": 512,
+  "http_requests": 3,
+  "identical": [
+   true,
+   true,
+   true
+  ]
+ },
+ {
+  "ctx": 261632,
+  "direct_tokens": 512,
+  "http_requests": 3,
+  "identical": [
+   true,
+   true,
+   true
+  ]
+ }
+]