[Dev Workflow] We Added Provenance to 18 Model Repos: How to Check a Quantized Download

---

Why we started with our own repos

I publish quantized models on Hugging Face under coolthor. When Microsoft Research described Lazarus, a technique for planting dormant behavior in model weights, I had a fairly immediate question: what evidence could someone downloading my models actually check?

We are the third party in somebody else's model supply chain. So I started with our running models and our own releases. We added provenance sections to 18 repositories, including source information, build details, published file hashes and explicit gaps. In 17, the historical base revision was not recorded in the recovered material.

The useful outcome for a downloader is a procedure you can repeat: find the actual file your runner uses, compare it with a pinned release, then inspect how that release was made. None of this audit found a backdoor, and none of it rules one out.

If quantization itself is unfamiliar, our introduction to quantization algorithms explains the conversion. Here, the question is whether you can account for the result you downloaded.

A model name does not identify the file your agent loads

Start with your runner's startup arguments or configuration. Record the weight filename it actually opens, its publisher, repository and revision. For a sharded model, record every loaded shard and the index. Include separately loaded adapters, projectors and other model components. A friendly model alias is useful for routing requests; it is insufficient evidence of what sits on disk.

Our inventory found an alias suggesting a Qwen model that actually pointed to a MiniCPM derivative. Another runtime consumed a locally packed cache rather than the original checkpoint.

For a new download, inspect the model card and Files and versions before starting inference. Copy the full release commit, rather than recording only main. Keep the filename with it. You should be able to answer: which publisher, which repository, which commit, which file?

Follow the quantizer's immediate source before the original model family

The name Qwen or Gemma in a quantized repository is a starting point. It does not tell you whether the input was the original release, a fine-tune, a merge or another quantization.

For example, our Huihui Qwen NVFP4 provenance section names the Huihui derivative as its immediate input. Skipping that step and writing “from Qwen” would omit an upstream modification. The build-time commit for that input remains not recorded.

Read the source table alongside the build section. A source link identifies a repository; a historical commit identifies the input version. Tool names and a description of the method help, but reproducing the build also needs the actual command, patches and relevant data. Today's upstream HEAD cannot reconstruct which revision an older job consumed.

Compare SHA-256 against a pinned release

Here is a real example from our Sulphur NVFP4 model card. Its provenance section identifies the inspected weight release as d8f083b8d126bd06c292c42262588c400a8abe60. The newer commit in the card URL only updates the README.

I use the separately packaged VAE because the filename, byte count and expected digest are all recorded. This is a media-model component, not a model tested in the Lazarus experiments. Checking this file does not check the repository's other weights.

File	Expected bytes	Expected SHA-256
ltx_full_vae.safetensors	1452240458	a48d539b06bd8628d514de36c3a3e816c08c217d2fe90534b6426978c6dca5d8

Use a new, empty directory so the download does not replace an existing model. It requires space for the byte count above. The following command fetches the file from the recorded weight release; it does not load or execute the model:

curl --fail --location \
  --output ltx_full_vae.safetensors \
  https://huggingface.co/coolthor/Sulphur-2-distilled-NVFP4/resolve/d8f083b8d126bd06c292c42262588c400a8abe60/ltx_full_vae.safetensors
wc -c < ltx_full_vae.safetensors

On Linux, calculate the local digest:

sha256sum ltx_full_vae.safetensors

On macOS, use:

shasum -a 256 ltx_full_vae.safetensors

Compare the entire digest with the card. A filename match or byte-count match alone is insufficient. If the file came from a Git clone, make sure Git LFS downloaded the weight contents. A small LFS pointer text file is a different file and produces a different hash.

What if they differ? First check the exact filename and release, whether the download completed, and whether you hashed a pointer or an error response. Until you resolve the discrepancy, you have not identified those bytes as the referenced release. A mismatch alone does not identify malicious modification.

For an existing local model, use its actual path instead of downloading another copy. Save the expected digest and commit alongside your computed result. For sharded models, hash every shard.

A matching hash establishes file identity, not safe behavior

If your digest matches the pinned publisher record, your file matches that release. You have not established whether the release itself was modified before publication, whether its declared source is correct, or whether a trigger could change its behavior.

You also have to trust wherever the expected digest came from. A publisher account compromised before you retrieve the file could serve both altered weights and matching checksums. Keeping an independently obtained, previously trusted release record gives you a reference outside that new download. Our newly written source sections do not provide an independent historical attestation.

