malaiwah commited on
Commit
b5ca3b3
·
verified ·
1 Parent(s): e51e904

disclose that materialization-receipt.json names a destroyed filesystem

Browse files

packed_root and output_root in materialization-receipt.json are the
PRODUCER's absolute paths on a rented GPU filesystem that no longer exists.
The receipt is self-sealed and its digest is verified against the PUBLISHED
bytes on every measurement run, so correcting the paths in place would
permanently break every future measurement against this release and would
falsify a record of where the encode ran. The receipt is untouched; this
file states what those fields are and names the reading path that works
(--source tr3 / --source exl3hf).

Files changed (1) hide show
  1. MATERIALIZATION-PATHS.md +45 -0
MATERIALIZATION-PATHS.md ADDED
@@ -0,0 +1,45 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # `materialization-receipt.json` names paths that are not on your machine
2
+
3
+ **Added:** 2026-08-29, as a correction. Nothing in this repository was edited to add it.
4
+
5
+ `materialization-receipt.json` in this repository records
6
+
7
+ "packed_root": "/home/jl_fs/glm53-k8/out-k8"
8
+ "output_root": "/home/jl_fs/glm53-k8/ckpt-k8"
9
+
10
+ Those are the **producer's absolute paths on a rented GPU filesystem that no longer
11
+ exists**. They are sealed provenance metadata describing where the encode ran. They are
12
+ not resolvable locations, and nothing you can do locally will make them resolve.
13
+
14
+ ## Why they were not simply corrected
15
+
16
+ The receipt is self-sealed: `receipt_sha256` is a SHA-256 over its own canonical form
17
+ with that field blanked. Editing any byte changes the digest, and that digest is verified
18
+ against the **published bytes** on every measurement run
19
+ (`k6/tools/tr3_surface.py::verify_seal`, called from `bin/measure_cloud.py`, which
20
+ raises `this release's PUBLISHED seal does not reproduce`). Rewriting the paths to make
21
+ them prettier would permanently break every future measurement against this release, and
22
+ would falsify a record of where the encode actually ran. The honest fix for a wrong
23
+ pointer inside a sealed record is a correction beside it, not a quiet edit.
24
+
25
+ ## What to read instead
26
+
27
+ | You want to | Use |
28
+ |---|---|
29
+ | Score this release | `--source tr3` (or `--source exl3hf`) — reads the published shards directly and never consults `packed_root` |
30
+ | Verify the release's own claims | `k6/tools/tr3_surface.py` — recomputes all 12 claims in the receipt from the published bytes before decoding |
31
+ | Reproduce the published KLD | the published capture dataset, `malaiwah/GLM-5.3-Flash-fidelity-suite-v1` |
32
+
33
+ `--source checkpoint` and `--source payload-store` are **producer-side** reading paths.
34
+ The payload store was never published, so they are not reachable from this repository —
35
+ that is a publishing gap, not something a flag can fix. `--source checkpoint` resolves
36
+ `packed_root` out of this receipt and will fail on the path above; that failure is the
37
+ expected outcome, not a misconfiguration on your side.
38
+
39
+ ## Schema note
40
+
41
+ This receipt's `schema` is `malaiwah.glm53-k8-materialization-receipt.v1`.
42
+ Its sibling release uses the other family string for the same document type
43
+ (`quant-pipeline.glm53-k6-...` vs `malaiwah.glm53-k8-...`). Both are historical; no
44
+ validator in the suite keys on this field. Recorded here so a third party writing one
45
+ does not assume the namespace is stable.