# `materialization-receipt.json` names paths that are not on your machine

**Added:** 2026-08-29, as a correction. Nothing in this repository was edited to add it.

`materialization-receipt.json` in this repository records

    "packed_root": "/home/jl_fs/glm53-k8/out-k8"
    "output_root": "/home/jl_fs/glm53-k8/ckpt-k8"

Those are the **producer's absolute paths on a rented GPU filesystem that no longer
exists**. They are sealed provenance metadata describing where the encode ran. They are
not resolvable locations, and nothing you can do locally will make them resolve.

## Why they were not simply corrected

The receipt is self-sealed: `receipt_sha256` is a SHA-256 over its own canonical form
with that field blanked. Editing any byte changes the digest, and that digest is verified
against the **published bytes** on every measurement run
(`k6/tools/tr3_surface.py::verify_seal`, called from `bin/measure_cloud.py`, which
raises `this release's PUBLISHED seal does not reproduce`). Rewriting the paths to make
them prettier would permanently break every future measurement against this release, and
would falsify a record of where the encode actually ran. The honest fix for a wrong
pointer inside a sealed record is a correction beside it, not a quiet edit.

## What to read instead

| You want to | Use |
|---|---|
| Score this release | `--source tr3` (or `--source exl3hf`) — reads the published shards directly and never consults `packed_root` |
| Verify the release's own claims | `k6/tools/tr3_surface.py` — recomputes all 12 claims in the receipt from the published bytes before decoding |
| Reproduce the published KLD | the published capture dataset, `malaiwah/GLM-5.3-Flash-fidelity-suite-v1` |

`--source checkpoint` and `--source payload-store` are **producer-side** reading paths.
The payload store was never published, so they are not reachable from this repository —
that is a publishing gap, not something a flag can fix. `--source checkpoint` resolves
`packed_root` out of this receipt and will fail on the path above; that failure is the
expected outcome, not a misconfiguration on your side.

## Schema note

This receipt's `schema` is `malaiwah.glm53-k8-materialization-receipt.v1`.
Its sibling release uses the other family string for the same document type
(`quant-pipeline.glm53-k6-...` vs `malaiwah.glm53-k8-...`). Both are historical; no
validator in the suite keys on this field. Recorded here so a third party writing one
does not assume the namespace is stable.