Microsoft Research's Lazarus summary describes a weight-editing attack that does not require training and can remain dormant during ordinary evaluations. That makes “it answered my usual prompts correctly” inadequate evidence for excluding this attack. It does not establish that our releases contain it.

The agent's tools determine what an emitted command can do. While provenance remains incomplete, limit filesystem access, keep credentials outside the agent's reach, restrict outbound connections and review consequential commands before execution. These are recommended controls. This inventory did not deploy them or change running services.

Keep a build record when you publish your next quantization

The record I want alongside our next release starts before conversion. Save the exact source repository and full commit, the input filenames and their hashes. Do this for each input in a merge or a package containing several components.

Keep the converter or quantizer commit, local patches, full command and environment. If calibration affects the result, record the data revision, selection method and random seed. Record intermediate transformations too: extracting a component, merging an adapter and repacking runtime weights can each create a new artifact that needs its own explanation.

Finish with an output manifest containing filenames, byte counts and SHA-256 digests. State what was actually checked: published metadata, a local file comparison, a reproduced build or a tensor-aware diff. Those results support different claims. Re-running the recipe may also produce different file bytes because of serialization or execution differences; document that limitation rather than promising deterministic output without testing it.

For an old release with missing records, write not recorded. Leave the input commit unknown until historical evidence supports one.

Deep dive: what our inventory did and did not establish

Skip this section if you only need the checks above. It covers the scope behind our numbers and why some comparisons are still open.

The running-model inventory and the publishing audit count different things

The local inventory calculated SHA-256 for 34 unique files or auxiliary artifacts. This was an inventory of evidence associated with running services or recent service use, not a full disk search and not proof that every listed media weight remained in GPU memory. Paths referring to the same physical file were recorded as aliases; distinct copies were separate observations.

The categories below describe comparison evidence. They are not a distribution of safe versus unsafe models.

Comparison result	Files or artifacts	Interpretation
Original publisher, same known revision, matching	4	Local bytes matched the referenced original release
Third party, same known revision, matching	2	Local bytes matched that third-party release
Original publisher content matched; acquisition revision unknown	1	A matching public file does not recover download history
Third-party content matched; acquisition revision unknown	13	The same limitation applies to these public derivatives
Different from quantization upstream; local edits recorded	2	A documented derivative needs review of its transformation
No directly comparable upstream file	12	Local hashes exist, but direct upstream identity remains unresolved

The differing files had recorded local modifications. That explains why byte equality with the earlier quantization was not expected; it does not independently verify the edits. Runtime caches and repacked weights also need a reconstruction or a format-aware comparison. There may be no upstream file with identical serialization to compare.

The source-card update covered published metadata, not a rebuild

The publishing review covered 18 repositories and 73 weight or calibration files. Those repositories include media models and auxiliary artifacts; describing them all as agent LLMs would be incorrect. Each repository received an appended English Provenance section. The push report verified the new cards and checked that repository changes were confined to README.md.

The 73 digests came from pinned Hugging Face LFS metadata. That card update did not download every large weight file and calculate its hash again. The local 34-file inventory did calculate local hashes. The two counts describe separate scopes and must not be added together as an audit coverage total.

In the recovered source records, 17 of 18 repositories lacked a historical base revision. The exception was VoxCPM2-Q4_K_M-GGUF, whose recorded base was openbmb/VoxCPM2@32279effe8c19989596f05d353d1447f51d9e915. Even that release still lacked parts of a complete reproduction record. A known input commit is valuable evidence, but it does not supply missing commands or dependency locks.

We performed no quantization rerun or weight-diff audit in the card update.

Lazarus motivates checking weights without supplying an all-clear test

The Lazarus paper reports editing 7 dormant neurons in Nemotron-Terminal-8B. Its gradient-refined variant (Lazarus-SGD, fitted on 23 examples) predicted the payload on at least 98.8% of recorded triggered test trajectories; the paper also describes an analytic version that skips fine-tuning. It also reports vulnerability in Qwen3.6-27B and Gemma-4-31B-IT. These are study results for the tested checkpoints and conditions, not a measured attack rate across downloaded quantizations.

A quantized checkpoint normally differs numerically from its unquantized source. Comparing their raw file hashes cannot separate expected quantization changes from unexpected weight edits. Checking how a quant was derived takes the pinned base model, the build recipe and a format-aware tensor diff. Our historical records do not yet support that complete check for the releases discussed here.

Also in this series: Quantization algorithms.